DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-01-09 22:56 ---
*** Bug 11271 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-12-04 14:54 ---
I have just sent the following to [EMAIL PROTECTED]:

Now I know the meaning of the JSR-154 Expert Group but I have still some open
questions:

- Why is the clarification missing in the spec 2.4?
- What does this citation mean:

SRV.6.1.1 Examples of Filtering Components
• Authentication filters

Should such a Authentication filter completely reimplement the Authentication?

Another citation:

Step 7: When the last filter in the chain has been invoked, the next entity
accessed is the target servlet or resource at the end of the chain.

- Is j_security_check not a resource? If not why can the browser send a post to 
it?

- How should applications deal with such issues to allow a smart migration to 
the features of Spec 2.5
  which should address these issues?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-12-04 12:21 ---
*** Bug 25194 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-27 00:52 ---
I received a clarification from Yutaka Yoshida (lead for the 2.4 spec) with this
clarification: 

"In regards to this issue, servlet EG had a consensus that Filter must not be
applied for j_security_check. We believe the application component should not be
involved in the container-managed security. Although we understand why people
are using filter to manipulate the authentication mechanism, it doesn't solve
all issues related to the security and must be addressed in a larger scope of
the portable authentication mechanism, which I expect to have in the next
version of the specification. "

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 21:00 ---
I am willing to leave this as resolved invalid until we have a clarification 
and rationale from the servlet standards team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 14:56 ---
It also opens a nasty can of worms with respect to BASIC authentication. Since
the container issues the 401 challenge and not the webapp.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 14:30 ---
Authentication (BASIC, DIGEST, FORM) is an internal feature of the servlet
container. As such, a request to a specific URL will not be passed through the
filters or any servlet, as it simply doesn't reach the application layer.

Please DO NOT reopen this bug, which will not be addressed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 21:13 ---
Container extension methods are not a valid way of extending the model because 
they are not standardardized but are container specific.  What is needed is a 
means of extending security behaviour without being container specific. Filters 
could provide one means to do this.  

The standard itself is not clear on the point of whether filters should work 
with j_security_check.  In the long run the real problem is with the standard.  
The j_security_check mechanism is awkward and does not adequately address a 
number of needs.  Hopefully, someone will come up with something better soon.

In the meantime I am hoping that the servlet committee decides that filters 
should work with j_security_check so that I can write code that will be 
portable across containers.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 14:38 ---
FWIW - I also have a request to [EMAIL PROTECTED] for feedback on
this. I also prefer to keep this bug as RESOLVED-INVALID unless the spec team
decides that tomcat is behaving incorrectly in which case - we'll reopen the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 14:50 ---
And in which case I have no idea how to implement it, as the filter pipeline
ends with a servlet, and there's no servlet matching that URL. Besides, it would
make FORM behave differently than the other auth methods, which contradicts its
design principles.

For extending the machanism, a container extension feature should be used, such
as: a custom realm, a custom authenticator, a custom valve inserted in the
pipeline. Filters are located at the application level, and as such are not a
magic bullet for everything (although they can meet maybe 90% of the needs).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-08-04 05:33 ---
I have made the request for clarification. It seems to me that this is a 
critical matter and is one of the remaining areas of incompatability between 
containers created by different vendors.  The current means of using FORM based 
security is too limiting to be useful to many applications that desire to use 
container managed security.  Filters offer a potiential means of removing some 
of the limitations.  Examples some of the limitations that I am refering to 
include:

- Logins that require more than just userid and password.
- Support for optional login or login directly from a home page form.
- Logins supporting a "remember me" feature.
- Situations that require logging and retrieval or recording of information 
upon each login.

These situations occur too frequently in the real world to be ignored. If 
container managed security is to have any value it must be able to support 
these types of situations.

John T. Bell

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 16:26 ---
Al, your interpretation that the Servlet Specification requires j_security_check
to be handled through filters does *not* conform to my understanding of the
Servlet Specification, and AFAIK it does not conform to the understanding of any
other member of the JSR-154 expert group (responsible for creating the Servlet
2.4 specification) either.  The best way to get the issue cleared up, however,
would be to submit feedback to the expert group (send mail to
[EMAIL PROTECTED]) and ask for it to be clarified.

Complaining about Tomcat isn't going to have any influence on what the spec
actually says or means.  Encouraging the expert group to clarify things is the
only way to accomplish that.

Craig McClanahan
Member, JSR-154 Expert Group
J2EE Web Tier Architect

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 13:57 ---
The removal of Tomcat is as much about how this bug has been handled as it is 
about this specific issue.

The overall problems are;

1) There are a HUGE number of bugs with Tomcat 4 that either haven't been 
looked at or been fixed after 25 minor revisions.

2) The bugs that are closed may be closed because the reporter has been 
referred to another group rather than being closed because the issue was 
resolved in a manner that satisfies both parties.

