Hi @NeilF ,
If you’re OK with users forgetting to logout on a public device and sharing data between users, the easiest solution would be to just NOT require any login.
I’m not too familiar with multiple user sessions - but I’m pretty sure they have a different purpose than to compensate for users being careless on public devices.
@thijs You’re assuming a lot in your last response (I’m OK with it, it’s a public device…), and your reply is not particularly helpful or insightful. I’ll go elsewhere for some support with this as you have nothing constructive to offer on this topic.
Hi @NeilF my sincere apologies - it’s not in my interest to say something that’s considered ‘nothing constructive’. I tried to be helpful - and honestly I thought you might be overlooking a security risk. English is not my native language, I was struggling to find the right words for my last sentence (and reading from your response failed to do so).
hi,
don’t know if it’s work for you, but you can add “xano logout” action right before the new login process.
I think it will erase all the existing tokens from the local storage. So, the new user login will only have their own token.
Thanks Batik, I’ve tested this and seems to do the trick 
Hey @Alexis , just wondering if the team has considered implementing this yet?
Often what happens is the user clicks around, and suddenly no data comes through. They will then refresh the page and it logs them out. This thread has great solutions for the logout on 401 error with the custom code, but having a ‘on 401 logout > login page’ global workflow would be really neat.
Additionally, I am using Azure OAuth with Supabase. Microsoft usually stores a refresh token somewhere on the browser so that you never need to log in again depending on the Microsoft tenant’s authentication policies - is there a way I can benefit from grabbing that refresh token or something for the Weweb authentication?
Many thanks in advance
Hey all. Old thread but just wanted to add that I had this same issue (just like anyone using weweb will) and my solution was 2 fold.
Now in Start Session Management what I am doing is tracking ANY sign of user activity. Button click, mouse movement, anything. If I detect user activity, I refresh the token using the weweb action (it’s silent), and then reset my timer. As long as the user keeps using the app (my time interval is 5 mins) so as long as the user does something once every 5 minutes, I don’t refresh, that’s normal usage. So the user has no idea. Now in a case where the user has been off for a long time (longer than 5 minutes), when they come back as soon as they do anything, even just click the UI I run the refresh flow and if the token has expired, I show them the login popup there and then. They login and the session begins. The UX is that user’s can’t do anything with an expired token, so the only thing they can do is login. And they continue where they left off, I don’t redirect them back to the login page.
This is the code I use to track user inactivity if that may help:
const inactivityLimit = context.parameters['inactivity window'] * 60 * 1000;
const refreshInterval = context.parameters['refresh interval'] * 60 * 1000;
const showSessionExpiredModalUUID = context.parameters['refresh token WF'];
const refreshTokenWorkflowUUID = context.parameters['refresh token WF'];
let inactivityTimer;
let lastRefreshTime = Date.now();
function handleUserActivity() {
resetInactivityTimer();
if (shouldRefreshToken()) {
wewebExecuteWorkflow(refreshTokenWorkflowUUID);
lastRefreshTime = Date.now();
}
}
function resetInactivityTimer() {
clearTimeout(inactivityTimer);
inactivityTimer = setTimeout(() => {
handleInactivity();
}, inactivityLimit);
}
function handleInactivity() {
wewebExecuteWorkflow(showSessionExpiredModalUUID);
}
function shouldRefreshToken() {
const now = Date.now();
return now - lastRefreshTime >= refreshInterval;
}
function wewebExecuteWorkflow(workflowUUID) {
if (typeof wwLib !== 'undefined' && wwLib.executeWorkflow) {
wwLib.executeWorkflow(workflowUUID);
} else {
console.error('Weweb library not available.');
}
}
function startActivityTracking() {
// List of events tracked for user activity
const events = ['click', 'mousemove', 'keydown', 'scroll', 'touchstart'];
events.forEach((event) => {
wwLib.getFrontDocument().addEventListener(event, handleUserActivity, false);
});
resetInactivityTimer();
}
startActivityTracking();
So to summarize how I did it - 1. Track user activity. 2. Set a timer to track when last did your user do anything and set a threshold. 3. Each time your user does something once it is past the inactivity threshold you want, refresh the token - the user will not know so nothing happens. BUT this gives you an insurance that IF the inactivity is too long such that the token has already expired, simply give them a login-in-place option and then let them continue. That way UX and security is balanced.
Thanks AgentD for the ideas and code examples. What’s the overhead on the client running this call at the desired interval? If you don’t re-download all the auth-me data I’m guessing it’s not too much?
The earlier thread 401 logout code I had running previously and it worked - but if I have components or pages where there are different role-based api calls and they get run in the background for a user that doesn’t need them (maybe a collection is grabbed on load as example), then the user gets logged out since it’s an unauthorized/401 api response. So I like the other ideas in the mix