Feature #15061
Updated by Peter Amstutz about 5 years ago
New design, based on discussion Apr 17 h3. Existing user: # When a user logs into a home cluster, make ajax calls to known federated cluster login endpoints to say "this browser prefers cluster X as home" which returns a cookie. # User arrives at a federated cluster. The login button takes user to login endpoint on API server. User can also choose a specific home cluster for log in. # Request to login endpoint includes cookie saying user prefers cluster X, which can be overridden with an explicit query parameter that indicates a home cluster # API server redirects login to proper home cluster h3. Migrating to remote account (because you have an existing account or created one by accident) # User logs in to local account # User selects "migrate account" and selects home cluster X # Current token is saved in local session storage and user is redirected to log into cluster X # User is redirected back to cluster with salted token from cluster X # Everything owned by local user is reassigned to remote user and local user is marked "redirect_to_user_uuid" to the remote # User now uses token Complete logging in as remote user h3. Logging into a redirected account, no cookies or other hints telling us which cluster to use: # User logs in to local account # After log in, we realize redirected user is not local # Display a page that says "this has been migrated to a remote account, must log in at home cluster" # Redirect to home cluster # User logs in a second time (Existing user flow) h3. Scripted user migration # Admin generates list of email address and/or usernames assigned to each home cluster # Get list of users on each cluster # If there are user records with the email address or username that doesn't match the assigned home cluster, perform account merge # Need to tweak "merge" endpoint for admin variant which accepts "old_user_uuid" and "new_user_uuid" instead of using current token / "new_user_token"