You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/11/08 10:17:42 UTC
DO NOT REPLY [Bug 50231] New: Manager application should not use GET
request to perform operations
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
Summary: Manager application should not use GET request to
perform operations
Product: Tomcat 6
Version: 6.0.29
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Manager application
AssignedTo: dev@tomcat.apache.org
ReportedBy: ramon@echophase.com
Currently the operations that can be performed on webapps are from the manager
app are triggered by links that generate GET requests. These actions include:
Start, Stop, Reload, Undeploy. These actions have side-effects and should not
be triggered by GET requests, but by POSTs. The effect on the end-user of the
manager app is that reloading the page after performing one of these actions
causes it to be performed again without warning.
Suggested fix: change the links to forms with method="post", redirect the user
back to the list after posting.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
--- Comment #2 from Ramon <ra...@echophase.com> 2010-11-08 06:40:02 EST ---
I'm not sure what you're suggesting Rainer? My issue relates to the tomcat
manager HTML page specifically. In my opinion the right thing to do is to use
POST. I do not see the need for complex logic just so that we can still use
GET. To my mind, the use of GET in this context is just plain wrong to begin
with, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1.
Regarding tooling, I'm not suggesting a change to the tooling interface. If it
currently supports GET, it should probably continue to do so for backwards
compatibility. It should also support POST as the "proper" way of doing things.
I think all HTTP clients support POST easily - wget, curl, lwp - what are you
using?
Another problem that could arise from these side-effecting GET requests is CSRF
- not sure how that could be dealt with while preserving tool compatibility.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
--- Comment #1 from Rainer Jung <ra...@kippdata.de> 2010-11-08 04:42:37 EST ---
For the mod_jk status worker we use GET but respond with an answer page that
only acknowledges and is after a few seconds redirected to the page used before
the operation was requested.
That way operations are still easy to automate (many tools are better or at
least easier to use with POST) but there is no problem with reloads.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
--- Comment #3 from Mark Thomas <ma...@apache.org> 2010-11-08 09:42:05 EST ---
The comment re CSRF is pure FUD:
a) POSTs make it marginally harder to commit a CSRF attack but by no means
prevent it.
b) The generic CSRF protection from Tomcat 7 has been back-ported to 6.0.x and
will be included for the Manager and Host Manager in 6.0.30 onwards.
I'd lean towards not fixing this in 6.0.x but if someone wants to back-port the
changes from 7.0.x I'd probably vote for it.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
Ramon <ra...@echophase.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #6 from Ramon <ra...@echophase.com> 2010-11-08 13:55:12 EST ---
*** This bug has been marked as a duplicate of bug 40001 ***
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
--- Comment #5 from Mark Thomas <ma...@apache.org> 2010-11-08 10:41:18 EST ---
Tomcat 7 has switched to POST for all requests where you'd expect POST to be
used. A refresh can still cause problems but at least the user will be prompted
by the browser first.
If someone is so inclined to propose a patch for 6.0.x, the 7.0.x patches would
be a good starting point and shouldn't be that hard to find in the archives.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java?view=log
would be a good place to start.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50231] Manager application should not use GET
request to perform operations
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50231
--- Comment #4 from Ramon <ra...@echophase.com> 2010-11-08 10:33:21 EST ---
I'm sorry if I offended you. I admit don't know enough about how browsers
handle HTTP authentication credential to properly assess the CSRF threat. I did
not mean to sensationalize the issue. Glad to see that it is addressed in the
next version anyway though.
My real issue is with the HTML manager interface and usability. It is a really
bad experience to accidentally undeploy an application just by refreshing the
page without any warning. Will this be addressed in Tomcat 7 too?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org