httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] authentication question
Date Mon, 11 May 2009 08:22:25 GMT
Jonathan Zuckerman wrote:
> On Sat, May 9, 2009 at 9:34 AM, Ross Boylan <> 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:> for more info.
>> To unsubscribe, e-mail:
>>   "   from the digest:
>> For additional commands, e-mail:
> 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 :

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message