Jonathan Zuckerman wrote:
On Sat, May 9, 2009 at 9:34 AM, Ross Boylan <r...@biostat.ucsf.edu> wrote:
Suppose I have apache running in front of a web application and
subversion.
I am thinking of a scenario in which the web application provides a
login page. However, the user may also browse to web pages served by
subversion.
Is there a way that my app can have someone log in and then pass the
identity and authentication "up" to appache? In particular, I'd want
this authentication used if the user browsed over to the subversion
repository.
I'm assume a common source, e.g., LDAP, will provide user and password
information that is the same for my app and apache.
A final wrinkle is that the application itself may access subversion via
http:// (https?) using either the identity of the user or, perhaps, a
separate identity the application runs under.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
This is a good question, it would be nice to use Apache to
authenticate all those pages instead of having to include your own
application's authentication in every page. Let us know if you do
find a solution for this, I'd be interested to hear how it turns out.
It is in any case a question with quite a complex answer, delving deep
in a lot of aspects of HTTP and Apache.
The problem is that it is the question of question that one doesn't
really know from which side to pick it up.. Therefore probably the lack
of answers so far.
The first part probably consists of saying that the HTTP protocol, per
se, is state- and connection- and session-less : each request is
independent from previous and future ones. And Apache being a HTTP
server, so it is too.
Since keeping the information about a user's authentication across
several requests would imply keeping that information somewhere on the
server side, and thus introducing a form of "session", that's where the
basic problem arises. Apache itself has no mechanism for that, which
implies that any mechanism to do this would be outside of Apache itself.
What Apache itself can do, at the level of each individual request, is
authenticating a user using either Basic or Digest authentication.
Those mechanisms rely on the fact that once authenticated one time, the
browser will keep sending a specific HTTP header with each subsequent
request for the same "realm".
Provided this is in place, at each new request, Apache will pick up this
HTTPheader in the request, and internally set the corresponding internal
Apache user-id *for this request*.
It then belongs to the application to pick up this internal Apache
user-id and do something with it.
Any other "persistent" authentication mechanism would have to rely on a
cookie sent to the browser, which either "contains" the authentication
itself, or contains some identifier which refers to something stored at
the server side and which in turn contains this authentication.
Under the appropriate setup, the browser would then return this cookie
at each subsequent request.
Apache itself will not decode this cookie nor do anything with it.
Again, it belongs to the application to do so.
I would imagine (but I am not sure), that the various mod_auth* modules
that belong to the standard Apache distribution, do something of the
kind (I mean, avoid doing a new lookup in LDAP or a database at each
request, by storing some information in some kind of cache).
So, to get back to OP question, in the way that he describes it, my
comment would be : if you want to use the user authentication across
several applications, then you should /not/ do the authentication at the
level of one application in particular, and then try to "pass it up to
Apache". You should do it at some higher level, for /all/ applications,
and "pass it down" to each application (including yours).
And you should make sure that the mechanism used to authenticate and
store this authentication across several requests, can be understood by
all applications (SVN being one, yours being another).
If it that series of applications there are some that you do not control
(like SVN), then I believe the only standard mechanism would be to set
Apache's internal user-id at each request.
As to your "final wrinkle", I think you need to be a bit clearer as to
what you want there. What determines the choice of whether a user has
to login, or gets some standard user-id ? And what would this standard
user-id be ?
(As an idea : it is possible to implement a scheme whereby a user gets
some "automatic" id if he calls from a specific IP address (or range of
addresses). And even possible to organise that, if the IP comparison
fails, then they would get a login page.
But not from any standard Apache module, you'd need something customised
for that.
Or, have a look at the existing library of mod_perl authentication
solutions, for example here :
http://cpan.uwinnipeg.ca/search?query=apache2%3A%3Aauth&mode=dist
)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
