Am 2012-10-27 16:57, schrieb Mark Thomas:
On 27/10/2012 14:50, Michael-O wrote:
Hi,
several authentication mechanisms require a session (*not* HTTP session)
or connection being initiated when authentication is performed and
principal cached for subsquent requests [1], [2].
Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave
stateful. I once contributed that code to Apache in bug 48465 [3] which
does not behave like that. I like to align both authenticators.
This issue initially popped up while fixing an issue in libserf [4] for
the upcoming Apache Subversion version 1.8.0.
How do I access that information in an authenticator? I do not intend to
create a HTTP session for that for two reasons:
1. Creation of sessions should be upto the webapp.
2. There is no guarantee that the client will present the session cookie
on a subsequent request.
The only mechanism to maintain state between HTTP requests is the HTTP
session. You might be able to hack something together (in a non-portable
way) on a per connection basis but that is likely to require some rather
major internal surgery for Tomcat (and may be rejected by the committers).
Is there no way to tell that subsequent n requests come from the very
same socket connection? HTTP is just on top of TCP/IP. Something like
this should be transparent to HTTP though?
I am curious, since I know server implementations which indeed DO
maintain state without HTTP sessions but I do not know how they do that.
At least the chromium link says how this can be done. Apache HTTP Cient
does that too. Why not Tomcat?
It isn't unreasonable for use of an authentication to require an HTTP
session. FORM auth does that so I don't immediately see why SPNEGO can't.
FORM auth works very different compared to header-based auth. Form is
meant for human interaction with a browser which will always pass cookies.
I cannot expect that from a "machine" client nor can the client actively
say destroy that session unless a specific URL is called. "Connection:
close" can do that.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
