feat(account): add Account Preferences #205
Conversation
- Adds `GET /account/:id/preferences` - Adds `POST /account/:id/preferences` The first "preference" is `signinConfirmation`, which we can use to determine if a user wants to always receive signinConfirmation no matter what. The design of the `signinConfirmation` column is an integer, so it can easily be expanded upon, such that other numerical values can be used to signal that a user desires different kinds of confirmation, like Push Notifications or a mobile authenticator code. Current values: 0 = don't force signin confirmation 1 = force email signin confirmation
|
Part of mozilla/fxa-features#68 |
|
Without wanting to heretical here, I wonder...I wonder if it's worth using just a big old JSON blob for the user's preferences, so making it simpler to add/modify/migrate new preferences over time. Or is that just a crazy Friday-afternoon thought bubble? |
|
I considered that something like that might be nice in the sense that it's less work for us, less MySQL patches. It also means possibly less efficient queries, since you don't get direct offsets on columns. I don't know exactly how InnoDB would store and lookup on the primary key. If it's that BTree you've mentioned, with pointers directly to the next row, I suppose that part wouldn't matter much. I'd expect that a DB could optimize for when the rows are exact sizes, and so any row is always a certain offset from the previous row. |
Heh, no I don't think so. I had similar thought about how FxA user preferences would look. For example, I could see a user wanting to define a custom timeframe where this preference is enabled or only for certain situations, oauth, sync logins etc. This seems like one of the times where having the flexibility to define a preference could be very beneficial. Also, newer versions of Mysql support the JSON datatype and that could alleviate some of the query performance issues if we eventually migrate. Either case, user preferences FTW! |
|
Closing this for now, I hope we bring this back though :( |
GET /account/:id/preferencesPOST /account/:id/preferencesThe first "preference" is
signinConfirmation, which we can use todetermine if a user wants to always receive signinConfirmation no matter
what.
The design of the
signinConfirmationcolumn is an integer, so it caneasily be expanded upon, such that other numerical values can be used to
signal that a user desires different kinds of confirmation, like Push
Notifications or a mobile authenticator code.
Current values:
0 = don't force signin confirmation
1 = force email signin confirmation