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 resource. > 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: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 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:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: [EMAIL PROTECTED] " from the digest: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
