Proper user authentication

[greenash@…]

• Environment: standalone Tracd from 0.9b2 and firefox 1.0.6 for Linux

I am unable to figure out what strange metaphor Trac uses for user management, but it's definitely not something a normal human being would anticipate.

Inside my LAN I log in, log out, go to another computer and click the Login link; low and behold — I am magically logged in again with the same user I have just logged out of. The browser never asks for a password. My session settings (e-mail) are not retrieved, of course. I have no idea how anyone could program that *on purpose*, let alone by accident.

Why not provide a normal, friendly and boring Register New Account / Login / Settings / Logout set of pages ? The user data would be stored in the Trac environment for each project. This is what most users would expect.

But no, that would not be confusing enough, right? Your unique "session-centric" user management is certainly superior in that respect.

As it is, I am unable to use the software in my project.

And it's too bad, because overall Trac looks like a very nice webapp which is being developed at a good pace.

[Emmanuel Blot]

This is a duplicate of the long lasting #791 ticket

Definitely not a "blocker" issue: Trac can be used with a little fuzz: you simply need to close your browser to discard the authentication information.

[anonymous]

I personally find reliance on external authentication far superior, because (1) any decent organization already has a directory of users somewhere; and (2) doing it is better delegated to the software that's designed for that purpose. Having to deal with yet another passwd file is a liability that should be avoided at all costs. Writings backends to every possible authentication flavor should not be Trac's concern either, it is done for better or worse in numerous other Web servers, Apache 2 being a prime example.

So, if you want to see who's changing what, consider investing time in connecting your Web server to a proper user directory, and provide one of several available front-ends to manage accounts. You'll be glad you did.

[Emmanuel Blot]

I'm not sure to understand how the last comment relates with the original ticket topic.

Authentication is not done by Trac anyway (with the exception of the stand alone daemon). It is performed by the web server, with one of the numerous authentication scheme in the case of Apache.

[Matthew Good]

Tickets closed with any resolution besides "fixed" should not have a milestone.

As eblot said, if you need more flexibility in your authentication you should switch to another server such as Apache and use their authentication mechanisms.

If you want user registration see #287 and ​http://trac-hacks.swapoff.org/wiki/AccountManagerPlugin

[greenash@…]

Thanks for the link.

You may not realize it, but having an unsupported "hack" on a site called trac-hacks.swapoff.org isn't exactly a solution for user account management. At least it's not a confidence-inspiring solution. This is a basic feature that all bug tracking packages provide and should be integrated in the core code.

Of course, I don't expect to find much sympathy from developers. Every open-source project seems to breed its own peculiar species of starry-eyed folks. The sad part is that Trac seems to have a company behind it, so I expected more than from the average sourceforge piece of cr^HH software. And yet, basic issues remain unresolved because the project has adopted some weird ideology that's different from most people's expectations.

[Matthew Good]

Unlike other bug-tracking systems that simply have another database table for storing the users, Trac took the approach of allowing users to leverage the numerous authentication modules available for their web server. This means that many users won't need to manage the Trac users by hand, since they can tie Trac into something like LDAP, Active Directory, or whatever centralized user system that they already have in place.

I created the account manager plugin as a proof of concept for reimplementing an old patch as a standalone plugin. Its purpose at the moment is really for public installations to allow users to register new accounts. I haven't been updating it lately, but I do intend to continue to support it. As far as it being a "hack", the title "Trac Hacks" was simply chosen by Alec Thomas since it sounded cool. I guess I could have put the code in a branch of the Trac repository, but I think the site is a good idea for collecting various extensions to Trac.

Regarding "starry-eyed" developers, I think that any developer, open source or not, will become defensive when a brand-new user takes a look at their product and says "no that's wrong, you should do it like this." Yes, people may be accustomed to managing a separate table of users within each webapp that they install, but that doesn't mean that it's a "better" way to do it.

[greenash@…]

Dear mgood: all very true regarding hurting people's feelings, especially as a brand new user — I appologize. OTOH, I read the BileBlog regularly and am a fan of vitriolic criticism. It's the only thing that gets things moving; flame wars are underrated :)

I based my argument on Nielsen's "most people spend most of their time on sites OTHER than yours" rule. In other words, don't break your user's mental model of a webapp. This is 2005 and people have come to expect a certain pattern — it's pretty late for innovation in webapp interaction (notwithstanding AJAX). If innovation also breaks functionality (and it does, in the case of missing user registration), the case is even stronger.

Regarding your "hack": I have nothing against "hacking", and I do not doubt the quality of your code. However, Trac does not seem to have a standard plugin mechanism (like e.g. jEdit) so your "hack" could stop working even with a minor Trac upgrade. Furthermore, if you lose interest in the code or get an "all your time is belong to us" job, the users get the shaft. OTOH, if the feature was in the core code, this would be less of a problem.

The really sad part is that you guys are Python hackers, not C/++/Java programmers, so this webapp is actually likely to evolve fast — if only you'd be more mindfull of common use scenarios.

[anonymous]

Did you happen to see TracPlugins or TracDev/PluginDevelopment? Trac does have a standard plugin system and all the modules in Trac are based on it. Also, mgood's account manager plugin is based on this system so should only have a chance to break if a major change happens in the core system. And Trac is not alone in how it handles user administration and registration. I use several web apps that lets the web server handle the authenication. A few that come to mind are Sharepoint, Outlook web mail, and ​TWiki. Just because that for some reason PHP based systems roll their own user systems does not mean everyone has to. I for one find it easier to manage my users in one place and the users find a much friendlier environment if they do not have to remember a zillion passwords and usernames. I know the current push in the corporate world is for all software to support single sign on and LDAP. An LDAP plugin is currently in development which will be a welcome addition.

As for mgood's plugin, I do not understand why users get the shaft if we loses interest. The code is opensource and anyone can pick development and maintenance of the plugin. Do you expect all contributed plugins to be brought into core development? That is a little unrealistic.

[Carsten Klein <carsten.klein@…>]

Replying to greenash@…:

You are using HTTP Basic Auth or some similar authentication mechanism? Too bad, the user agent you are using is caching the information.

See ​http://eregie.premier-ministre.gouv.fr/manual/howto/auth.html#basicfaq for more information.

Here is the major reason why it does not work as expected, basically you will have to restart your user agent if you really want to log out.

How do I log out? Since browsers first started implementing basic authentication, website administrators have wanted to know how to let the user log out. Since the browser caches the username and password with the authentication realm, as described earlier in this tutorial, this is not a function of the server configuration, but is a question of getting the browser to forget the credential information, so that the next time the resource is requested, the username and password must be supplied again. There are numerous situations in which this is desirable, such as when using a browser in a public location, and not wishing to leave the browser logged in, so that the next person can get into your bank account. However, although this is perhaps the most frequently asked question about basic authentication, thus far none of the major browser manufacturers have seen this as being a desirable feature to put into their products. Consequently, the answer to this question is, you can't. Sorry.

[Carsten Klein <carsten.klein@…>]

For standalone trac this could be easily fixed though, by making HTTPBasicAuthentication, on _do_auth, return not the generic realm as in

start_response('401 Unauthorized',

[('WWW-Authenticate', 'Basic realm="%s"' % self.realm),

('Content-Length', '0')])()

but by also including some randomized component, say

start_response('401 Unauthorized',

[('WWW-Authenticate', 'Basic realm="%s_%s"' % ( self.realm, self._randomize_realm()),

('Content-Length', '0')])()

That way, and since the realm is in no way associated with the user in the htpasswd file, logout and login would work as expected, effectfully ruling out the caches of the browser.

Dunno if something similar for apache exists, though, but maybe someone has already done an auth extension that would work similarly to what is depicted above…

[Carsten Klein <carsten.klein@…>]

See also ​http://trac-hacks.org/wiki/TrueHttpLogoutPatch for a javascript based solution, don't know if it will work, though.

[Carsten Klein <carsten.klein@…>]

Replying to Carsten Klein <carsten.klein@…>:

See also ​http://trac-hacks.org/wiki/TrueHttpLogoutPatch for a javascript based solution, don't know if it will work, though.

Just noticed that this is already cross-linked on 791#comment:54.

[Carsten Klein <carsten.klein@…>]

Reopening this since the issue still remains, i.e. forging a name when adding comments to a ticket or posting tickets, modifying or adding content to the wiki so on.

Relabeling this to "Anonymous user email verification"

[Carsten Klein <carsten.klein@…>]

Ups, it is late, closing this again since it was the wrong ticket. My mind was set on a different ticket i was searching for. Sorry for that.

[Carsten Klein <carsten.klein@…>]

changing back the title