Welcome message for unauthenticated users on closed Tracs
David Abrahams
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?
Thanks,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Matthew Gillen
>
>
> 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>
Matt
David Abrahams
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.
Matthew Gillen
>
> Matthew Gillen <m...@mattgillen.net> 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>
>>
>
> 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
Christopher Taylor
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
John Hampton
> 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.
You'll have to patch trac proper, but the attached patch will redirect
an anonymous user to /login if they get a permission error
-John
David Abrahams
David Abrahams
<chta...@gmail.com> writes:
> 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.
Not if you disable the registration module in the Admin area. Am I
missing something?
David Abrahams
writes:
> diff -urN trac-0.10.3/trac/web/main.py trac-0.10.3-loginredir/trac/web/main.py
> --- trac-0.10.3/trac/web/main.py 2006-12-12 18:44:08.000000000 +0000
> +++ trac-0.10.3-loginredir/trac/web/main.py 2007-01-19 00:00:31.556000250 +0000
> @@ -402,6 +402,8 @@
> 'message': e.message
> }
> try:
> + if (req.authname == 'anonymous') and (e.reason == 'Forbidden'):
> + req.redirect(env.href('login', {'referer':req.href(req.path_info)}))
> req.send_error(sys.exc_info(), status=e.code)
> except RequestDone:
> return []
This is fantastic; it works perfectly. Is there any chance the powers
that be would accept it?
John Hampton
> This is fantastic; it works perfectly. Is there any chance > the powers that be would accept it?
I'd love for something like this to go into the base, the only problem is that it is a bit confusing if you don't use form based login. Without form based login, you just get a popup login box without any explanation. Perhaps I should modify it so that it can be turned on and off via an option in the config file. What say ye, oh wonderous devs?
-John
David Abrahams
writes:
> David Abrahams said:
>> This is fantastic; it works perfectly. Is there any chance > the
>> powers that be would accept it?
>
> I'd love for something like this to go into the base, the only problem
> is that it is a bit confusing if you don't use form based login.
> Without form based login, you just get a popup login box without any
> explanation.
Doesn't seem like a big problem to me.
But anyway, isn't there some way to control the HTTP auth dialog
title?
> Perhaps I should modify it so that it can be turned on
> and off via an option in the config file.
Seems reasonable.
John Hampton
> But anyway, isn't there some way to control the HTTP auth dialog
> title?
Yeah, for basic authentication you can change it via the "AuthName"
parameter.
-John
David Abrahams
<da...@boost-consulting.com> writes:
I take it back; it doesn't quite work perfectly. When trying to access
https://mysite/trac/mytrac/ticket/19#comment:3
After logging in, I am redirected to
https://mysite/trac/mytrac#comment:3
got a fix for this one?
TIA,
David Abrahams
I think I've now fixed it; see http://trac.edgewall.org/ticket/5340
for an updated patch.
--
Dave Abrahams
Boost Consulting
Christopher Taylor
http://www.trac-hacks.org/wiki/AuthRequiredPlugin
-Chris
jtuchscherer
AuthRequired plugin. It is great and easy and solves the problem.
On Jun 21, 7:18 pm, "Christopher Taylor" <chtay...@gmail.com> wrote:
> Turns out there's a plugin that addresses this issue ....http://www.trac-hacks.org/wiki/AuthRequiredPlugin
>
> -Chris
>
> On 5/20/07, David Abrahams <d...@boost-consulting.com> wrote:
>
>
>
> > on Sun Feb 18 2007, David Abrahams <dave-UB3wUj7V41K5azolltMz9laTQe2KTcn/-AT-public.gmane.org> wrote:
>
> > > David Abrahams
> > > <d...@boost-consulting.com> writes:
>
> > >> John Hampton <pacopa...@pacopablo.com>
> > I think I've now fixed it; seehttp://trac.edgewall.org/ticket/5340