On Fri, 11 Jan 2002, Gerry Duhig wrote:
> Date: Fri, 11 Jan 2002 19:12:35 -0000
> From: Gerry Duhig <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Securing access to pages
>
> No, I'm not trying to fake it. The original data comes from the user, and
> the container puts up the form (login.htm), but I post from there to
> login.jsp. What I am trying to do then is force my login servlet to run
> immediately after j_security_check.
>
Well, that's part of what I meant by "fake it". :-)
The servlet spec *requires* that the form based login page submit to
"j_security_check" directly. You're violating that requirement, so it's
not really surprising that you see "undefined" behavior.
> The user may have attempted access to any of a dozen html or jsp pages and
> been trapped by the security system and given the login form. I want him to
> fill that in, go through j_security_check then be forced to run my servlet.
>
> Do you know a better way?
>
> It would be perfect if there was a path parameter or "property" to
> j_security_check (where_to_go_after_this).
>
The problem is that the container *already* remembered where to go -- it
automatically goes back and completes the request that the user originally
requested (that triggered the login dialog because it was protected, and
he or she had not authenticated yet). Attempting to override this is a
misuse of the form based login facility, and will cause you nothing but
portability grief -- you'd be better off dispensing with container managed
security entirely and manage it yourself.
>From a user experience point of view, form based login is designed to feel
*exactly* like BASIC login, where the dialog box pops up -- the only
difference is that you get to control the look and feel of the login page.
You will note that there is no opportunity for your servlet to get
originally asked for. That's how form based login is designed to work as
well.
If you need to do some processing when a user first logs on, I would do it
in a Filter that is mapped to your protected URLs. Then, the filter can
assume that the container has authenticated the user, and check the
session attributes to see if it has already initialized this user's
information. If this is the first time, then do whatever setup you need
and store something in the session to indicate that it's been done. Or,
you could even do a RequestDispatcher.forward() to a "login completed"
page if this is the first time -- but I wouldn't really want to piss off
users that way :-).
If you don't care about whether the user has logged in yet or not, another
approach is to use an HttpSessionListener that is notified every time a
session is created (even before login has been completed, if you're using
form based login).
> Gerry
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
