Programming a timeout into Apache
Hi: I am adding code to Apache 2.0 to provide a timeout for all authenticated content. I have everything working, but because browsers use cached credentials, I cannot be sure that the user re-authenticated or the browser re-authenticated. I change the realm name and do a HTTP_UNAUTHORIZED response to trick the browser into prompting the user. However, if the user types the password in wrong or cancels the authentication process, I cant be sure that the next successful authentication came from my original HTTP_UNAUTHORIZED response or not. Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that its authenticating to? Any other ideas or approaches to this problem would be appreciated. Thanks, Brian S. Wallace Oak Ridge National Laboratory P. O. Box 2008, MS 6025 Oak Ridge, Tennessee 37831-6025 Voice (865) 576-3193 Fax (865) 241-4000
Re: Programming a timeout into Apache
On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache Not that I know. And this list is mrore for the development of apache so not sure if this is the right place. or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. Approaches I've used: * prefix the path with a random string; and only ask for an auth beyond that string. Most browsers will not try to use the password; or happily flash the popup box when a new prefix is seen. The timeout is simply (in my case) based on an MD5 of a secret, the clients IP address, the time of issue followed by a plaintext time itself. When the timeout comes the module accepts the connection; accepts the password as usual but does a redirect to a new prefix. * use the password in a form to set a crypto cookie or forward to a random page (i.e. postfix with a /counter++) and ask auth there (digest perhaps). If you must do it as your own module you can rip some ideas out of the 2.0 code or out of http://www.apache.org/~dirkx/mod_auth_jabber/ * for the truly evil (and I've only done this only in intranet situation; not sure how wise this is on an internet); put in a wildcard DNS entry; use server alias and use trick a with a random prefix in the FQDN. This fixes the issue with some corperate IE vrsions which also offer up the NT real username/passwd unsolicited. Dw
Re: Programming a timeout into Apache
On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. The are many tricks depending on the specific version of the specific browser. There is no way that I know of to reliably instruct browsers to forget a password. A google search will find many discussions of this topic. If you need to provide a reliable logout, you need to role your own sessions using that broken thing we call cookies or some other session technique. Further discussion should go to [EMAIL PROTECTED] Joshua.
RE: Programming a timeout into Apache
Thanks to all, I will move the discussion to [EMAIL PROTECTED] -Original Message- From: Joshua Slive [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 2:37 PM To: [EMAIL PROTECTED] Subject: Re: Programming a timeout into Apache On Tue, 31 Aug 2004, Wallace, Brian S. wrote: Are there any tricks that can be done like telling the browser to clear the password cache or have the browser return the realm name that it's authenticating to? Any other ideas or approaches to this problem would be appreciated. The are many tricks depending on the specific version of the specific browser. There is no way that I know of to reliably instruct browsers to forget a password. A google search will find many discussions of this topic. If you need to provide a reliable logout, you need to role your own sessions using that broken thing we call cookies or some other session technique. Further discussion should go to [EMAIL PROTECTED] Joshua.
