Victor,
You're correct in looking at these methods but the fact that they are in
HttpServletRequest interface (as opposed to what, HttpSession?)
is irrelevant.
The latter two methods depend on getRemoteUser -- if it returns null (no
user has been authenticated) then they return false and null respectively.
These two are really convenience methods; they use getRemoteUser as a start
and know nothing about authentication.
getRemoteUser is problematic. The 2.2 spec is ambitious (to put it mildly)
in that it wants getRemoteUser to work across different authentication
mechanisms incl. HTTP Basic/Digest authentication, HTTPS client auth (client
certificate) and form-based authentication.
If basic/digest auth is used I don't believe it's possible to make the
browser forget this (i.e. you can't have a "hard" logout). There are some
clever workarounds with sending the Auth headers back again but I
don't think you want to go there nor have I seen this approach actually work
in all browsers. Check the archives for more info as this particular topic
has been discussed early on.
If client certificates are used then you're out of luck at the application
level as far as "de-authentication" goes. I don't
remember if it's even possible at all (at the container level).
To repeat: the spec is ambitious and I would like to see a container that
will do this. I am betting there won't be one anytime soon just as there
isn't a container that uses SSL session ID to track HTTP sessions in SSL
environment. (That last one would be real nice as it would absolve the
application from both cookies and URL rewriting...but the application would
have to be only HTTPS from get-go and stay that way).
In other words the declarative security in 2.2 spec will work best (or work
at all?) when used in conjunction with form-based authentication AND cookies
would be used to track the session. The spec admits this in section 11.5.3.1
("Login form notes").
It also mentions that since authentication will be applied in uniform
fashion to many resources of which a particular web application is only a
single instance, the authentication information will be have to be kept at
the container level. This contradicts what I said about invalidating the
session (hasty reply that was) but I believe that in order to implement the
logout scheme the container will have to listen for session.invalidate().
Actually it looks like the spec might use another paragraph to explain this.
Container writers/Sun: please comment on the paragraph above!
This is an excellent question for advanced-servlets list (announcement
coming very soon). Advanced-servlet folks: sounds like a good first thread
-- feel free to chime in here...
Hope this helps,
Alex
----Original Message Follows----
From: Victor Miksonov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: How to logout in case of lazy login
Date: Mon, 31 Jan 2000 11:19:18 -0800
Servlet API 2.2 specifies that getRemoteUser, isUserInRole, and
getUserPrincipal are methods of *HttpServletRequest* interface. A servlet
designer can try to use these metods when there is no HttpSession object
created, so it would be incorrect to assume that invalidating non-existing
session will help to initiate a logout
for a specific user.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
___________________________________________________________________________
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
