https://issues.apache.org/bugzilla/show_bug.cgi?id=12428
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #29 from Mark Thomas <ma...@apache.org> 2011-04-01 07:21:31 EDT ---
This has been fixed in 7.0.x and will be included in 7.0.12 onwards. It is
disable by default but can be enabled on a per context basis.
To address some of the points raised in comment 26:
I don't believe RFC2617 or the Servlet specification are sufficiently clear to
enable preemptive authentication by default. They are open to interpretation
and my reading of them is that there are ambiguities in the language that
defines the server response in such a scenario.
I did not say that an application cannot trigger authentication by returning a
401 response. My point was that if the application uses the Servlet 3.0 API to
manually implement preemptive authentication, it needs to consider what to do
if that authentication fails when the client has requested a non-protected
resource. Returning a 401 in that case strikes me as the wrong thing to do but
that goes back to the ambiguity in the Servlet spec and RFC2617.
Regarding programmatic security and declarative security, the relationship
between them is set out in section 13 if the servlet spec. The point I was
making was that if an application uses both declarative security and
programmatic security and the programmatic security performs actions normally
handled by declarative security (e.g. sending and processing authentication
headers) then you need to be careful to ensure that the two do not interfere.
To summarise the current position:
- with alwaysUseSession and cache enabled on an authenticator, the
authenticated user name and principal will be available to all requests once
the user has accessed a protected resource
- with preemptiveAuthentication enabled on an authenticator, the authenticated
user name and principal will always be available
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
