In my opinion, as a network administrator, I don't want to show to my end users why the user shouldn't commit anything in the repository. Because as Les Mikesell said, the message could show someway to workaround and allow the user to commit something without permission. I think the current message, 403-forbidden is a excellent message because when the end user sees this message, the user needs to call me and ask why is not possible to commit, and then I can explain that the folder, for that user, is only for read. If he/she need to commit something to that folder, the user need to talk with someone who has permission. Or ask for the administrator to change the permissions. I guess a lot of users gets confuse about the sides, and as a lot of people are both (user and administrator) they just think the messages should show in the client-side "what is wrong" to fix it in the server, but the messages are not to the client-side know how to fix in the server but just to let the users know that they CAN NOT commit anything because they have no permission, just it.
Rafael M. Heise On Sat, Jul 30, 2011 at 7:04 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > On Sat, Jul 30, 2011 at 3:10 PM, Les Mikesell <lesmikes...@gmail.com> > wrote: > > On 7/30/11 1:14 PM, Jeremy Pereira wrote: > >> > >> On 30 Jul 2011, at 18:17, Les Mikesell wrote: > >> > >>> > >>> '403 forbidden' makes reasonable sense for a client-side message to > >>> someone who shouldn't know internal details anyway. > >> > >> Seriously? You think an HTTP response code (which *is* an internal > >> detail) is an acceptable error message. You think it makes sense? Why > is > >> 403 forbidden? Oh, right, that's just a code. Ok what is forbidden? > Is it > >> me? the repository? writing to the repository? writing to a particular > >> file? Why is it forbidden? Is it because it is Tuesday? WHY???!!!! > >> > >> It's a useless error message. It's even pretty useless to the average > >> person when they are trying to use a browser to access a URL. > > > > From a security perspective it is a bad idea to tell a network client > that > > is doing something you have explicitly denied any of the details of how > the > > system is configured to prevent it. Working correctly is usually a yes > or > > no question and this answer is clearly 'no'. > > > >>> Is something better in the apache error log where the sysadmin who set > it > >>> up wrong should be looking? > >> > >> Except that the administrator might not have set up the repository > wrong. > >> He might have made it deliberately read only. Users should not have to > >> trawl Apache logs to find out that they are not allowed to commit to a > >> repository. > > > > Right, if the system is intentionally set up for read-only access, the > user > > should not get a hint about how to work around it, and it won't do them > any > > particular good to know if it is denied in the http config, the > > authorization setup, or the filesystem. Really, what do you need to > know > > as an end user besides that your commit was denied? > > When I, as a user, am denied access to something, it's very helpful to > know at which level of the setup my access was denied in order to > *fix* it. And it's helpful for me, as an admin, to get an error > message that reveals as much as possible about the problem so that I > can fix it if the problem is my fault. >
