Introduction:
This document describes the design approach of creating and switching of Managed User’s account
Background:
Jira Issue: https://project-sunbird.atlassian.net/browse/SH-68
https://project-sunbird.atlassian.net/browse/SH-95
Epic: https://project-sunbird.atlassian.net/browse/SH-67
Presently only user having email address or phone number can register and use application.
Problem Statement:
How managed user account can be created.
How to switch between different managed user account and user account.
Key design problems:
How to map actions performed by managed user to his account.
Telemetry should be mapped with different user ID.Device ID will be same for user and managed user.
Existing workflow:
User login in to his account and starts using application.
Change request: As part of https://project-sunbird.atlassian.net/browse/SH-68 user should be able to switch and create profiles.
Below is data store in session
Solution 1:
Create separate session - 1. User session
2. Managed user session.
Both sessions should reference to each other internally.
It can be handled via 2 different approaches -
Creating sub session and adding a pre-fix for all the routes which will generate 2 session ID.
Create and maintain 2 session objects referencing to userId
Pros:
Cons:
Maintaining multiple sessions could be cumbersome and lead to errors.
Adding prefix to routes could be extra work.
Solution 2:
Changes references like userid roles and other necessary things in existing session and portal automatically starts to use that.
Things to reinitialise -
Telemetry
User profile
Update UserId in elements in inde.html
Proposed changes to session object
Pros:
Simple to do.
Cons:
Increasing size of session data.
Managing session data each time when profile is switched.
Session ID remains same for user and managed user profile
Solution 3:
Things to reinitialise -
Telemetry
User profile
Update UserId and session ID in elements in index.html
Challenges :
Securing switch user API as it can generate token/login any user.
Securing API for mobile as mobile will generate token from portal
Notes -
2 user ID current user and switching user id should be send.
Verifying user id after fetching details
Things to discuss -
Storing session id and mapping it with User Id in cassandra (where portal store sessions)
Cassandra TTL might delete the other mapped data (not sure NOC team says they dont add explicit TTL currently).
Fetch user details should give details of parent if parent exists
How to do in mobile
How mobile will support offline swtich (as switch requires to generate token)