AuthCookie won't help you here, it still sends a cookie back to the client.
Whatever you do, you will need to modify the response to the client to contain a
session id somewhere where you can get it back.
From what you've said, you will need to modify the url in some way. It
doesn't matter whether you store information in a server-side store or in
the session key itself, you still need to stick it in the url somewhere
and make sure that all relative links contain that key.
Is there a handler out there that can munge relative urls in this way for
static pages, perhaps as part of an Apache::Filter chain ?
HTH,
S.
From "Ian Frawley" <[EMAIL PROTECTED]>
Date 17 October 2000
To
Simon Wilcox/BASE/WilliamsLea@WilliamsLea, Time 21:30
[EMAIL PROTECTED]
Copy to
Bcc
Fax to
Subject Re: Remembering Authentication
The problem for me with cookies is the fact that we are going to be serving WAP
phones that don't like cookies for obvious reasons.
The only thing I can think of is using server side cookies that are destroyed at
the end of the user session. Perhaps relating the server side cookie to a
Session ID storing the users password and username to compare against.
The problem with this is that I can't seem to install the AuthCookie module from
cpan. DOH!!!
Ian
----- Original Message -----
From: [EMAIL PROTECTED]
To: Ian Frawley
Cc: [EMAIL PROTECTED]
Sent: Tuesday, October 17, 2000 10:05 AM
Subject: Re: Remembering Authentication
Ian,
Using cookies is just one way of overcoming the stateless nature of
http.
The other ways that I know of are to modify the url in some way or to
put
a hidden field in a form.
The latter only works if you're processing forms of course so for
general
viewing, you need to modify the URL. There are two ways that I have
heard
about.
1. modify the url to include a session key in the path. To serve html
pages you'd need to write a custom content handler to rewrite all your
outgoing page links to include the session key. I haven't seen one on
CPAN, please let me know if you find one, I could use it too !
2. authenticate the users and then redirect to a fake host
session.www.somecorp.com/page/you/wanted/. Then you use a custom handler
at the translation phase to strip the session key and recover the user
name from whatever session store you're using.
I haven't got beyond cookies myself but these are both avenues I need to
explore in the next few months.
HTH,
Simon Wilcox
From "Ian Frawley" <[EMAIL PROTECTED]>
Date 17 October 2000
To
[EMAIL PROTECTED] Time 19:20
Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)
Bcc Simon Wilcox/BASE/WilliamsLea
Fax to
Subject Remembering Authentication
Hi all
Is it possible to authenticate a user without having to use the unfriendly
login
box provided by browsers, without using cookies?
I have managed to authenticate a user once through some text fields on a HTML
page but unfortunately this does not make the browser remember the user's
authentication information. On subsequent requests to the same secure area
apache requires that the user enters their credentials again.
Is there a way around this? If so any help would be appreciated.
Thanks
Ian
-------------------------------------------------------------------------
-----
______________________________________________________________________
This email contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an
addressing
or transmission error has misdirected this email, please notify the author
by
replying to this email. If you are not the intended recipient you must not
use, disclose, distribute, copy, print, or reply on this email.
|
The problem for me with cookies is the fact that we
are going to be serving WAP phones that don't like cookies for obvious
reasons.
The only thing I can think of is using server side
cookies that are destroyed at the end of the user session. Perhaps
relating the server side cookie to a Session ID storing the users password and
username to compare against.
The problem with this is that I can't seem to
install the AuthCookie module from cpan. DOH!!!
Ian
|
______________________________________________________________________ This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or reply on this email.
