-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregor,
On 5/7/2009 7:12 AM, Gregor Schneider wrote: > Chris, maybe you'll get the hang of this Valve if I explain the > business-requirement I had: I think I understand your business requirement. It's your code I don't understand. > Now let's assume, session is timing out, and after that timeout the > user selects one of the menue-entries on the left side. > What's happening? > > The url requested will look like "http://mysite/protected/some_stuff"; It will look like http://mysite/protected/some_stuff.html > The HTML in that case looks like > > <a href="http://mysite/protected/some_stuff.html"; > target="some_content">menue4</a> > > No this triggers j_security_check, but unfortunately j_security_check > just stores the last request, and after passing the credentials, > you'll won't see your "index.html" but "/protected/some_stuff.html" - > without the iframe and aboviously without the menue. Where did index.html come from? Your link should open in the "some_content" window. So, you'll get the login page shown in your iframe, then you login, and then /protected/some_stuff.html is shown in the iframe. Is that not what you want? > So the purpose of this Valve is to provide a mechanism which makes > sure, that if a non-authorized request comes in requesting anything > else but your "/protected/index.html", that the original request (i.e. > "/protected/some_stuff") is replaced by > "/protected/index.html" (or any other url being specified in the > Valve-descriptor). Wow. You're right: I didn't understand your business requirement. I think this use case is ... minimally represented among web sites. > This basically says, that all /non-authorized/ requests to the > protected content will be re-routed to "/protected/index.html" > (redirectAfterAuth). Note that this violates the servlet spec, which you are certainly free to do. >> 1. Why can't the "redirectAfterAuth" path be within the protected space? > > Actually I do not see why this shouldn't be possible: Sorry, looking back, I'm not sure why I made that statement. > If you take a look at the first condition: > > + if (aRequest.getRequestURI().startsWith(protectedPath) > + && > !aRequest.getRequestURI().startsWith(redirectAfterAuth) > + && !aRequest.getRequestURI().startsWith( > + "/j_security_check", > 10)) { > > Basically it says: > > - Only URLs are handled being in my protected area > - the URL must /not/ be equal my default protected starting-URL No, it says that it can't start with your redirectAfterAuth URL. > - the URL requested must /not/ be j_security_check No, this checks characters 10-16 of your URL. > The two latter conditions are necessary to avoid an infinite loop when > accessing protected content Why? If the user is not authenticated, they get redirected. If the user is authenticated, nothing happens. The loop only occurs when the redirectAfterAuth URL lives within the protected space, which is what you said you wanted. Presumably, the container intervenes and serves the login page before the loop is allowed to occur. Note that you have an extraneous level of if/then... the authType check could just as easily be a part of the 3-part predicate just discussed. >> 2. Why do you check to see if the request URI /startsWith/ the >> redirectAfterAuth instead of being equal to it? > > Because there might be some parameters after the adress in the URL - > i.e., if Cookies are not possible so that the session-information is > stored within the URL Check the spec: the ';jsessionid' will not be included in request.getRequestURI. > When "j_security_check" is triggered, the URL will look like > > /protected/j_security_check I'm not sure that's guaranteed. Your app may work this way, but someone else's app might use /j_security_check no matter what (i.e. the "protected" prefix does not have to be in front of j_security_check in order for logins to work). > Why do I not ask for the String ending with "j_security_check"? > I was not sure how that URL looks like if session-info is encoded > within the URL - therefore I'm using startsWith() See above. It's easy to test this, btw. >> 4. Why are killing the session if the authtype is null? > > Because we experienced with some users, esp. behind company-proxies, > that situations may occur where a session still exists, but the > Principal was null. > Therefore, if Principal is null, better be safe than sorry and make > sure you definitely have a new session. You already have a session... why not simply allow it to live? Having a session and being authenticated are not the same (though the inverse /is/ true for FORM authentication). >> 5. Why does your valve pass-through any requests before the component >> has "started"? Is there a valid use case where NOT performing these >> checks and redirects is appropriate? > > Nope. I took this code from AccessLogValve (I believe it was that > one), and my assumption was those checks don't make sense /before/ the > Valve is completely set (started). > If you feel that a different approach does make more sense here, I'm > happy for your suggestions I'd be surprised if requests were accepted before all Valves were brought into service. But, I've been surprised by Tomcat's /filter/ behavior before (i.e. filters who throw exceptions during init() are happily put into service and can fail all they want!). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkoDWTwACgkQ9CaO5/Lv0PCSMwCdHk+NMxyXW7EHxI1nXmjJeRbp 0KwAniyQPk0lAHV+DSHYVHThxfTvPEl7 =BJ4Z -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
