Succesful Auth can create orphaned record on user_id_eid_map
Description
Activity
Filter Maintainer August 8, 2008 at 6:04 AM
2.5.0 QA has been completed. Unfortunately, there were not resources available to specifically test this issue. If you find this to still be a problem in the latest release (at this point 2.5.2), please reopen the JIRA and add the latest affects version.
Megan May February 5, 2008 at 2:53 PM
Updating 2.5.x to 2.5.0.rc1 since the tag has been cut
David Horwitz January 16, 2008 at 1:23 AM
merged into 2-5-x with r40153
Ray Davis January 15, 2008 at 4:23 PM
I revised the UserDirectoryService logic to resolve the no-user-found ambiguity the other way (skipping the legacy "authenticateUser" method), which should maintain backwards compatibility for authentication-only providers.
Checked into trunk at revision: 40148.
Any existing "junk" records in SAKAI_USER_ID_MAP will have to be deleted by hand. Once we have confirmation on the fix, this should be merged into 2.5.x for the 2.5.0 release.
Ray Davis January 15, 2008 at 1:11 PM
Regarding the "ghost" record in the SAKAI_USER_ID_MAP, another background issue is that the only two required fields on a Sakai user record are ID and EID. Handed a near-blank user record, your provider said "successful authentication!" and handed the near-blank user record right back again. At which point the UserDirectoryService said, without bothering to check anything else, "Cool, I guess the provider knows about this EID after all" and happily mapped an ID to it. Again, it looks like the best solution will be to disambiguate the other way and not call the legacy authentication method if the EID didn't retrieve a user.
If you have configured sakai to authenticate against a provider (e.g. LDAP) but which stores user information localy (i.e the provider getuser methods always return null), and a user successfully authenticates but has no internal account then a record is created in SAKAI_USER_EID_MAP for the user. This effectively leaves the database in a corrupt state for this configuration.
If the provider is not supplying a user then no attempt should be made to create the eid_id map