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 <[EMAIL PROTECTED]> wrote: "Joerg Heinicke" wrote in message news:[EMAIL 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/[EMAIL PROTECTED]/msg104931.html. > 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
