Closed astralbodies closed 7 years ago
I don't think we should use a UUID. Some thoughts:
username
. Maybe we just call /me
before creating the account and storing the credentials, maybe we include more account details in the OAuth2 /token
response.setUsername:
fix (if we added some multi-context safety to it).@diegoreymendez is this resolved by #3967 do you think?
My PR only solves points 3, 4 and 5. The logic we use for storing the username still needs to be reviewed.
I agree that we should never store the email of our users as the username. We should let them log in and call /me
to retrieve the proper username as @koke pointed out. The username's case sensitivity should be taken into account, too.
We also need to make sure we have the logic in place to handle the token being invalidated, and other scenarios that could require re-authentication.
Also: re-authentication currently doesn't care if you log back in with the same account or a different one. This is something to fix, although it probably deserves a different ticket.
I'm dissociating myself from this issue for the time being, since this is not the current priority.
This hasn't been looked at in a year, and points 3, 4 and 5 were addressed - @astralbodies what do you think? Can we close it?
We can close it - we'll eventually want to address it again when supporting multiple accounts.
Related: #3950
When storing the OAuth2 token of a WPAccount instance make sure to use a key for the iOS Keychain that isn't the username. The username is a volatile piece of data and changing that will cause the token to be lost in the keychain with no way to fetch it. #3956 fixes this with a workaround but it's not the final solution.
This issue will require fairly extensive testing. Two-factor auth, restore from backup, revoking tokens from server side, etc.
cc: @sendhil @koke @diegoreymendez @oguzkocer @SergioEstevao @aerych