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 2011/02/25 17:33:25 UTC
DO NOT REPLY [Bug 50831] New: j_security_check handling doesn't
handle original request anchors
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831
Summary: j_security_check handling doesn't handle original
request anchors
Product: Tomcat 6
Version: 6.0.29
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
AssignedTo: dev@tomcat.apache.org
ReportedBy: mbatchelor@pentaho.com
Created an attachment (id=26694)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=26694)
Replacement for jsp/security/protected/index.jsp
When linking to a protected resource with anchor specified in the URL using
Form Authentication, tomcat directs to the login page (correct) and upon
successful authentication, directs to the original request but strips off the
anchor.
Example:
1- Copy altered attached index.jsp into examples/jsp/security/protected
(replace index.jsp).
2- Link to the JSP with an anchor:
http://localhost/examples/jsp/security/protected/index.jsp#sectc
3- Note you will be correctly linked to the login JSP. Authenticate with
both/tomcat.
4- Upon successful authentication, you are directed to the index page, but it
doesn't follow the anchor. Look at the URL in the address bar and you'll see
that the anchor was stripped off by Tomcat.
5- Re-paste the original URL from #2 above, and notice that the anchor is valid
and works.
Tested in Tomcat 5.5.29 and 6.0.29. Tested with Chrome and Firefox.
The attached index.jsp has three different anchor points and long sections of
junk between them so you can easily see when the page retains the anchor and
when it doesn't.
Since Tomcat handles all the j_security_check stuff internally, I can't find a
work-around that will let me get the original requested URL with the anchor.
--
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 50831] j_security_check handling doesn't handle
original request anchors
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831
Marc Batchelor <mb...@pentaho.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version| |All
--- Comment #1 from Marc Batchelor <mb...@pentaho.com> 2011-02-25 14:21:31 EST ---
Further looking with tracing tools indicates that the anchor is never actually
sent to the server. So there's no way for the server (Tomcat) to store it in
the SavedRequest object without it being sent to the server.
There really isn't a work-around that I can see at this point. Since the server
processes the j_security_check, and the redirect rightly goes to the login
page, by the time it lands there, the anchor bit is completely lost.
Given all this, it's safe to close this. My only recourse in my current
application is to rewrite handling to not use anchors.
--
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 50831] j_security_check handling doesn't handle
original request anchors
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831
Konstantin Kolinko <kn...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Konstantin Kolinko <kn...@gmail.com> 2011-02-25 14:30:07 EST ---
> Further looking with tracing tools indicates that the anchor is never actually
> sent to the server.
Yes, this is how it works. It has nothing to do with Tomcat. Thus I am closing
this as INVALID.
Just a note: Servlet 3.0 spec (implemented by Tomcat 7.0.+) allows to perform
login() programmatically. Maybe that will help you. Also using BASIC or DIGEST
auth methods won't suffer from this issue.
If you want to discuss this further, please use the users@ mailing list.
--
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