You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Lawence <al...@yahoo.com> on 2003/09/30 00:12:09 UTC
Filter for Form Authentication Problem
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.
---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
Honestly, I personally have no clue with respect to encoding issues. I will
be playing with UTF-8 soon but ala, I am stuck in ISO8859-1 for now.
But my gut feel is container authentication implementation is purely
container dependent. So you'll be stuck with tomcat, or weblogic, or ???.
Hopefully, the dependency will be very simple and lightweight to ease the
portability issue.
If you have a lot of time to waste, I think there and many "resolved" issues
in bugzilla with some probably interesting conversations.
Hopefully someone else is lurking and has more insight.
-Tim
Joerg Heinicke wrote:
> 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@jakarta.apache.org/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?
>
> Joerg
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
Honestly, I personally have no clue with respect to encoding issues. I will
be playing with UTF-8 soon but ala, I am stuck in ISO8859-1 for now.
But my gut feel is container authentication implementation is purely
container dependent. So you'll be stuck with tomcat, or weblogic, or ???.
Hopefully, the dependency will be very simple and lightweight to ease the
portability issue.
If you have a lot of time to waste, I think there and many "resolved" issues
in bugzilla with some probably interesting conversations.
Hopefully someone else is lurking and has more insight.
-Tim
Joerg Heinicke wrote:
> 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@jakarta.apache.org/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?
>
> Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
See the tomcat-dev list archives, there are conversations about that now.
(or the last day or 2)
-Tim
Adam Hardy wrote:
>
> Do you know when the 2.4 spec goes final?
>
> Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
That bugzilla issue only addresses filters, not character encoding, with
j_security_check.
On the one hand the servlet 2.4 spec actually addresses response
character encoding issues nicely, with the addition of stuff like:
<locale-encoding-mapping-list>
<locale-encoding-mapping>
<locale>ja</locale>
<encoding>Shift_JIS</encoding>
</locale-encoding-mapping>
</locale-encoding-mapping-list>
to the web.xml .
It would be a shame if the solution doesn't extend to the request
encoding as well, i.e. so that the tomcat SetCharacterEncodingFilter
class becomes redundant, but at this point I haven't got to the point
where I can tell. I guess the tomcat committers would know :)
I only upgraded to tomcat 5 on Sunday and I'm still trying to get back
to the stage where I was with tomcat 4.
Do you know when the 2.4 spec goes final?
Adam
On 09/30/2003 12:58 PM Tim Funk wrote:
> Did that alrady. Here's the gory details and the conclusion is valid for
> 4 and 5. It seems the spec folks took care of the character encoding
> issue but forgot how to fix it for j_security_check. So the "short term"
> solution is probably a custom solution per platform. :( (Maybe google
> has the answer, haven't checked yet)
>
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795
>
> -Tim
>
> Bill Barker wrote:
>
>> This is a really interesting issue. I would hope that you would send a
>> message to servletapi-feedback@eng.sun.com 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.
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
--
struts 1.1 + tomcat 5.0.12 + java 1.4.2
Linux 2.4.20 RH9
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
Did that alrady. Here's the gory details and the conclusion is valid for 4
and 5. It seems the spec folks took care of the character encoding issue but
forgot how to fix it for j_security_check. So the "short term" solution is
probably a custom solution per platform. :( (Maybe google has the answer,
haven't checked yet)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795
-Tim
Bill Barker wrote:
> This is a really interesting issue. I would hope that you would send a
> message to servletapi-feedback@eng.sun.com 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.
>
>
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
Did that alrady. Here's the gory details and the conclusion is valid for 4
and 5. It seems the spec folks took care of the character encoding issue but
forgot how to fix it for j_security_check. So the "short term" solution is
probably a custom solution per platform. :( (Maybe google has the answer,
haven't checked yet)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795
-Tim
Bill Barker wrote:
> This is a really interesting issue. I would hope that you would send a
> message to servletapi-feedback@eng.sun.com 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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Lawence <al...@yahoo.com>.
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 <wb...@wilshire.com> wrote:
"Joerg Heinicke" wrote in message
news:3F78CEC3.60508@virbus.de...
> 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@jakarta.apache.org/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 servletapi-feedback@eng.sun.com 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
Re: Filter for Form Authentication Problem
Posted by Bill Barker <wb...@wilshire.com>.
"Joerg Heinicke" <jh...@virbus.de> wrote in message
news:3F78CEC3.60508@virbus.de...
> 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@jakarta.apache.org/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 servletapi-feedback@eng.sun.com 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.
Re: Filter for Form Authentication Problem
Posted by Bill Barker <wb...@wilshire.com>.
"Joerg Heinicke" <jh...@virbus.de> wrote in message
news:3F78CEC3.60508@virbus.de...
> 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@jakarta.apache.org/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 servletapi-feedback@eng.sun.com 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Joerg Heinicke <jh...@virbus.de>.
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@jakarta.apache.org/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?
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@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Filter for Form Authentication Problem
Posted by Joerg Heinicke <jh...@virbus.de>.
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@jakarta.apache.org/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?
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.
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
You can't intercept j_security_check with a filter, it violates the spec.
-Tim
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.
Re: Filter for Form Authentication Problem
Posted by Tim Funk <fu...@joedog.org>.
You can't intercept j_security_check with a filter, it violates the spec.
-Tim
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@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org