-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complete a technical breakdown for decommissioning Tokenserver #1582
Comments
Can this doc be made public ? I'm interested in following how tokenserver evolves in the future. |
At this point, this evolution is but one proposal, and we haven't moved ahead with any plans to changing tokenserver's behavior or role. |
As a bit of general overview about this... In The BeginningWhen Sync was originally designed, microservices were just starting to become "a thing" and there were starry eyed systems architects that dreamed of being able to let users grant third party access to their data stores using a separate credential system. In addition, we needed sync to run on a horrific number of servers because the back end database couldn't support all of our users and the machines kept dying, so we built some really clever code to divvy users up to a given node, and then remember where they were (up until the machine caught fire, again). Time marched on, reality set in, and a few hard lessons were learned:
Work was done and we moved all of the nightmare stuff we had to do to less nightmare-y. That left a nearly vestigial token server hanging out. Someday Around Tea TimeSo let's look at what token server did vs. what we need it to do.
So yeah, that's were things are at. Tokenserver does some validation on the "token" the User Agent passes us to indicate that you really are you. That token is created and blessed by FxA (which is the only thing that can say if You are You). We could roll that authentication stuff into the main Sync Server (and we did some leg work already around this) which would kill off the need for a separate machine with it's own database doing some magic. Goat path to TomorrowMind you, it's not just "us" working here. Remember how I said that FxA are the only ones that can say You are You? We need to work with them to make sure that things work right. FxA is also looking at that 15 year old code and wondering if there's an opportunity to make things a lot easier and better. (If you listen carefully, you can hear the folk working on Thunderbird cheering right now.) We also have to deal with the UserAgent. Not just the most recent one, but all of the old, in use versions that are out there still. Both for desktop and mobile. That means that we have to come up with an "interim" fix which will probably be "temporary" for 7-10 years, so we're thinking about this pretty darn hard. The document goes over some plans on all of this. It's not public mostly because in the past when we've brainstormed on stuff some folk took those ideas out of context and started panicking. We've learned to be a bit more close to the vest about that sort of thing and only announce stuff once we actually have a road map. At this point, we have a collection of goat paths and one torn piece of parchment with a bunch of "Here Be Dragons" scrawled on it. Still, we should be a bit more public about the fact that we're looking at ways to make Syncserver a bit easier and simpler, and hopefully this provides a bit of that. |
Let’s plan and breakdown in detail how we will accomplish the decommissioning of Tokenserver: https://docs.google.com/document/d/1gYy875bIYASuGDhoJYUYOBUMy73yH_eyXXu1Br3iw5s/edit#heading=h.5r69rom8w46i
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: