Basically, but you missed this:
If you use *form* authentication the password/user isn't cached at the
browser. If you use *basic* authentication then it is.
Form authentication is built into Tomcat et al. If you use Basic
authentication (aka the little dialog popping up) then it is stored in the
browser indefinitely (usually until it is closed).
Workflow of a Form based authentication:
You request a protected page
You have no session cookie
Tomcat sends you to the authentication form
You enter your user and password and click submit
It posts to j_security_check action
Tomcat sends you a session cookie
Tomcat forwards you to the correct page
You request another protected page while your cookie is valid
Tomcat sends you to the page skipping the rest
Your cookie expires or is invalidated, repeat from the top...
Basic Authentication:
Same thing but no form, browser dialog and the BROWSER automatically resends
the user id and password when asked. Meaning it never asks again until you
close the browser.
-Andy
> From: "Richard O. Hammer" <[EMAIL PROTECTED]>
> Reply-To: "Research Triangle Java User's Group mailing
> list."<[EMAIL PROTECTED]>
> Date: Wed, 07 Apr 2004 16:26:32 -0400
> To: "Research Triangle Java User's Group mailing list."<[EMAIL PROTECTED]>
> Subject: Re: [Juglist] HttpServletRequest.getRemoteUser() and Http
> Authentication
>
> Thank you Lee.
>
> I still have not solved my original question as repeated at the bottom
> of this post. But I'm learning a little bit.
>
> Let me describe what I suspect is going on. I hope that more savvy
> readers will correct any errors they see in the following element.
>
> <I_JUST_MADE_THIS_UP truth="~62%">
>
> HTTP Authentication, whether form-based or basic, is
> separate from sessions. Authentication and sessions
> evolved separately.
>
> Once authentication has happened, knowledge of this
> authentication is kept in the client, not the server.
> The client communicates authentication data to the
> server on each request in the authorization header of
> the HTTP request. HTTP authentication probably never
> times out, but that's up to the client.
>
> A server-side Java programmer has access to the
> authenticated username (decoded and fetched from the
> authorization header) through the
> HttpServletRequest.getRemoteUser() method. But this
> programmer finds no way to set, void, or timeout the
> authenticated username kept in the client.
>
> A session (with data kept on the server) can be
> invalidated or set to timeout. But this will not
> affect the authenticated username which will continue
> to be sent by the client.
>
> Of course a server-side Java programmer can bypass
> HTTP authentication and write his own authentication
> code which keeps its stuff in a session, a session which
> can be timed out or invalided at the server-side
> programmer's will.
>
> </I_JUST_MADE_THIS_UP>
>
> So, savvy readers, what mistakes have I made there?
>
> Thanks,
> Rich Hammer
>
>
> Lee Haslup wrote:
>> Rich,
>>
>> Usually, if you have a webapp where the user logs in using different
>> IDs there will be some sort of logout action that is initiated by the
>> user (clicking logout, etc.) that results in the session being
>> explicitly invalidated. ( request.getSession().invalidate() ) You can
>> save the extra step, from the user's point of view, by having this be
>> the first thing the login screen does if it sees the remnants of an old
>> session (often something like
>> request().getSession().getAttribute("userId") but this will depend on
>> your login code.) Setting the "timeout" on the session doesn't usually
>> help with the problem of multiple userIds from a single browser
>> execution since it makes the invalidation event happen at a somewhat
>> arbitrary time (not likely to be when you need it.)
>>
>> It occurs to me that I am assuming you are using form-based
>> authentication but I think that this works with basic authentication as
>> well.
>>
>> I did a bit of Googling for "tomcat session timeout" and for
>> "form-based-authentication servlet" and came up with several threads
>> that seemed useful, notably
>> http://www.experts-exchange.com/Web/Web_Servers/Apache/Q_20878998.html
>> http://www.jguru.com/forums/view.jsp?EID=504163
>> and
>> http://www.jguru.com/forums/view.jsp?EID=524485
>>
>> Hope this helps.
>>
>> Lee
>>
>> Richard O. Hammer wrote:
>>
>>> Is there some way that I can cancel or timeout an HTTP authentication?
>>>
>>> I would like to use HTTP authentication to log into my webapp -- first
>>> as one user and then as another user -- both from within one running
>>> instance of a browser window. But what I have discovered so far seems
>>> to suggest that a browser, once logged into a domain, will always
>>> continue to send the same authorization header.
>
>
> _______________________________________________
> Juglist mailing list
> [EMAIL PROTECTED]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org
