Re: how to flush cache of authenticated users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken, Ken Moore wrote: We use basic authentication for web services. I'd like to flush the cache when the password is changed. Do you mean that you want to force your users to re-login when they change their passwords? I've been looking through the doc and code and I've not yet found the cache or a way to flush it. The cached value is really associated with the session. So, if you invalidate the session, you will destroy this cache. Since the browser will continue to send the (old) HTTP AUTH header, Tomcat will likely react by vetoing the re-login and respond with a WWW-Authenticate response header. The browser will then ask the user for credentials (the familiar pop-up username/password dialog) and the user should be re-logged-in. If this isn't happening smoothly, you can issue a 401 response and include a WWW-Authenticate header manually (along with a session invalidation) to attempt to force a re-request of the user's credentials. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeEqF9CaO5/Lv0PARAnaDAJ9l8d8w9RS9GyoiauS854v1DzIbaACggkwA J9jFbniNwNu6yQP82duWhyk= =icOa -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how to flush cache of authenticated users
Hi Christopher, Thanks! I thought it might be stored in the session. Our web app mainly supports web services. We are pretty much stateless on the app server and don't have the notion of logging in. We don't explicitly do anything with sessions. Instead, we use basic authentication and the credentials are supplied with each web service request, in the standard http headers. The clients are not browsers, they are other applications. If a password is changed, we need to ensure that any web service requests sent in with old password are rejected. I wonder if I've misunderstood the nature of the caching mentioned in the realm how-to doc. It sounds as if the login module might be invoked for each web service request. At any rate, it is time for me to do some more digging and investigation. Thanks again. -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 2:29 PM To: Tomcat Users List Subject: Re: how to flush cache of authenticated users -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken, Ken Moore wrote: We use basic authentication for web services. I'd like to flush the cache when the password is changed. Do you mean that you want to force your users to re-login when they change their passwords? I've been looking through the doc and code and I've not yet found the cache or a way to flush it. The cached value is really associated with the session. So, if you invalidate the session, you will destroy this cache. Since the browser will continue to send the (old) HTTP AUTH header, Tomcat will likely react by vetoing the re-login and respond with a WWW-Authenticate response header. The browser will then ask the user for credentials (the familiar pop-up username/password dialog) and the user should be re-logged-in. If this isn't happening smoothly, you can issue a 401 response and include a WWW-Authenticate header manually (along with a session invalidation) to attempt to force a re-request of the user's credentials. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeEqF9CaO5/Lv0PARAnaDAJ9l8d8w9RS9GyoiauS854v1DzIbaACggkwA J9jFbniNwNu6yQP82duWhyk= =icOa -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to flush cache of authenticated users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken, Ken Moore wrote: Thanks! I thought it might be stored in the session. The servlet specification does not dictate where this information is stored. Since the spec does not state this, Tomcat intentionally does not store the information in the session. But you could expect that a session is more or less directly related to this information. Our web app mainly supports web services. We are pretty much stateless on the app server and don't have the notion of logging in. We don't explicitly do anything with sessions. It is very possible that sessions are being used without your knowledge. For instance, Tomcat /may/ use a session so that your credentials work. It may also use a JSESSIONID cookie without an actual session or something else entirely. JSPs and some other components can sometimes inadvertently create sessions. You might consider creating an HttpSessionListener to log session creations (with a stack trace) to see where they might be being created, if at all. Instead, we use basic authentication and the credentials are supplied with each web service request, in the standard http headers. The clients are not browsers, they are other applications. If a password is changed, we need to ensure that any web service requests sent in with old password are rejected. This makes a lot more sense. I wonder if I've misunderstood the nature of the caching mentioned in the realm how-to doc. It sounds as if the login module might be invoked for each web service request. At any rate, it is time for me to do some more digging and investigation. Generally, Tomcat will only validate the credentials once for a particular session. The WWW-Authenticate header will probably be compared to the cached value that includes a flag that says yep, these creds have already been validated, so validation only occurs that one time. If you are issuing a WWW-Authenticate header to a web service, there's nothing for it to ask of a user, so my suggestion is probably worthless for your needs. Invalidating the session object itself /should/ work, but if HttpServletRequest.getSession(false) returns null, then I'm out of ideas ;) Good luck. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeFTW9CaO5/Lv0PARAnRtAJ9kVmTO6bLTp6OzvNPWEqDNUAPh2ACdGpks cuneNLDe87cKEOjEuKJwBcg= =8kiy -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to flush cache of authenticated users
What kind of authentication do you use?? Session or Cookies or others? On Tue, 19 Jun 2007 14:18:16 -0700 Ken Moore [EMAIL PROTECTED] wrote: The Realm Configuration HOW-TO doc ( http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html ) says that: Once a user has been authenticated, the user (and his or her associated roles) are cached within Tomcat for the duration of the user's login. and for BASIC authentication, that means until the user closes their browser We use basic authentication for web services. I'd like to flush the cache when the password is changed. I've been looking through the doc and code and I've not yet found the cache or a way to flush it. Anyone know where it is? 吴熊敏 [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
