tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: j_security_check
Date Thu, 04 Dec 2008 20:16:18 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

Martin Dubuc wrote:
> I will describe the browser interactions with regards to the access logs.

Thanks, this was helpful.

> My assumption is that clicking on OK caused the client to be
> redirected to sessionTimeout.jsf.

I think you mean that the browser simply requested sessionTimeout.jsf,
rather than being redirected. The response was 200, which means that it
should have been successfully serviced. I think recent Tomcats return
200 when the login-page is shown, though, so it's tough to tell exactly
what happened.

Requests for the following resources seemed to happen simultaneously
(probably from the original page being loaded):

/a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf
/a4j/s/3_2_2.SR1org/richfaces/renderkit/html/css/extended_classes.xcss/DATB/eAF7sqpgb-jyGdIAFrMEaw__.jsf
/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js.jsf
/favicon.ico HTTP/1.1

None of those should have caused the login page to be displayed, either
(which wouldn't have happened anyway, since it would have been included
in the main content, rather than being the response to the initial request).

> 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.

Are you sure you don't have any other <security-constraint> sections in
your web.xml?

> 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).

That'll do it ;)

> - The sessionTimeout.jsf was triggered from JavaScript.

Okay, so this simply requests /sessionTimeout.jsf after the session
should have timed out. This should behave exactly as if you manually
typed-in /sessionTimeout.jsf into your browser. Remember to run that URL
through response.encodeURL() before putting it into your Javascript,
just in case your client isn't using cookies.

> - The login page does not access any of the protected resources (it doesn't
> use the stylesheet, nor any images).

Ok.

> - 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.

You can easily convince yourself that your login expired because you are
asked to login again ;) Not sure why you have to, but at least you know
your session is gone.

> - 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.

Ok.

Can you post more of your web.xml?

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk4OpIACgkQ9CaO5/Lv0PC3vgCdHtyFdztw6px/s35pmI6rzep7
2WEAniK8Oh49jZCcoitk0Z3ks79RT/Fb
=LCGJ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message