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