Table {authmap} table is not synced on user insert or delete. This means when some module (e.g. user import or similar) or admin creates/deletes user accounts, webserver_auth isn't familiar with these events. Users added by admin or other modules wont be able to log in into Drupal if "Automatically Create user when user does not exist in the Drupal user table" options was disabled.

Provided patch is adding functionality to add or remove users from {authmap} table on hook_user_insert and hook_user_delete hooks.

Looking forward for review and comments.

CommentFileSizeAuthor
#3 authmap_table_sync_184066_2.patch822 bytesesolano
#1 uathmap_table_sync.patch4.13 KBAnonymous (not verified)
uathmap_table_sync.patch4.16 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
FileSize
uathmap_table_sync.patch4.13 KB

Updated patch to remove dsm calls.

esolano’s picture

esolano CreditAttribution: esolano commented

Hi psheiman,

When Admin is creating a new account, your function webserver_auth_helper_get_authname() returns the Admin's username. This will create (or update) a record in authmap with the uid of the new user being created, but with the wrong authname, which should be the username for the new user being created, instead of the Admin's username.

I'm not sure what your webserver_auth_helper_get_authname() function is there for. Shouldn't this simply add a new record in the authmap table with the new user's info coming in the $account object?

Regards,

esolano’s picture

esolano CreditAttribution: esolano commented
FileSize
authmap_table_sync_184066_2.patch822 bytes

Hi again,

This is a patch we created to address the issue in comment #2.

Regards,

specky_rum’s picture

specky_rum CreditAttribution: specky_rum commented

Interesting. I can see why this causes a problem but I actually thought that it was "by design". I mean, why have an authmap table if it is just going to contain an exact copy of the user table?

The idea was, I thought, that only users added by this module were listed in authmap deliberately so that this module can only log people in that it registered. If you do a mass import you have to copy the user entries into authmap as a one off job but once the module is installed, if it is the only login method you're using there should be no need to create users manually anyway, you should always let them login once and then grant the created user the permissions it needs. If this isn't the only login method you're using then you may not want to allow people to login across methods as a security precaution?

See the description of the user_set_authmaps function which says: "Save mappings of which external authentication module(s) authenticated a user. Maps external usernames to user ids in the users table." therefore if another module registered this user then this module has no business with it.

Thoughts?

specky_rum’s picture

specky_rum CreditAttribution: specky_rum commented
Assigned: » specky_rum
Status: Needs review » Closed (won't fix)

Having looked into this issue again I don't know why this patch was ever created? There is code in the module that already does exactly this, you just have to turn the option on in the settings.

The authmap table is present to enable different modules to log people in without conflicting with each other and this patch (and the already implemented code) goes against that design although clearly in most cases where this module is used that will be the requirement. I'm going to implement an alternate method which will enable you to tell the module to ignore the authmap table when logging people in and instead to use the users table. This will mean that historic and future new users will all be able to login via this module if authenticated by the web server which will I think, be a better way of solving the same problem. I will leave the current method in too but mark it as not recommended.