On Thu, Mar 25, 2010 at 11:36 AM, Lane, Ryan <[email protected]> wrote: > That makes sense. My only concern is that this will require extension > developers to dive into core to add features they'd normally add to their > own extension. This isn't necessarily a bad thing, as their changes could > benefit everyone.
My goal is to not have this done in extensions at all. Everything should be in core, ideally. This encourages people to write clean, reasonable code -- current AuthPlugins duplicate code massively, with all the problems that entails. Each one supports a different set of functionality in different ways. Of course, the interface should also be stable and suitable for extensions, but any ExtAuth plugin in SVN should be in core, not extensions, IMO. > I add users into the groups; I don't add groups to users. I do this by: > > 1. Getting a list of all groups ($user->getAllGroups()), and a list of > groups the user is in ($user->getEffectiveGroups()) > 2. I iterate through the list of all groups and: > 2a. Add the user into the wiki group if they are in the external group > 2b. Remove the user from the wiki group if they are in the wiki group, but > no longer in the external group > > Effectively, I'm synchronizing the groups every login. I see. This sounds like it would have a couple of notable issues: * Special:UserRights would be pretty confusing. Additions and removals would seem to work, but only until the user next logged in. * Group changes would only take effect on login. Users might only log in once a month. I was thinking that the groups should be implicit, like autoconfirmed, not explicit. This would require a query to the backend on every permissions check, however, for linked accounts. Some type of caching could be optionally used -- maybe just storing the list of groups in the User object and relying on the fact that that's cached. > Well, the proposal mentions allowing the user to choose their own username. > That is fine for some extensions (OpenID does this, for instance), and it > may even be useful for the LDAP plugin, but I'd like to ensure the plugin > can choose the name without giving the user an option. What are the use-cases for this? What sorts of names would you want to auto-assign? It sounds like this would best be done by exposing some kind of hook, if it's meant to be for stuff as narrow as semi-anonymous users. E.g., just have a hook somewhere in account autocreation that gets passed the User and ExternalUser objects, and let it choose a name if it likes. > It would be *really* nice if this worked for both regular, and > auto-authentication, as right now it only works for auto-authentication; I > use this for a semi-anonymous user feature, but it only works for auto-auth: > > http://ryandlane.com/blog/2009/06/18/semi-anonymous-users-in-mediawiki-using > -the-ldap-authentication-extension/ I'm not sure what the difference is between regular and auto-authentication. > Actually, no. LDAP usernames are not assumed to be unique, or stable. > Generally, usernames are based on some combination of a person's name. > People's names can change for various reasons (marriage, legal name change, > etc.). When a person's name changes, their username changes with it. LDAP > entries are assumed to have some unique identifier that is often different > than the username. In the Posix schema, this is uidNumber. In Active > Directory, it is often the Security Identifier (SID), but may also be the > userAlternativeName attribute, which is often the case in smart card > infrastructures. > > In the Posix schema, this is guaranteed to be an integer, but in Active > Directory, it will most likely be a string, and can be fairly long. Okay, now I'm confused. So you're saying that there is no stable, unique identifier that can be used for querying information about a user? The only identifier you can use is the username, and that's unstable? That seems decidedly inconvenient. How is any external system supposed to integrate with the authentication system if there are no stable identifiers? > The LDAP plugin detects the external account was renamed the following way: > > On account creation, the plugin records the external ID. On authentication, > the plugin queries LDAP, and gets the username back. If the username is > different than the local account, the plugin renames the account, or blocks > login, which should inform the user to contact the site admin. If the new > username is already taken, the plugin blocks login, which should inform the > user to contact the site admin. > > Allowing the user to choose a new name in this situation wouldn't really > make sense, as the extension is assuming the external username matches the > local one. Keeping the name the same is also really problematic for most > organizations using LDAP, as usernames may be re-used. ExtAuth takes the philosophy that the wiki name may be totally disconnected from the external name. It would certainly make sense to allow admins to require them to always be the same, though -- as long as the backend doesn't have usernames that MediaWiki doesn't allow. > This actually makes me think of another case that needs to be handled. If > the local database has a username that is the same as a username in LDAP, > but has an external ID recorded that is different from what is in LDAP, the > account in LDAP was likely deleted, but the username was re-used. The plugin > should block login in this situation, so that the admin can rename the > account to something like "Username (deleted)" or "Username (was <uid>)". > This is important from an auditing perspective. This is only an issue if backends don't expose a stable user id that's guaranteed not to be reused. If LDAP really doesn't expose such a thing, it's crazy :), but I guess it will need to be handled. > All of this assumes that account renaming can be initiated reliably from an > authentication extension. This isn't currently possible. Why isn't > RenameUser part of core? I don't know. If it's necessary, it can always be merged to core, IMO. That's the nice thing about developing in core. ;) On Thu, Mar 25, 2010 at 12:08 PM, Lane, Ryan <[email protected]> wrote: > Yeah, I seriously doubt any system is going to have a unique identifier > longer than 255 characters. I know after this is implemented I'll find some > crazy organization doing this though ;) (like the one that had a user with > over 500 groups - crazy). If they do, they can ALTER TABLE to change it to a larger size if they like. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
