I'm splitting off the documentation needs in #817118: Remove {authmap} and migrate OpenID entries to their own table to a new issue.

In a nutshell, the {authmap} table is poorly documented. Most of the confusion results from the unique keys on the authname column. This means that if...

In case multiple external authentication mechanisms are employed, it is possible that an identical authname is defined in more than one external authentication mechanism, and thus an authname occurs twice in the authmap table with two different uids.

The proper use of the authname column is described by Damien:

@Dave Cohen: indeed, you need to use 1234@facebook, not 1234. The module column is there to all modules to quickly find all the authentication maps that belong to them (OpenID uses that, for example, to display the list of identifiers you have mapped to your account).

This stuff is mostly undocumented, I believe, so starting by documenting it would be great. As far as I know, there are no performance penalty either way, so I see no compelling reason to change that in D7, which is long API frozen.

Comments

bfroehle’s picture

Issue tags: +Needs documentation

Tagging.

jhodgdon’s picture

Where do you propose that this should be documented -- in the database schema?

bfroehle’s picture

No, probably in user_set_authmaps(). I haven't figured out the exact wording yet, but the message needs to be that the username (i.e., the value of the 'authname_MODULE' key) needs to be globally unique amongst all external authentication schemes.

Also, since the talk in #817118: Remove {authmap} and migrate OpenID entries to their own table is leaning towards removing this functionality in D8, a note saying @todo: Remove this function in D8 might be a nice warning for developers.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.