httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mordechai T. Abzug" <>
Subject Re: [users@httpd] basic auth, apache, and denies
Date Thu, 03 Aug 2006 07:19:42 GMT
On Thu, Aug 03, 2006 at 08:45:27AM +0200, Boyle Owen wrote:

> It's not as clever as that. Each request has to have a valid set of
> credentials in a basic auth header or the server responds 401.

The credentials are valid.  Just not allowed access to the individal

> I rather think the funny behaviour results from something else:
> 1) Are /x and /y really parallel URLs (eg, http://server/dir1 and
> http://server/dir2) or are they nested (eg, http://server/dir and
> http://server/dir/subdir)? If they're nested, results will be
> unpredictable since basic auth only supports a single layer of
> authorization...

/x and /y are parallel.  Access controlled via .htaccess.

I've also tested with nested .htaccess, and have consistently found
that the lowest-level access applies.

> 2) Is any of the content on /x located /y or vice-versa? If /x/page
> contains an image at /y/pic.png, then this might screw up (it's browser
> dependent). 

No.  Again, simple access to /x and /y.

> Credentials are only valid relative to a resource. You can't go to the
> Stones concert with a ticket for Robbie Williams. You might as well turn
> up with a bus ticket...

Both /x and /y share the same "realm", so the credentials are a valid
resource for both.  Just, the user who is authenticated by the
credential is only allowed in /x, not /y.  To use a different anlogy,
imagine presenting an ID to get access to differerent places at a
government facility.  The same ID authenticates you to all places at
the facility, but does not authorize you to all places at the
facility.  If the guard of an area validates your ID, but you're not
on the list to get access, the guard doesn't say "see if you have a
different ID", the guard says "you don't get access."

This is the principle of separating authentication and authorization.
It's pretty basic.  First you present authentication.  Once we know
who you are, then we check if you are authorized.

Again, this only applies to cases where the authentication for this
realm was correct.

> The correct response to an unauthorized request for a protected
> resource is 401. Sending 403 breaks HTTP and can't (and shouldn't)
> be done. 403 means the server wasn't allowed to fetch the data
> (server config or file permissions).

Per RFC 2616:

However, I submit that this does not make sense given browser behavior
and standard security models, as described above.  It makes sense to
be able to return a 403 in response to a correctly authenticated
request that is forbidden access to the resource.

- Morty

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