This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Would it be possible to pull a check on the user auth? We’re using AWS Cognito, and it would be cool to check if the user is in the pool or disabled during a sync.
Don’t know if this is possible or not, but it would be helpful if this 60 days could be extended, or maybe as a pro account feature. My users are not great with tech, and often mess up the log in stage, so it would be great to extend this as much as possible. I realize 60 days is already a long time though. Thank you!
On the flip side, it would nice to be able to reduce this. Some organizational policies mandate that login sessions not persist beyond a certain timeframe.
We check access permissions every time an app is accessed in our cloud service (approximates to every sync, but also a number of other operations). For apps using whitelists, the moment you remove the user from the whitelist, that user will fail on their next sync (which could even be a background sync) and after that the app becomes unusable. For apps using domain auth and groups, it is expensive to check group membership, so we cache this membership for upto 15 mins. Which means that if you remove a user from the group that has access to the app, then within 15 mins, AppSheet will know that this change has happened, and on the next sync, that user’s app stops working. In the case of Cognito, we have not yet implemented groups at all — we’re just associating access with membership in a user pool. As Jonathon pointed out, we are checking for membership during initial access/login, but not during repeated access. We have active dev work to fix that and should be deploying it soon. @Scott_Haaland@vinothp FYI
PS: the lifetime of a login cookie is raised in this thread. I think we could provide a knob to control that, but we have been hesitant to provide knobs that control low-level behaviors that most people don’t understand well. For every informed person who sets it intentionally, there’s usually five who set it wrong and run into trouble. So that’s where I currently stand on this – we could learn of course that this is an important issue to enough people, but so far, it does not come up much.
Hi All, I have some good news for you. We’ve been working on fixing this issue with Cognito, and it was just released to AppSheet. Here’s what we did:
The App Creator will need to provide some extra configuration for the AWS Congnito Auth setup in AppSheet. We need to get an AWS User Key ID and Secret (With AmazonCognitoReadOnly permission in AWS IAM) configured so that we can read the Congnito UserList.
We will check that the app user’s auth is valid on every Sync. However, we will cache the auth status of the app user and only hit the Cognito back end after 15 minutes, otherwise, continual syncs during that 15 minute window will use the cached auth check. This should minimize the extra latency of an Auth check on every sync.
If the user does not have access (for example, if you remove them from the Cognito UserList), then they will receive this error message when they try to access the app (after the 15 min cache time) : “Your account xyz@xyz.com (1321237) is not authorized to access appxyz-1233213.”.
If you have an App that is already created and you haven’t provided the extra Cognito Id/Secret information, AppSheet will continue to work as it did before the fix. We will just check the local auth cache and not hit the backend Cognito Auth.
We will update the docs to reflect this asap.
A big shout out to engineering who jumped on this and got it fixed quickly. I hope it works for your “Remove a Terminated employee from your app” use case. Let us know if you have any questions.
I made the appropriate updates to the auth domain in my AppSheet account, created the role in AWS IAM; and updated the Cognito user pool. Pretty simple process assuming I did it all correctly!
Doesn’t appear to work in my apps yet, but I suspect that the change has yet to propogate to my account.
Thanks Jonathon for the feedback. I can have engineering check to see if your account is updated, but I suspect that if you saw the extra id/secret configs in the Cognito setup screen, then it should be there already. Can you send your account info to me in a DM.
Can you let us know how you are running your test, step by step, and we can try to reproduce it?
Hello, can I achieve the same result with google log in? ie force everyone to log in afresh after a couple of days etc? Some of my users are borrowing phones to work in the app which leaves me worried about security
LinkedIn
Twitter
