Allow looking up users by an email address

[andrewshadura]

This patch adds an option to look up users by an email address. This is useful for example for tools manipulating or synchronising the user database with other sources.

The new API does not pose any greater privacy or security risk than the currently available APIs, since they already allow finding a user by their email address, albeit much slower (list all users, iterate over users, request emails; possible to optimise by first checking users with usernames similar to their email addresses).

Example of the usage:

$ osc --debug api '/person?email=andrew.shadura@collabora.co.uk'
GET https://obs-api/person?email=andrew.shadura@collabora.co.uk
<directory count="1">
  <entry name="andrewsh"/>
</directory>

[dmarcoux]

I'm not against this, but I'm also not entirely convinced. So when you write This is useful for example for tools manipulating or synchronizing the user database with other sources, I would be interested to hear more about those tools.

If we decide to go ahead and introduce this feature, it should be documented in the API documentation. We would also need an index on the email column in the users table. I can guide you with this, but first I'll wait on details about the tools.

[andrewshadura]

We’re currently writing a tool to synchronise group membership with an external database, so when a (new) user logs in, they’re added to the corresponding groups. The upstream users database does not use usernames at all, but uses emails as the primary identifier; to keep the performance within safe limits, we need this extra API, otherwise as I outlined in the PR description, it’s way too tedious to extract the same information from the API.

I must admit this works quite well without any additional indices. The current work-in-progress patchset for OmniAuth-based SSO uses find_by_email (which ends up doing the same query) and it works well enough for the purpose.

This query is not expected to be used frequently anyway, so slower performance shouldn’t be a big issue.

[hennevogel]

I'm against to enable this for regular users. Only for admins please.

[andrewshadura]

Can you explain the reason please? As I mentioned, this doesn't expose any more information than is already available through other API methods.

…

On Wed, 1 Sep 2021, at 12:06, Henne Vogelsang wrote: ***@***.**** requested changes on this pull request. I'm against to enable this for regular users. Only for admins please. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11562 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLQBKUWW3YDDBFFCGKN7LT7YCNFANCNFSM5DEHBDXA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Cheers, Andrej

[hennevogel]

Can you explain the reason please?

It's making it too easy for my taste to check if some email address has an account.

[adrianschroeter]

you can achieve the same via xpath search already

/search/person?match=@email=...

[vpereira]

@andrewshadura User.where(email: params[:email]) to make the linter happy

[hennevogel]

So yeah this is already (although undocumented) possible...

osc api "/search/person?match=@email='hvogel@suse.com'"
<collection matches="1">
  <person>
    <login>hennevogel</login>
    <email>hvogel@suse.com</email>
    <realname>Hendrik Vogelsang</realname>
    <state>confirmed</state>
    <globalrole>Staff</globalrole>
  </person>