3) To get any movement on the bug I had to indicate an intention to move to 
another servlet engine.

In short, if we recommend Tomcat and someone comes accross one of the 680+ 
outstanding issues, we're pretty much on our own. As we do not claim to be 
experts in Tomcat or it's underlying code, this isn't a responsibility we can 
afford to take on.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 13:38 ---
You may wish to remove weblogic too:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3e9b0241%40newsgroups.bea.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 13:07 ---
Thankyou for youe comments. Tomcat will now be removed from our list of 
approved software.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 12:06 ---
Please get a response from the spec team from Sun to confirm tomcat's behavior
is invalid. 

I contend the tomcat's behavior is correct with respect to the spec. If you
strongly disagree, please attach a patch that fixes the behavior and if another
committer agrees with your patch, it will be committed.

Here's a note from Craig about filters and j_security_check:
http://marc.theaimsgroup.com/?l=tomcat-user&m=101078110723448&w=2

If another container allows this behavior, that is ok. But it appears there is
no requirement that tomcat must do this.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 11:18 ---
The bug isn't resolved. There is still a dispute over the spec.

Closing a bug without checking with the bug reporter's agreement maybe a way 
to thin down the bug count, but is NOT a way to professionally handle bug 
reports.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 11:12 ---
Please see Section SRV6.2.4 in the Sun Servlet spec 2.3, which details the 
procedure a contain must follow when dealing with requests. 

In short it says that if an incoming URI matches a filter pattern the user 
specified filter should be invoked. It appears neither section says that the 
use of j_security_check should stop a filter being triggered, yet the filter 
section indicates that the filter should be.

Other containers do trigger filters on j_security_check, evidence of this can 
be found at 
http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/tsec_servlet.html (4th 
paragraph),  http://mainframeforum.com/archive/1047/2003/4/545167 (comment 
from Scott Sobotka), and http://www.caucho.com/quercus/faq/question.xtp?
question_id=1239 


Snippet:

- Identifies the target web resource according to the rules of SRV.11.2.

- If there are filters matched by servlet name and the web resource has a 
servlet-name, the container builds the chain of filters matching in the order 
declared in the deployment descriptor. The last filter in this chain 
corresponds to the last servlet-name matching filter and is the filter that 
invokes the target web resource.

- If there are filters using url-pattern matching and the url-pattern matches
the request URI according to the rules of SRV.11.2, the container builds the
chain of url-pattern matched filters in the same order as declared in the 
deployment
descriptor. The last filter in this chain is the last url-pattern matching
filter in the deployment descriptor for this request URI. The last filter in
this chain is the filter that invokes the first filter in the servlet-name 
macthing
chain, or invokes the target web resource if there are none.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 11:11 ---
The spec implies that authentication is part of the container, not part of the
webapp so the j_security_check occurs outside the role of filters.

SRV.12.2 Declarative Security
Declarative security refers to the means of expressing an application’s security
structure, including roles, access control, and authentication requirements in a
form external to the application. The deployment descriptor is the primary
vehicle for declarative security in web applications.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 11:03 ---

copied text from servlet-spec-2.4-pfd3 for container managed security with 
forms -> j_security_check

SRV.12.5.3 Form Based Authentication
The look and feel of the  login screen  cannot be varied using the web browser 
s
built-in authentication mechanisms. This specification introduces a required 
form
based authentication mechanism which allows a Developer to control the look and
feel of the login screens.
The web application deployment descriptor contains entries for a login form
and error page. The login form must contain fields for entering a username and 
a
password. These fields must be named j_username and j_password , respectively.
When a user attempts to access a protected web resource, the container checks
the user s authentication. If the user is authenticated and possesses 
authority to
access the resource, the requested web resource is activated and a reference 
to it is
returned. If the user is not authenticated, all of the following steps occur:
1. The login form associated with the security constraint is sent to the 
client and
the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the username and password
fields.
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the information from 
the form.
5. If authentication fails, the error page is returned using either a forward 
or a re-direct,
and the status code of the response is set to 401.
6. If authentication succeeds, the authenticated user s principal is checked 
to see
if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource using 
the stored
URL path.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 10:43 ---
But under the Sun specifications it SHOULD reach the filter because the filter 
is defined as handling all request going to that webapp. Authentication is 
suppose to be a transparent layer on top of the webapp, not something that 
overrides the behaviour specified in web.xml

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 09:53 ---
j_security_check is handled internaly by tomcat authenticator valves, and so never 
reachs your filter.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795

j_security_check isn't fed through filters





--- Additional Comments From [EMAIL PROTECTED]  2003-08-01 08:16 ---
After lack of comment and/or action from developers on this issue, and the 
discovery of over 680 open bugs in Tomcat 4, confidence in Tomcats stability 
and standards complaince is now very low.

With this in mind we have made the decision to replace Tomcat with an 
alternative servlet engine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]