UserDirectory

1 view
Skip to first unread message

Waldemar Kornewald

unread,
Dec 3, 2006, 12:45:58 PM12/3/06
to Trac
Hi,
what is needed to finally get real user support integrated into Trac?
There is IUserDirectory, but that patch
(http://trac.edgewall.org/ticket/2456) wasn't accepted because it
didn't seem to make you happy. I'd like to work on a simple patch with
a new interface to finally make it possible for authentication plugins
to provide extra user data instead of using the session API.

What do you need, exactly?

Is the following interface good enough? It consists of two interfaces
which separate the user from his attributes. In order to make the API
centrally accessible, I'm planning to add a UserManager (as part of
the env) which will provide the same functions as the two interfaces.

class IUserDirectory(Interface):
"""
Extension point interface for backends that store known users.
"""

def get_known_users(self):
"""
Generator that yields a list of known users.

@return username
"""
pass

def delete_user(self, username):
"""
Deletes the given user.
"""
pass


class IUserAttributeProvider(Interface):
"""
Extension point interface for backends that store user attributes.
"""

def get_user_attribute(self, username, attribute):
"""
Returns a user attribute.

@param username: the user you want to get the attribute of
@param attribute: the name of the attribute

@return value
Returns None if the attribute is not supported.
"""
pass

def set_user_attribute(self, username, attribute, value):
"""
Sets a user attribute.

@param username: the user you want to set the attribute of
@param attribute: the name of the attribute
@param value: the new value of the attribute

@return success
Returns False if setting the attribute is not supported.
"""
pass

def delete_user_attribute(self, username, attribute):
"""
Deletes a user attribute.

@param username: the affected user
@param attribute: the name of the attribute that should be deleted
"""
pass

def delete_all_user_attributes(self, username):
"""
Deletes all of the given user's attributes.
"""
pass

Do you have any suggestions?

Bye,
Waldemar Kornewald

Waldemar Kornewald

unread,
Dec 5, 2006, 6:54:43 AM12/5/06
to Trac
Hi again,
please take a look at the ticket, again:
http://trac.edgewall.org/ticket/2456
I've uploaded a draft API (user.py). It's completely untested. I just
want to know if it's going in the right direction. I want to work on
this, but without any input I don't want to continue because I don't
want to waste time for nothing.

Bye,
Waldemar Kornewald

Waldemar Kornewald

unread,
Dec 15, 2006, 12:56:48 PM12/15/06
to Trac
Hi,
the new patch can be applied to trunk and it works correctly, as far
as I could test it:
http://trac.edgewall.org/ticket/2456
Anonymous users can change their session settings as before, but
logged-in users access the UserManager API to change their user
properties (by default it accesses the session, again ;). Information
from authenticated users must be retrieved with the UserManager (e.g.:
email map, usernames for restrict_owner). The API should be usable, as
is, but Christian Boos said that it needs more work to be complete. I
agree, but by providing the API now we could let others create plugins
independently (and thus help me with my work).

The next step would be to port the AccountManager's admin interface to
the new API.

Do you want Trac to use the web server's http authentication method or
should Trac by default use form-based authentication like with
AccountManager and DbAuth? We could support htpasswd and htdigest by
manually specifying those files in trac.ini. Forms are more
user-friendly because http authentication blocks the whole browser
window.

Should the adapted DbAuthPlugin be integrated into Trac, too? That
way, Trac's default behavior could be similar to other bug-trackers
that simply store the user information in the DB and provide real
registration support (which probably needs DB changes for activation
confirmation...). This would get users started more quickly (esp.
those who use Trac as a bug tracker without repos integration).

In the future, I want to allow for managing htpasswd/htdigest
independently of the registered users (i.e.: separate repos access
from Trac access) with an extra plugin (RepoAccount). I already hacked
AccountManager locally such that it allows for managing repos access
with Trac 0.10, but our login is handled by DbAuth. There is a new
permission policy REPOS_ACCESS and an additional admin interface for
managing the accounts. Users with that permission get a menu "Repos
Account" where they can change the password for their repos account
(and create an account if it doesn't exist).

In order to work properly on this I want to ask if you could give me
access to your repository. I could work in a separate branch. Also,
this would make it easier for me to commit small bug fixes to trunk
very quickly. Thank you.

Bye,
Waldemar Kornewald

Ilias Lazaridis

unread,
Dec 15, 2006, 3:44:20 PM12/15/06
to Trac Development
Waldemar Kornewald wrote:
> Hi,
> the new patch can be applied to trunk and it works correctly, as far
> as I could test it:
> http://trac.edgewall.org/ticket/2456

You may want to create a document, describing the requirements for this
component, and what the status of the implementation is.

I am interested in this, too - and could contribute some testing and
work, too.

Such a component is very important.

Ilias Lazaridis

unread,
Dec 15, 2006, 5:45:57 PM12/15/06
to Trac Development

Waldemar Kornewald wrote:
> Hi,
> the new patch can be applied to trunk and it works correctly, as far
> as I could test it:
> http://trac.edgewall.org/ticket/2456
...

The OpenID plugin has a new maintainer, see:

http://trac-hacks.org/ticket/1007

Possibly he can serve you with some requirements.

.

--
http://dev.lazaridis.com/base

Reply all
Reply to author
Forward
0 new messages