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.
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.
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
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.
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
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.
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
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
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
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?
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
11 matches
Mail list logo
