Several of us who have implemented alternate login management have encountered the same problem viz. the TWiki core code assumes that groups can be fully loaded, so it can do its own membership test. This is really a hangover from file-based users/groups, and needs to be sorted once and for all. The API needs to allow a user mapping manager to provide a group membership test. I had a chance to fix it when I abstracted the password managers. Sven then had a chance to abstract it when he did the user mapping code. Both of us missed the ball.
need at least:
TWiki::User::isMemberOf($group) -> $boolean
TWiki::User::getGroups() -> \@listOfGroup
These methods also need to be exported to the
TWiki::Func
API.
I am marking this as an enhancement to avoid making it a release blocker, though arguably it should be a requirement.
CC
This is very far-reaching. For example, all functions in
User.pm
, and as
a consequence in
TWikiUserMapping.pm
, need User objects to do their check.
These are created using
findUser()
or
expandUserList()
. In the situations
under consideration (e.g. in
TWiki::Access.pm
)
you can get along by only using the WikiNames instead of full fledged
perl objects.
So (a) one should not create so many User objects and (b) one should omit to
create User objects at all and only use their WikiNames if possible.
One example of a heavy weight function is
groupMembers()
which returns
a list of User objects that are used to check if the current user is a member of it.
The final check is a simple call to
equal()
to see if the two names are equal.
This function in itself requires two User objects to do the comparison. Overkill.
What would be enuf is a
groupMemberNames()
that simply returns the names
of the group members instead. As groups can be nested the check
isGroup
,
which also is an ObjectMethod, needs to be able to perform on simple
strings.
And so on.
MD
I've attached a
patch that implements the above.
Caution, this is not tested yet nor benchmarked. It is simply the stuff I've done so far.
MD
Second version of the patch. AccessControllTests pass now.
MD
Thanks for the work on the patch micha; but I'm afraid this just isn't mature enough to go into 4.1 as-is. So I'm resetting this to New and let's hope someone picks it up and actually merges the code. For now, I'm going to continue with my existing non-core solutions.
CC
The work in the patch shows that we can get away with the TWiki::User object
all together. In this respect the patch is only a start. Nevertheless the code does
work out properly. It only needs testers.
CC, is there any other objection wrt to the actual patch? Which non-core solution
does there exist you are currently using?
For now I'd say that we defer the attached patch til 4.1 is out, then work on
eliminating the TWiki::User object all together and push this item up in the prio
so that it gets more visibility and testers.
MD
Followed up in
Item3838 by a wider-reaching change, so closed no action.
CC