API makes assumptions about email uniqueness amongst active users

[jameswettenhall]

The API extensions provided by this app makes some assumptions about email address uniqueness amongst active users:

The following code will raise an exception (and trigger an Internal Server Error) if there is more than one active user with the same email address:

User.objects.get(email__iexact=user_folder_name, is_active=True)

The most likely scenario where this could happen is if a user logs in with a new authentication method (e.g. OAuth), having previously logged in with an old authentication method (e.g. LDAP), but they don't immediately migrate their account, so the old account remains active.

get could be changed to filter, and if multiple matches are found with User.objects.filter(email__iexact=user_folder_name, is_active=True), then it could choose the most recent one (largest User ID), or the largest User ID associated with at least one ObjectACL if one exists.

[jameswettenhall]

The User.objects.get... code above is used by the MyData API extensions' /api/v1/mydata_experiment/ endpoint to determine if an appropriate experiment exists to upload data into.

A related issue is the question of how MyData looks up a User record from a user folder name, which is described here: mytardis/mydata#246 and here: mytardis/mytardis#2301

In that case, there is potential confusion after migrating an account, because the MyTardis API could still find the user's old account when MyData is looking up a user folder name.

One option could be to delete the old account after migration instead of simply marking it as inactive.

Or we could use the "approved" field in the UserAuthentication table to mark all new OAuth accounts with existing LDAP accounts with the same email address as unapproved until they have migrated their account.

But whether we use the "approved" field in the UserAuthentication model or the "is_active" field in the User model to clarify which user account should be associated with a user folder, we either need some changes to MyTardis's /api/v1/user/ API endpoint, or we need to add an /api/v1/mydata_user/ API endpoint in this mytardis-app-mydata app. Because currently it is difficult for the client application (MyData) to find the correct user account to create an ObjectACL for.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.