> Date: Sun, 6 Jun 1999 13:19:44 +0100
> From: Nic Ferrier <[EMAIL PROTECTED]>
> Subject: Re: Http Basic Re-Authentication
>
> >> The point of authentication, should be to get away from cookies
> (at least in my mind). We only use
> >> cookies/sessions to identify the user. The users state information
> is always kept on the server (ie
> >> lite cookies).
>
> As Craig said, this is wrong. Why should authentication get you away
> from cookies?
>
> Ok, if you don't want to use Cookies then use session url
> re-writing.
Ack. I'll not get into why URL re-writing is not a good choice.
> Authentication Cannot Replace Sessions
> Partly because authentication doesn't usually time out, though you
> could make it time out.
> Mainly because a user could log on to 2 machines and you wouldn't be
> able to uniquely identify each session.
> Of course you may not need to do this. But it is important.
This is an important point. Sessions do have this advantage. With this point aside,
one could build
a system similar to sessions that used HTTP authentication. (We built our own session
system in JSDK
1.0 before there was a Session API.)
Sessions and Cookies are virtually the same when you take on the browser perspective.
From the
browser point of view a block of data is included with each request. In both cases
that block
identifies the user (in the session case the user and the browser). Sessions have one
other
advantage in only identifying the browser. It allows unauthenticated state to be
maintained.
I would be interested in other possible solutions to using authentication instead of
Sessions. The
problem as you point out is how to discern the same user on multiple browsers.
> Original Problem
> You don't have to use a session to signal a change in
> authentication.
> If you read my original mail carefully you will see that all you need
> to do is send UNAUTHORIZED response.
> All you need to do is get the servlet into a _state_ whereby it sends
> this response.
Is this really true? I havent tried it myself. If I send an UNAUTHORIZED to a user
upon pressing
logout, I can see that this will cause the authentication dialog to appear, but what
if they just
cancel and re-request the page? Doesnt the browser just send the authenication
information again?
The question is does sending UNAUTHORIZED really cause the browser to remove the
credentials?
> But Sessions Are A Good Idea
> It's even easier though if you use sessions - this is one of the
> reasons they're in the API.
Yes, sessions are easy and we presently use them. The problem is there are still those
people who
dislike cookies (no we wont use URL rewriting). Another oddity is the authentication
dialog. People
are comforted by it and its "convenience". (They can press enter instead of using the
mouse.
(foolish browsers!))
Thanks for your ideas, this is very enlightening.
(I hope I have not taken this discussion away to far from the original question.)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ClueIn - The Internet's FREE Community Service.
Go to http://www.cluein.com and experience the most dynamic way to communicate with
groups of people! You are limited only by your imagination. This service is yours to
use free. Clue in now.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
