Thanks for the replies.
So this means I have to go with custom realm and authenticator? Actually I first tried with them but got stuck, I guess I was quite close to success though. I posted one article asking for help several days ago but got no response at all. I am reposting it below, hopefully sb. would kindly point me a way out.
===============================================================
Dear all,
I wrote my own authenticator (extends FormAuthenticator) & realm (extends JDBCRealm). What I need is to check one more field in the database besides password for authentication. Only minor modifications are made on the original codes so I think it should be fine. What I also did include changing the org/apache/catalina/startup/Authenticators.properties
file to add the new authenticator; modifying the server.xml and web.xml accordingly. Furthermore, I added the entries for my authenticator and realm in the mbeans-descriptor.xml file.
I expected everything to work perfectly but when I tried to access the secured area, I got the following error:
HTTP Status 500 - Configuration error: Cannot perform access control without an authenticated principal
---------------------------------
type Status report
message Configuration error: Cannot perform access control without an authenticated principal
description The server encountered an internal error (Configuration error: Cannot perform access control without an authenticated principal) that prevented it from fulfilling this request.
This error was triggered instantly. I mean I even did not have a chance to see the login webpage. Now I have several questions:
What is the flow of the authentication? Was my authenticator got executed at all?
Any suggestions would be greatly appreciated.
================================================================
Bill Barker <wbarker@(protected):
"Joerg Heinicke" wrote in message
news:3F78CEC3.60508@(protected)...
> Tim Funk wrote:
> > You can't intercept j_security_check with a filter, it violates the
spec.
> >
> > -Tim
>
> This is at least one answer to my thread started last week:
> http://www.mail-archive.com/tomcat-user@(protected).
> What are the consequences/possibilities to set the request character
> encoding with servlet standard API mechanisms instead of using the
> Tomcat proprietary solution of using a Valve?
>
This is a really interesting issue. I would hope that you would send a
message to servletapi-feedback@(protected)
to clarify this before the 2.4 spec goes final. Because the Servlet-2.2
spec lacks the request.setCharacterEncoding method, Tomcat 3.3 jumps through
a lot of hoops to try and guess the charset. These were dropped in Tomcat
4+, since the request.setCharacterEncoding method was supposed to solve all
of these problems. As you have pointed out, it is not possible to use this
in a Filter for the standard Form-auth config (for the simple reason that
Auth is called before Filters). Therefore, the j_security_check target is
flying blind wrt charset.
> Joerg
>
> > Lawence wrote:
> >
> >> Dear All,
> >>
> >> I wrote a filter servlet that does some preprocessing. Basically it
> >> intercepts the call of j_secuity_check. The problem is that most of
> >> the time it was just bypassed. The only way to trigger it as I found
> >> is to first fill the form and got authenticated, then go back and try
> >> the authentication again. Anybody knows the solution?
> >> Another question is how to sepcify the url pattern of
> >> j_security_check. My login page is /secured/login.jsp, I think the
> >> url should be /secured/j_security_check, am I right?
> >>
> >> Thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
