I have a filter that has a <url-pattern>/*</url-pattern> and a security
contraint of <url-pattern>*.do</url-pattern>, so the filter is hit even when
the container detects a security constraint and redirects to the login
screen. My login-config is as follows:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login.jsp?error=true</form-error-page>
</form-login-config>
</login-config>
The filter checks for request.getRequestURL().indexOf("login.jsp") and if
it's there, it checks for the cookies and redirects to
"j_security_check?j_username=cookieUsername&j_password=cookiePassword - just
like the form does.
Here's the code for the filter: http://tinyurl.com/6jn8
It also checks for the <form-error-page>'s URL and if that's there, it
deletes the cookies, so the user is routed to the form-error-page without
attempting a login.
This might not work in containers that do a forward to the login.jsp -
making it invisible (??) to the filter. But if you're using Tomcat, this is
awesome and has sped up my development time considerably as I never have to
login anymore!
Matt
-----Original Message-----
From: Will Hartung
To: Tomcat Users List
Sent: 3/5/2003 6:56 PM
Subject: Re: remember password HOW-TO?
> From: "Raible, Matt" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 05, 2003 4:36 PM
> Subject: RE: remember password HOW-TO?
> Actually, it *is* using form-based security. I just do a redirect to
> "j_security_check" to mimic how a form's action submits to
> action="j_security_check".
Really?
That certainly is crafty, and I'd like to think that it would work, but
I'm
a bit puzzled. Perhaps someone can clarify these points.
My understanding is that the basic problems with interacting with
Container
based authentication are two fold.
One is that the Servlet API provides no way for a Servlet to actually
set
the UserPrincipal, a Servlet can only access it. As seen by a Servlet,
the
UserPrincipal is an attribute of the Request, not of the Session.
Your technique sort of mitigates this by directing to the container
specific
parts so it can Do Its Thing.
However, my understanding of the path of a request is something like
this:
Request ->
Mapper (determines where this URL should go, servlet, jsp, etc) ->
Container Security (if Mapper points to protected resource, Security
kicks
in) ->
Filters ->
Servlets
I'm under the impression that the Container Security layer is ABOVE the
Filter layer. So, if you have a Container Security Managed resource that
is
also a Filtered Resource, then the Security will hit first before the
Filter
has a chance to do anything (in this example check a cookie and
redirect).
Now, this data flow is not enumerated at all within the spec, at least
not
in a nice blocky diagram. Filters can easily come before the Container
Security, but I would think not as the filter may be doing something
(say an
Access Log filter) for a request that is later denied by Container
Security,
and then the user is passed on to either HTTP or Form based
authentication.
This would also be horribly nasty if for some silly reason the Filter
had
already started committing the response (which it's allowed to do).
So, for simply sanity I'd think all of the Container Security would be
done
far before the Filters start firing.
And I don't know how Container Security interacts with
RequestDispatcher. If
a unsecured request tries a .include or .foreward call. I'm guessing not
at
all.
But, all of this tells me that Container Security is really just a thin
veneer hammered in place between the original request and the rest of
the
Container.
Anyway, I'm not saying your implementation does not work, obviously it
does,
or you wouldn't be using it.
However I would be curious to see your security-contraint tags and
filter-mapping tags.
Regards,
Will Hartung
([EMAIL PROTECTED])
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
