Chris,
On Thu, May 7, 2009 at 4:07 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> A few questions:
>
Chris, maybe you'll get the hang of this Valve if I explain the
business-requirement I had:
My primary target was to cirumvent the problem having a framed
web-app, where some content is requested after the session has timed
out.
let's say we have the following website-structure:
+----------------------------------------+
| menue1| |
| menue2| some_content |
| menue3| |
| menue4| |
| menue5| |
+-----------------------------------------+
(hope the formatting is ok )
"some_content" is an iframe, and the content of this iframe is changed
by selecting one of the left menue-items.
The iframe is specified in "index.html such as:
<html>
<body>
<iframe name="some_content" src="/protected/somepage.html">
Some iframe-error-message
</iframe>
</body>
</html>
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";
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.
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).
Now take a look at some example-Valve-descriptor:
<Context>
<Valve className="org.apache.catalina.valves.LoginValve"
protectedPath="/protected"
redirectAfterAuth="/protected/index.html"/>
</Context>
This basically says, that all /non-authorized/ requests to the
protected content will be re-routed to "/protected/index.html"
(redirectAfterAuth).
> 1. Why can't the "redirectAfterAuth" path be within the protected space?
>
Actually I do not see why this shouldn't be possible: Actually the
idea is, that redirectAfterAuth /must/ be in the protected area
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
- the URL requested must /not/ be j_security_check
The two latter conditions are necessary to avoid an infinite loop when
accessing protected content
> 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
> 3. Why are you checking to see if characters 10 - 16 of the request URI
> are "y_check". Why not check for the whole "j_security_check" string?
> Why not check the /end/ of the request URI for j_security_check,
> since the URI for j_security_check is not required to be
> /j_security_check but pretty much */j_security_check?
You are right with this:
Actually I made a mistake here:
When "j_security_check" is triggered, the URL will look like
/protected/j_security_check
As you can see, in this example it works since "/protected" is exactly
10 characters long.
Therefore, the correct code would be
+ && !aRequest.getRequestURI().startsWith(
+ "/j_security_check",
protectedPath.length())) {
I'll correct that with a new patch during the weekend.
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()
> 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 definately have a new session
> 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
>
> It appears that your valve does nothing but murder the session and
> redirect the user if authtype=null and you are requesting a resource
> from a particular URI space. This does not seem particularly useful.
>
> Maybe I'm missing something subtle.
>
Seems to be - see my explanations on top.
Cheers
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available
@ http://pgpkeys.pca.dfn.de:11371
@ http://pgp.mit.edu:11371/
skype:rc46fi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
