Great response. Follow-up questions below:
Christopher Schultz-2 wrote:
> When you login using form-based authentication, where invalid login
> attempts
>> redirect to the "form-error-page", how do you add a custom message to
>> that
>> page saying "Login Failed"? I ask because common practice is to send the
>> user to the same login page rather than a different page.
>
> You can do whatever you want, since you get to control the pages for
> login and login-error.
But if the login and login-error pages are the same page (meaning that when
someone fails an access check they get redirected to the login-error page,
which is actually the login page where they must re-enter their credentials)
how could you put information into the request or session scope to be
accessed by the page?
In my login/login-error page, I could have a ${loginFailedMessage} printed
in bold, red text, but where would I set this text in the first place for a
generic message like "Login failed"? The loginFailedMessage variable
wouldn't be set when the login page is accessed through a GET, but would be
when forwarded/redirected to by Tomcat upon login failure.
In fact, how could I add all sorts of state to the request so that the
message could read "Login failed for page ${failedPageName}" or some other
parameterized text?
In fact, I don't much care for the TC implementation of the whole
> authentication thing anyway, so I have opted to dump it and use
> securityfilter instead. Primarily, it allows me to do direct logins
> (submit to j_security_check even when no protected resource has been
> requested), and I can write my own authenticator that isn't tied to
> Tomcat's implementation in any way. That allows me to switch TC versions
> or to another vendor entirely without changing a single thing in my
> implementation. But that's just me.
I agree completely. I've been having a lot of problems with Tomcat
authentication and authorization, and would like to use a custom solution.
The only thing that deters me, and which applies to securityfilter as well,
is the lack of SSO across contexts. Although I don't see an immediate need
for SSO across contexts, I wouldn't want to have to rewrite an entire
security architecture if the need arises. (And it may well arise if you
decide to split up a large website's modules into different contexts.)
The securityfilter projects says they're looking into SSO, but the project
looks inactive enough that I'm not going to hold my breath. I tried looking
for other Java servlet security products or projects, but nothing really
came up.
Any thoughts on this all?
--
View this message in context:
http://www.nabble.com/Authentication-and-authorization-questions-tf4345698.html#a12398683
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
