Store username instead of email in make records

RESOLVED WONTFIX

Status

Webmaker
MakeAPI
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: cade, Assigned: cade)

Tracking

Details

Attachments

(4 obsolete attachments)

(Assignee)

Description

4 years ago
This change will eliminate the need to hydrate search results with usernames using the LoginAPI.

Pros: less load on login server, faster response times from makeapi, less nonsense and hackery in DSL generation code and search response handling code.

Cons: We'll have to build processes that ensure make ownership is maintained when account details change. We don't provide ways to change username without deleting an account right now, so that's a future thing to think about. The account deletion process must delete all makes associated with the account being deleted, to ensure that if someone claims the now freed username in the future, they don't also claim a bunch of old makes.
why not use a UUID that can be stable across both email and username changes?
(Assignee)

Comment 2

4 years ago
Using a UUID would fix the email problem, but would still require some party to make authenticated LoginAPI calls to translate the UUID into a Webmaker username. Preferably I'd prefer not to have that overhead if it can be avoided, and handle the problem of just updating makes when a username changed, and ensuring makes are deleted when an account is.

Comment 3

4 years ago
It'd require authenticated loginapi only because we coded it that way. I think opening up the loginapi to support searches via userid or username is a good move. And having a UUID that's stable across both email and username changes is the best solution here.
(Assignee)

Comment 4

4 years ago
Then the solution I shall now propose it this:

1. Make records store only a Webmaker accounts UUID.
2. Search requests can ask for hydrated results - uuid -> username - but will not be hydrated by default
3. The Login API should provide an API method that lets the Make API translate any given number of UUID's into a list of usernames, to limit hydration to a single HTTP request. This method could potentially be made without the need for basic auth/hawk to eliminate that overhead, since username and UUID aren't generally PII, but I may be wrong.
(Assignee)

Comment 5

4 years ago
Created attachment 830902 [details] [review]
https://github.com/mozilla/login.webmaker.org/pull/201

Part 1: Route for login server that can hydrate multiple user ids into usernames! I wrote a test for it as well.
(Assignee)

Comment 7

4 years ago
Created attachment 8338020 [details] [diff] [review]
https://github.com/mozilla/MakeAPI/pull/174

No rush on this one Jon. Just don't want to let it get lost.
Attachment #8338020 - Flags: review?(jon)
(Assignee)

Comment 10

4 years ago
gah. wrong bug.....
(Assignee)

Updated

4 years ago
Attachment #8338020 - Attachment is obsolete: true
Attachment #8338020 - Flags: review?(jon)
(Assignee)

Updated

4 years ago
Attachment #8338022 - Attachment is obsolete: true
Attachment #8338022 - Flags: review?(jon)
(Assignee)

Updated

4 years ago
Attachment #8338024 - Attachment is obsolete: true
Attachment #8338024 - Flags: review?(jon)
(Assignee)

Comment 11

4 years ago
With the addition of the /usernames route to login.webmaker.org ( bug 942338 ), only one request will ever be made to the login server on any given makeapi search. I don't think we need this ticket anymore.

Marking won't-fix
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.