Setting Cookies
Hello folks, Yesterday I posted a question about PerlTransHandler and received a lot of responses. Thanks to all of you who replied. However, my problem persists. I try to be more precise in explaining the problem today. My login module sets a few cookies that expire 24 hrs after they are set. Upon each request the validity of the cookies is checked, and in case of an expired cookie, the user is redirected to the login page to resubmit username/password again. A request with a fully qualified URL, example: http://myserver.mydomain.com/someLocation, has no problem continuing. The cookies are set. However, in case the URL has the .domain.com stripped, the login page is regenerated indefinitely. The cookies never get set. There were a few suggestions, such as using mod_rewrite, however that is out of the question because mod_rewrite was not built with our http server. My PerlTransHandler does not seem to be able to distinguish myserver.domain.com/someLocation request with myserver/someLocation. I appreciate any suggestions on this. -r
Re: Setting Cookies
ok - here is something ugly - off the top of my head. when a user submits without a cookie, or a cookie that u do not recognize: 1) Set-Cookie for the proper domain (i.e. .rhythym.com) 2) redirect them to the requested page, but with a fully qualified host/domain (i.e. http://www.rhythym.com/someLocation/) Rasoul Hajikhani wrote: Hello folks, Yesterday I posted a question about PerlTransHandler and received a lot of responses. Thanks to all of you who replied. However, my problem persists. I try to be more precise in explaining the problem today. My login module sets a few cookies that expire 24 hrs after they are set. Upon each request the validity of the cookies is checked, and in case of an expired cookie, the user is redirected to the login page to resubmit username/password again. A request with a fully qualified URL, example: http://myserver.mydomain.com/someLocation, has no problem continuing. The cookies are set. However, in case the URL has the .domain.com stripped, the login page is regenerated indefinitely. The cookies never get set. There were a few suggestions, such as using mod_rewrite, however that is out of the question because mod_rewrite was not built with our http server. My PerlTransHandler does not seem to be able to distinguish myserver.domain.com/someLocation request with myserver/someLocation. I appreciate any suggestions on this. -r -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: setting cookies?
On Mon, 1 Nov 1999, Robin Berjon wrote: At 11:44 01/11/1999 -0800, Doug MacEachern wrote: On Mon, 1 Nov 1999, Wyman Eric Miles wrote: The next question is, when the cookie expires 2 hours later, the initial SecurID user/password has long since expired. How do I cause the module to force the basic auth dialogs again? $r - note_basic_auth_failure; return AUTH_REQUIRED; Doesn't seem to work. that's cause netscape, ie, etc, cache basic credentials. so even though a 401 code is sent to the client, they just reuse the existing username/password in memory. I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? yeah, except that clicking 'cancel' causes the browser to send the cached credentials. at least, that was my experience last I tried.
Re: setting cookies?
No. This is not true. If browser gets 401 in response to request with user authentication then it pops up the dialog box. And only if user clicks "Cancel" then it displays the Authentication failed document. Only if you send 403 then browser will not prompt user for new user name and password. At least it works this way with IE and Netscape. Andrei On Tue, Nov 02, 1999 at 02:29:10PM -0500, Greg Stark wrote: I think if you send a 401 in response to a request that contained auth data the user will typically see a "Authentication failed" box, which may look bad compared to just getting the password dialog. Actually I couldn't get this to work a while back, but I didn't try very hard. "Andrei A. Voropaev" [EMAIL PROTECTED] writes: On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? I feel like this topic gets slightly confusing. Browser sends request, gets 401 back, asks user for username and password if it doesn't have one cached already. If it has one cached for this particular realm then it attempts to send the cached values. If in response it gets 401 again then it asks user for new username and password for this realm. As far as I know it always takes 2 requests to get protected document. First one returns with 401 code and realm for authentication, second request is done with appropriate user name and password. So if for some reason you decide that some user name and password is not valid any more then you should make sure that if they are sent any number of times later then your authentication handler says no always. Andrei -- -- greg --
Re: setting cookies?
On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? I feel like this topic gets slightly confusing. Browser sends request, gets 401 back, asks user for username and password if it doesn't have one cached already. If it has one cached for this particular realm then it attempts to send the cached values. If in response it gets 401 again then it asks user for new username and password for this realm. As far as I know it always takes 2 requests to get protected document. First one returns with 401 code and realm for authentication, second request is done with appropriate user name and password. So if for some reason you decide that some user name and password is not valid any more then you should make sure that if they are sent any number of times later then your authentication handler says no always. Andrei --
Re: setting cookies?
I think if you send a 401 in response to a request that contained auth data the user will typically see a "Authentication failed" box, which may look bad compared to just getting the password dialog. Actually I couldn't get this to work a while back, but I didn't try very hard. "Andrei A. Voropaev" [EMAIL PROTECTED] writes: On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? I feel like this topic gets slightly confusing. Browser sends request, gets 401 back, asks user for username and password if it doesn't have one cached already. If it has one cached for this particular realm then it attempts to send the cached values. If in response it gets 401 again then it asks user for new username and password for this realm. As far as I know it always takes 2 requests to get protected document. First one returns with 401 code and realm for authentication, second request is done with appropriate user name and password. So if for some reason you decide that some user name and password is not valid any more then you should make sure that if they are sent any number of times later then your authentication handler says no always. Andrei -- -- greg
Re: setting cookies?
Success! The problem is, the tokencode sent by the user expires the instant its validity is determined. That the browser caches this and returns it over and over is not only a nuisance, it can cause the SecurID server to disable the token. Problem was, the client kept coughing up an invalid cookie which was checked, deemed invalid, and the AUTH_REQUIRED sent back. Just made a loop the module could never escape. Now I (correctly) hand expired cookies off to the SecurID portion of our show, which forces another basic auth. At any rate, point is, two 401s in quick succession will throw an authorization failed message at the user, then prompt for a new username/password. I haven't had a user who didn't understand, in some vague way, that his surfing had come to an end and he'd have to fish the tokencard out one more time. Thanks! Wy On 2 Nov 1999, Greg Stark wrote: I think if you send a 401 in response to a request that contained auth data the user will typically see a "Authentication failed" box, which may look bad compared to just getting the password dialog. Actually I couldn't get this to work a while back, but I didn't try very hard. "Andrei A. Voropaev" [EMAIL PROTECTED] writes: On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? I feel like this topic gets slightly confusing. Browser sends request, gets 401 back, asks user for username and password if it doesn't have one cached already. If it has one cached for this particular realm then it attempts to send the cached values. If in response it gets 401 again then it asks user for new username and password for this realm. As far as I know it always takes 2 requests to get protected document. First one returns with 401 code and realm for authentication, second request is done with appropriate user name and password. So if for some reason you decide that some user name and password is not valid any more then you should make sure that if they are sent any number of times later then your authentication handler says no always. Andrei -- -- greg Wyman Miles Senior Systems Administrator, Rice University, Texas. (713) 737-5827, e-mail:[EMAIL PROTECTED], pager:[EMAIL PROTECTED]
Re: setting cookies?
I should have realized that. I managed to architect a kludge that sets the cookie but causes a fragment of the HTTP header to appear in the browser the first time. For now, I'm content with it. The next question is, when the cookie expires 2 hours later, the initial SecurID user/password has long since expired. How do I cause the module to force the basic auth dialogs again? $r - note_basic_auth_failure; return AUTH_REQUIRED; Doesn't seem to work. On Sun, 31 Oct 1999, Doug MacEachern wrote: On Mon, 18 Oct 1999, Wyman Eric Miles wrote: System: Solaris 2.6 Apache 1.3.9/mod_perl 1.19/gcc 2.8.1/perl-5.004.04 I'm using SecurID to authenticate for an Apache proxy server. I've written a little perl module that uses a username/tokencode returned by basic auth to validate a user and return a session cookie. The SecurID auth works fine and I'm able to generate a cookie for the user. The problem is, I can't get the module to return the cookie to the browser before the proxy request is completed. mod_proxy doesn't look at r-headers_out table, it just passing along the headers from the downstream server. Wyman Miles Senior Systems Administrator, Rice University, Texas. (713) 737-5827, e-mail:[EMAIL PROTECTED], pager:[EMAIL PROTECTED]
Re: setting cookies?
On Mon, 1 Nov 1999, Wyman Eric Miles wrote: I should have realized that. I managed to architect a kludge that sets the cookie but causes a fragment of the HTTP header to appear in the browser the first time. For now, I'm content with it. The next question is, when the cookie expires 2 hours later, the initial SecurID user/password has long since expired. How do I cause the module to force the basic auth dialogs again? $r - note_basic_auth_failure; return AUTH_REQUIRED; Doesn't seem to work. that's cause netscape, ie, etc, cache basic credentials. so even though a 401 code is sent to the client, they just reuse the existing username/password in memory.
Re: setting cookies?
At 11:44 01/11/1999 -0800, Doug MacEachern wrote: On Mon, 1 Nov 1999, Wyman Eric Miles wrote: The next question is, when the cookie expires 2 hours later, the initial SecurID user/password has long since expired. How do I cause the module to force the basic auth dialogs again? $r - note_basic_auth_failure; return AUTH_REQUIRED; Doesn't seem to work. that's cause netscape, ie, etc, cache basic credentials. so even though a 401 code is sent to the client, they just reuse the existing username/password in memory. I've never tried this but doesn't sending two 401s in a row for the same document have the auth popup appear again ? .Robin Radioactive cats have 18 half-lives.
Re: setting cookies?
On Mon, 18 Oct 1999, Wyman Eric Miles wrote: System: Solaris 2.6 Apache 1.3.9/mod_perl 1.19/gcc 2.8.1/perl-5.004.04 I'm using SecurID to authenticate for an Apache proxy server. I've written a little perl module that uses a username/tokencode returned by basic auth to validate a user and return a session cookie. The SecurID auth works fine and I'm able to generate a cookie for the user. The problem is, I can't get the module to return the cookie to the browser before the proxy request is completed. mod_proxy doesn't look at r-headers_out table, it just passing along the headers from the downstream server.
