How to force all user sessions to an APP closed

[Eso_Surveyors]

hi,
i had to change (restrict) an APP sharing from “all domain” to 10 approved emails in that domain.
but some users who are not in the 10 approved can still open the APP without problem.
i cannot know who all those unwanted users are, the history is only 1 day on my plan
how can i **force ** closed all user sessions to the APP centrally,
so that unapproved users are forced to sign in again,
hence be blocked?
cheers.

[Steve]

I’m not aware of a way to do what you want. I recommend you contact support@appsheet.com for help.

[Eso_Surveyors · Accepted solution]

I have, @Steve , there isn’t one. thanks anyway.

[Lynn]

Hi @Eso_Surveyors
One thing you could do which may or may not be suitable for your situation is make a copy of the app and delete the old one. Then sign up your wanted users again to the new app.

[Eso_Surveyors]

thanks, Lynn.

i’ve considered it, and probably will have to experiment with that.

the complication i see straight away is with the option to copy or not data along with the APP.

the APP in question is part of a client’s APP “ecosystem”, where APPs share other APPs sheets, like STAFF, ASSETS, and so on.

When i choose to copy APP and DATA, copies are made of the shared sheets as well.

the sheet copies inaccessible to the other live APPs.

does that make sense?

cheers.

[Steve]

Could you explain a little more about what access the non-whitelisted users (still) have access to?

Also, how did you “approve” the users? From within the app editor in the Users >> Users tab?

[Eso_Surveyors]

sure,
it used to be:

i changed to:

user n.fisher@eso… had opened quotes before the change.

he could still open it after the change, despite the setting to "sync on start:

[Jonathon]

Related:

Check User Auth During Sync Feature Requests

We currently retain user login information in a browser cookie — this ensures that the user doesn’t have to sign too often. This is maintained for a long time (I think 60 days). When we check app access control permissions, we are currently only checking that the user successfully signed in via that specific Cognito endpoint (but we do not check if they are still valid members). Point taken – we will add that. The refresh token stuff is nothing to do with this. That is meant for a different ki…

[Eso_Surveyors]

spot on,
thanks.

[Eso_Surveyors]

@Jonathon @Steve @Lynn
HI, any ETA on when we can see a fix to:

We currently retain user login information in a browser cookie — this ensures that the user doesn’t have to sign too often. This is maintained for a long time (I think 60 days). When we check app access control permissions, we are currently only checking that the user successfully signed in via that specific Cognito endpoint (but we do not check if they are still valid members)