This could work too, but it could be really expensive depending on the length of the cache.
Yes, it depends. If you're authenticating to some MySQL-based forum on the same server, then it's typically just one extra query per view, which is no big deal. In other situations it might be different.
In a really large LDAP database, you may be doing hundreds of queries, to multiple LDAP servers (if replicated directory trees are being used). The number of queries can vary drastically depending on if nested groups are supported, if memberOf is supported, how you implement the searches, and how accurate you want to be. In environments this large, you are likely to have hundreds or thousands of people logged in simultaneously. On most small to medium LDAP directories, this will range from 1-10 queries per person.
We could have a hook that gets passed the ExternalUser object, and add a getProperty() method or such to it. We could also have a $wgExternalAuthUsePropertyForName or something to set the name to a particular property instead of username.
Hook/getProperty() sounds perfect. I like it more than the global approach, because it may be possible to set more than one property if need be.
Hmm. That means you can't actually retrieve any data about the user at all if they don't enter their password, right? That would explain why nothing would update until the next login, because you can't retrieve the new data until the next login. So LDAP will have to store a lot of things that could just be retrieved on demand with a simple database backend, for instance.
It isn't impossible. If a proxyagent is used, data can be fetched without the user being authenticated. In the LDAP plugin, a proxyagent is required for auto-auth, since the user never actually logs in, in the traditional sense. A proxyagent is supported in regular authentication as well. Some admins don't want to create proxyagents though, for security reasons; since it is possible to operate without one, I allow both solutions.
We could add a eu_cache column that's just a blob that backends can throw anything in that they need to cache. Then the LDAP id could be used for eu_external_id, and anything that relies on creating an ExternalUser from id will use the cached data. At a minimum, usergroups would need to be cached, it sounds like.
Well, user groups are already cached, in a way. When a user is added to a group via $user->addGroup(), it gets added to the local database. As far as I know everything is stored locally for users, in some way. I treat the external database as something to be synced with, not as a real backing store.
Respectfully,
Ryan Lane