You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm starting this issue to discuss authentication state persistence:
Background information
We can specify what kind of authentication state persistence we want to enforce. Basically, when a user signs into the dashboard, we can choose to do one of the following with their authentication state:
indefinitely persist their authentication state until explicit sign out (called "local" persistence)
clear their authentication state when the window or tab is closed (called "session" persistence)
clear their authentication state on page reload (called "none" or no persistence)
It can be convenient to persist the user's state so that they don't have to explicitly sign in every time they visit the dashboard on the same device. However, given that the dashboard is likely to be used by multiple users on shared devices in schools, I think we don't want to use local persistence.
Short-term decision
In the short term, we should pick one persistence strategy for all users. Should that be "session" or "none?"
Long-term decision
It would be nice to develop a solution in which users in schools had "session" or "none," but users at home had "local" persistence. One way of doing this would be to deploy the dashboard to different subdomains (e.g., schools.roar.com vs. home.roar.com or some such). For the schools subdomain, we could enforce "session" or "none" persistence, while for the home subdomain, we could enforce "local" persistence. There are likely other strategies I haven't thought of.
What do you think?
The text was updated successfully, but these errors were encountered:
Is it easy to switch between these? Long term, it's a nice option to give to schools assuming it is a simple "one liner" to switch. Many schools we work with have one laptop per student. In that case "local" would be really nice. For others, I agree that session probably makes sense.
My bank, for instance, gives me a choice. It asks something like, "Is this a personal computer, or will others be using this device?" and it adjusts persistence accordingly. We might do that for the dashboard.
How often does the page auto-reload? I think session should be fine for schools-- does Clever offer any suggested guidance on this?
I'm starting this issue to discuss authentication state persistence:
Background information
We can specify what kind of authentication state persistence we want to enforce. Basically, when a user signs into the dashboard, we can choose to do one of the following with their authentication state:
It can be convenient to persist the user's state so that they don't have to explicitly sign in every time they visit the dashboard on the same device. However, given that the dashboard is likely to be used by multiple users on shared devices in schools, I think we don't want to use local persistence.
Short-term decision
In the short term, we should pick one persistence strategy for all users. Should that be "session" or "none?"
Long-term decision
It would be nice to develop a solution in which users in schools had "session" or "none," but users at home had "local" persistence. One way of doing this would be to deploy the dashboard to different subdomains (e.g., schools.roar.com vs. home.roar.com or some such). For the schools subdomain, we could enforce "session" or "none" persistence, while for the home subdomain, we could enforce "local" persistence. There are likely other strategies I haven't thought of.
What do you think?
The text was updated successfully, but these errors were encountered: