Please add a sane user management system

[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.

[eblot]

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.

[eblot]

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.

[mgood]

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.

[mgood]

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.