> -----Original Message----- > From: morty@xxxxxxxxxx [mailto:morty@xxxxxxxxxx] > Sent: Thursday, August 03, 2006 5:30 AM > To: users@xxxxxxxxxxxxxxxx > Subject: [users@httpd] basic auth, apache, and denies > > > Question: > > apache 1.3.x. apache basic auth (over SSL) involving many users and > groups. Alice's group gets access to /x and /y, but Bob's group only > gets access to /x. When Bob tries to access /x, Bob gets a > username/password prompt. Bob types in his username and password, and > all is good. But if Bob tries to go to /y, he gets a username and > password prompt again and again. This is presumably because apache > knows Bob isn't supposed to have access to /y, so it sends a 401 > error, and the browser prompts for another username and password in > the hope that Bob has another login that will work. Of course, this > confuses Bob to no end. 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. 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... 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). > > So what I would like is for Bob's access attempts to /y to result in a > 403 instead of a 401. In more concrete terms, if the browser presents > username/password credentials to a resource, and those credentials are > valid credentials but are not allowed access to this particular > resource, the access should result in a 403, or similar, instead of a > 401. 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... 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). Bone up a bit on exactly how basic auth works: http://en.wikipedia.org/wiki/Basic_authentication_scheme Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. > > Is this possible? A google search didn't turn up anything useful. > Probably not imaginitive enough in search terms; someone else has to > have had this problem before. > > Thanks! > > - 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: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. --------------------------------------------------------------------- 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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|