My problem was similar but different. I have a closed Trac environment in which anonymous has no privileges what so ever. However, with the UserAccount manager plugin, an unregistered user can still create an account. That account has no privileges until I move it to a "registeredusers" group, basically authorizing the user. However, if the users tries to access the system before I move him/her into the registeredusers group, they get the cryptic (from a user's perspective) notification: "Error, you do not have WIKI_VIEW permission" or something similar.
The best way to change this, IMHO, is for Trac to handle permission errors differently. I propose: When Trac throws a permission error it first checks to see if the current user (defaults to anonymous) has -any- permissions. If the users doesn't have any permissions then it looks for a NoPermissions.txt file (or something equivalent) and uses that to generate the error page. If that file doesn't exist it then defaults to a "You don't have access to the system, contact the system admin" error. If the user has any permissions, but a permissions error is still thrown then Trac looks for a No<Privilege>.txt file (or something equivalent) and uses that to generate the error page. If that file doesn't exist then it defaults to the current format for errors. Any Thoughts? Respectfully, Christopher Taylor On 1/18/07, Matthew Gillen <[EMAIL PROTECTED]> wrote:
David Abrahams wrote: > > Matthew Gillen <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> >>> >>> One of my users complained (bitterly) that when he arrives, >>> unauthenticated, at his Trac, instead of being directed to a "login" >>> screen he gets a cryptic message about not having the right privileges >>> to view the page. I know he should just get over it, but I have to >>> admit he's right; it's a bad user interface. That message only makes >>> sense on Tracs that can be used without logging in. Is there >>> something I can do about this? >> >> Of course. Assuming you're using apache, change the Auth Required scope >> to include the root URL, instead of just the /login path. >> >> Ie change something that looks like this: >> <LocationMatch "/tracsrv/test/login"> >> AuthType Basic >> Require valid-user >> </LocationMatch> >> >> to this: >> <LocationMatch "/tracsrv/test/"> >> AuthType Basic >> Require valid-user >> </LocationMatch> >> > > I'm using the new AccountManager, one of whose benefits is that the > login screen is a real HTML form. IIUC, if I do what you're > suggesting, I'll end up with an HTTP auth dialog box instead. Yes, that's correct. That's the extent of my apache-foo (or pitiful lack thereof). There very well might be a simple way to tell apache to use a different mechanism besides "AuthType Basic" (ie to redirect to the AccountManager URL), but I've never had occasion to find out. Perhaps someone else has some better ideas. I'd be curious to know if you find a solution though.. Matt >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
