I've seen in documentation that I should not use new roles for the deploy feature in the HTML Manager (cf. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#Manager_Application). So I'm using the old manager role, but I'm getting a 403 error when I deploy an application. The upload and undeploy features work well. Here is my tomcat-users.xml file : <tomcat-users> <role rolename="manager"/> <user username="tomcat" password="tomcat" roles="manager"/> </tomcat-users>
Bugzilla is not a support forum. Please post usage questions and issues on the Tomcat users' mailing list.
OK, maybe its not a bug, but it works fine in Tomcat 7 with the same usage. I've looked further and saw that, if the "deploy" action is a GET, it fails because the nonce is not in the request. If it is a POST it works. OK, maybe it is not a bug, but it could work better with a very lite change in the org.apache.catalina.manager.HTMLManagerServlet class.
Created attachment 26957 [details] Proposed patch
The role name is a red herring. The Realm doc wasn't updated. The correct role is manager-gui. The docs have been corrected although the original issue (deploy fails) remains.
I have confirmed both the issue and that the patch fixes it. The problem is that when a form is use with GET and the action URL contains request parameters user agents may (FF4 does) overwrite the parameters already in the URL with those in the form rather than combine them. Switching to POST avoids this issue. I have proposed the patch for 6.0.x.
(In reply to comment #5) > The problem is that when a form is use with GET and the action URL contains > request parameters user agents may (FF4 does) overwrite the parameters already > in the URL with those in the form rather than combine them. Switching to POST > avoids this issue. That is how form submission is defined in HTML5. 4.10.22 Form submission [1] -> 4.10.22.3 Form submission algorithm -> Table in Step 17 -> "http" + GET method gives "Mutate action URL" -> Mutate action URL is "Let destination be a new URL that is equal to the action except that its <query> component is replaced by query (adding a U+003F QUESTION MARK character (?) if appropriate)." [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission So it is a natural limitation on the use of CsrfPreventionFilter in such forms. But I am OK with the change to the form, because I do not see a reason to use GET method here. The action is not repeatable, nor it is bookmarkable, because of the nonce.
*** Bug 51183 has been marked as a duplicate of this bug. ***
Fixed in 6.0.x and will be included in 6.0.33 onwards. Thanks for the patch.
You're welcome. I'm glad with my small contrib.
Created attachment 31288 [details] I'm getting the attached error while connecting with javabridge using php Please anyone can you help me for the attached error?
(In reply to Madhiyalagan from comment #10) Not here. See Comment 1 above. http://tomcat.apache.org/bugreport.html#Bugzilla_is_not_a_support_forum