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
Bye,
Waldemar Kornewald
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
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.
The OpenID plugin has a new maintainer, see:
http://trac-hacks.org/ticket/1007
Possibly he can serve you with some requirements.
.