On Mon, 22 Apr 2002, Benjamin Drasin wrote:
> Date: Mon, 22 Apr 2002 22:06:25 +0000
> From: Benjamin Drasin <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Do I have to use j_security_check to authenticate?
>
> Hello all-
>
> I have a servlet based application running on Tomcat 3.2. It uses a
> homespun security system which I would like to replace with standard J2EE
> security. However, when the user logs in there are a number of server-side
> tasks which have to be performed both before and after authentication takes
> place, and which logically and functionally are all part of the login
> process.
>
> Therefore it is a problem for me that, as best I can tell from availible
> documentation, all authentication is done through the magic URL
> "/j_security_check" which is opaquely handled by the application server.
>
> I have seen some suggestions on newsgroups that I should hack my way around
> this by having my own servlet code forward to /j_security_check after doing
> my own processing, but
> 1)this is not really what I want because some of the work I have to do
> should not take place until after authentication, and
> 2)that seems like a collosal hack that might have ramifications I don't know
> about.
>
> What I really want is a server-side method like authenticate(username,
> password) which would be functionally the same as submitting to
> /j_security_check. Does any such thing exist, and where can I find out
> about it?
There is no such API that is portable across containers. If your
container supports it, JAAS is probably as close as you can get (for
Tomcat, that would mean using JAASRealm in the nightly builds), but
nothing is perfect.
> If not, can anyone suggest an alternative?
>
In a servlet 2.3 container, you can define a session listener that is
notified when new sessions are created. However, the notification does
not include the current request (indeed, it cannot -- sessions can be
created outside of the context of a request), so you won't be able to find
out who the newly logged on user is.
One approach would be to use a Filter that recognized the newly set up
session (because the session created listener placed a special attribute
there), and performed all the "logon setup" stuff based on the value
returned by request.getRemoteUser() or request.getUserPrincipal() if it
has not been done yet.
> Thanks in advance,
>
> Ben Drasin
>
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
