tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lawence <>
Subject Re: Filter for Form Authentication Problem
Date Tue, 30 Sep 2003 19:35:32 GMT
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/
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

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

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 <> wrote:

"Joerg Heinicke" wrote in message
> Tim Funk wrote:
> > You can't intercept j_security_check with a filter, it violates the
> >
> > -Tim
> This is at least one answer to my thread started last week:
> 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 to hopefully get the expert-team
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:
For additional commands, e-mail:

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message