Re: Setting Cookies

2002-06-13 Thread ___cliff rayman___

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?

1999-12-13 Thread Doug MacEachern

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?

1999-11-03 Thread Andrei A. Voropaev

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?

1999-11-02 Thread Wyman Eric Miles


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?

1999-11-02 Thread Greg Stark


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?

1999-11-02 Thread Andrei A. Voropaev

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?

1999-11-01 Thread Robin Berjon

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?

1999-11-01 Thread Doug MacEachern

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?

1999-11-01 Thread Wyman Eric Miles


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?

1999-10-31 Thread Doug MacEachern

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.