tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Dubuc" <martind1...@gmail.com>
Subject Re: j_security_check
Date Tue, 02 Dec 2008 19:36:49 GMT
Christopher,

I will describe the browser interactions with regards to the access logs.

At 17:13:06, the user accessed the main.jsf page. The session timeout for
the application is 1 minute. The main.jsf page has meta tag that redirectes
to sessionTimeout.jsf after 1 minute. The main.jsf page also has a
window.onbeforeunload  directive. After the meta timeout occurs (after 1
minute), I assume the client automatically tries to redirect to
sessionTimeout.jsf. Before the redirection takes place, the onbeforeunload
event is serviced and a prompt is presented to the user (Do you want to
navigate away from current page). In the recorded session, the user pressed
OK at 17:28:04. Note that accesses at 17:13:13 and 17:28:01 to the manager
application were done to verify if the session was still alive or not. At
17:28:01, the session was not present anymore in the list of live Tomcat
sessions. My assumption is that clicking on OK caused the client to be
redirected to sessionTimeout.jsf. I do not understand why, but that
redirection seems to cause Tomcat to ask for authentication, altough there
is no protected resources used by sessionTimeout.jsf or any other URLs that
are listed in the access log after 17:13:06.

So to answer some of your question more specifically,:

- To get the session timeout to kick in after 1 minute, I had to disable
some of my application code that was hard coding all sessions
maxInactiveInterval value to 15 minutes on startup (bypassing the web.xml
value).
- The sessionTimeout.jsf was triggered from JavaScript.
- The login page does not access any of the protected resources (it doesn't
use the stylesheet, nor any images).
- I believe that the session expired at 17:14:06, although I think the
client only gets redirected to sessionTimeout.jsf at 17:28:04 after user
clicks on OK.
- I do not know why any request resulted in the login page to be shown in
the first place. None of the a4j/*, favicon.ico should trigger the login
page.


On Tue, Dec 2, 2008 at 1:29 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> Martin Dubuc wrote:
> > I finally managed to get the sessions to time out after 1 minute.
>
> What did you have to change?
>
> > Here is the security-constraint definition:
> >     <security-constraint>
> >         <web-resource-collection>
> >             <web-resource-name>
> >                 Page constraints for users
> >             </web-resource-name>
> >             <url-pattern>/index.html</url-pattern>
> >             <url-pattern>/main.jsf</url-pattern>
> >             <url-pattern>/stylesheet.css</url-pattern>
> >             <url-pattern>/images/*</url-pattern>
> >             <url-pattern>/logOut.jsf</url-pattern>
> >         </web-resource-collection>
> >         <auth-constraint>
> >             <role-name>myrole</role-name>
> >         </auth-constraint>
>
> Does your login page attempt to display any of these files? Perhaps an
> image or your stylesheet? If so, this isn't going to work properly and
> you'll get a bunch of requests that all get sent to the login page after
> a session timeout.
>
> > Here is the access log:
>
> Care to point out when the session expires?
>
> > 192.168.0.110 - admin [02/Dec/2008:17:13:13 +0000] "POST
> > /manager/html/sessions?path=/system HTTP/1.1" 200 5114
>
> It looks like you wait for 15 minutes, here, and then there's another
> request:
>
> > 192.168.0.110 - admin [02/Dec/2008:17:28:01 +0000] "POST
> > /manager/html/sessions?path=/system HTTP/1.1" 200 4436
> > 192.168.0.110 - - [02/Dec/2008:17:28:04 +0000] "GET /sessionTimeout.jsf
> > HTTP/1.1" 200 2614
>
> Was this request for /sessionTimeout.jsf done from your javascript code,
> or by you typing something into the URL bar of your browser?
>
> > 192.168.0.110 - - [02/Dec/2008:17:28:04 +0000] "GET
> >
> /a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf
> > HTTP/1.1" 200 6857
> > 192.168.0.110 - - [02/Dec/2008:17:28:04 +0000] "GET
> >
> /a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/extended_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf
> > HTTP/1.1" 200 4134
> > 192.168.0.110 - - [02/Dec/2008:17:28:04 +0000] "GET
> > /a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js.jsf
> > HTTP/1.1" 200 1164
>
> Are any of the above requests related to the problem you are observing?
>
> > 192.168.0.110 - - [02/Dec/2008:17:28:04 +0000] "GET /favicon.ico
> HTTP/1.1"
> > 200 21630
> > 192.168.0.110 - - [02/Dec/2008:17:28:11 +0000] "POST /j_security_check
> > HTTP/1.1" 400 1100
>
> This is obviously where you get the 400 response. Which request resulted
> in the login page being shown in the first place?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkk1fmgACgkQ9CaO5/Lv0PCddQCgsXyX7KJ5gOZFn2xNeaPPxY3p
> 4Z0AoLbp8FYcs6B+lxx/W/Nl7vKRZTyP
> =5oYE
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message