Users of my web app have requested an "offline mode" that stores their work on the hard drive while an Internet connection is not available. They could be offline for anywhere from a few minutes to multiple weeks, so in order to prevent loss of their work, I'll need to be able to persist the data, even when under storage pressure (using IndexedDB without the proper permissions could result in data loss).
I read on Google Developers that the asynchronous navigator.storage.persist() method can be used to request the user's permission to store files, but that doesn't work on Chrome - the promise always returns false without prompting the user.
Then I read here that Chrome may decide not to show a permissions popout, but instead grant or deny persistent storage permission based on a precalculated decision. This appears to be based on the following:
The site is bookmarked (and the user has 5 or less bookmarks)
The site has high site engagement
The site has been added to home screen
The site has push notifications enabled
If any of the above are true, the permission is already granted, and if not it's automatically rejected. This means that in Chrome, there's no difference between navigator.storage.persist() and navigator.storage.persisted(), even though the first is supposed to be a permissions request and the second is supposed to be a permissions check.
I've already built in-app UI for requesting persistent storage permissions, so all I need is a sure-fire way to get the permissions popout to show in Chrome so the user can grant or deny that permission. Since I can't control the first three conditions, or reasonably ask the user to satisfy them, it seems like my only option is to ask for permission to show push notifications, which is unfortunate because that is not the permission I need and I have no interest in showing push notifications. A permissions request like that would likely confuse users.
Is there a more clear, user-friendly way to get permission to use persistent storage in Chrome?
If any of the above are true, the permission is already granted, and if not it's automatically rejected.
This is incorrect; the permission must still be requested. Until it is requested/granted the origin will still be treated as "best effort". The site must explicitly request the permission. You can observe this by calling persisted() prior to calling persist() on a site that has never requested the permission.
all I need is a sure-fire way to get the permissions popout to show in Chrome so the user can grant or deny that permission
Chrome does not have a permission popup for this permission, so there is no such way.
The preferred model is to not offer guarantees about offline capability until the permission is granted; that is, request the permission and only show any sort of "your data is absolutely definitely available offline" assurance once it has been granted.
As mentioned by Joshua Chrome does not have a permission popup for this permission.
What I did was manually enabled the push notification in the site settings for my website.
This was enough for Chrome to grant my website persistence storage permission.
Related
I'm writing a Playwright test that starts with a Google Auth0 login. After I fill my test user and password in the UI (google login), in Firefox and Webkit the authentication passes successfully, while, on Chromium, I'm getting the Verify it's you message (with a "send sms" message).
The account does not have 2 steps authentication.
When it happened locally, I opened the browser in headful mode, and after few clicks (which I assume "told" the browser that I'm a real user) the problem disappeared (I can now run my tests in headless mode locally). But, it still happens on CI (GitHub)
I run the test with chromium flags: --disable-dev-shm-usage and --disable-web-security.
I couldn't find any data about it anywhere...
When Google determines that a user is logging in from an unknown device or a new location, they may prompt the user with an additional login challenge.
The login challenge that the user receives depends on the information that associated with the account.
Does the prompt say "Enter a phone number to get a text message" or something else like "This device isn't recognized..."
If the former I believe you can circumvent this extra prompt by having a phone number linked to the Google account in question. If the latter I believe the prompt is once per user per device.
My understanding it is basically Google trying to get a valid phone number for the account (to prevent spam etc).
-- Edit
The only other thing I can think of is that you can temporarily turn off the verify-it's-you challenge, for 10 mins, but only if the account is a member of a Google Workspace or Cloud Identity service. I am not sure this is possible for an unmanaged account - or how useful it would be. The other issue is that for "free services" Google doesn't really offer any kind of support.
Anyhow, you might try "Temporarily turn off login challenges for a user" -
https://support.google.com/a/answer/12077697
There is also so good information on this verify-it's-you challenge here.
https://workspaceupdates.googleblog.com/2018/04/more-secure-sign-in-chrome.html
It has some notes on disabling the challenge per organization via response headers, but again this is for an organization and managed accounts.
If you wish to disable the new screen for your organization, you can
use the X-GoogApps-AllowedDomains HTTP header to identify specific
domains whose users can access Google services. Users in those domains
won’t see this additional screen, as we assume those accounts are
trusted by your users. This header can be set in Chrome via the
AllowedDomainsForApps group policy.
Do people typically store permissions in a JWT? I've seen example that might have admin: true or scopes: ['add_foo', 'delete_foo', 'read_foo']. And this seems fine, other that the potentially large size that the JWT could become if there are a lot of permissions/scopes. It seems like it would be really useful as you wouldn't need to hit a DB or cache to get the users permissions as long as the JWT can be verified.
My main question though is how these would be invalidated in the event of a permissions change.
For example, sys admin Joe, revokes the 'add_foo' and 'delete_foo' permissions from user Bob, but keeps the 'read_foo' permission. In this scenario user Bob should not have his token entirely invalidated and need to log back in, he should basically be forced to get a new JWT with the new permissions and carry on as normal.
I've seen examples explaining issuing a new JWT in the event of a password change, but the difference here is that sys admin Joe does the update to user Bob. Thus, there is no opportunity in this workflow for user Bob to get the new token immediately.
Most examples suggest for invalidation maintaining a black list of revoked tokens, or changing a DB record ID so the token is no longer valid, or having a per-user secret and changing that.
I see that all of these would work for the revoking of the token and test that its invalid, but how does the user then get a new token? their current JWT is now invalid? Trying to do anything with it should fail.
I've seen mention of a "refresh token". Are these widely use? Are they secure on the web or mainly used for mobile apps where the refresh token is harder to obtain. It seems like it would be reasonably easy to steal a refresh token via browser dev tools or similar and then someone would have access forever to that account until the unauthorized access was noticed and the refresh token revoked.
Maybe in this scenario forcing user Bob to re-authenticate is not such a big deal? Permissions probably don't change too often.
Thanks, Mike.
You can set expiration date (for Web app we are usually using 15 min - 30 min, for mobile 1 week). When you set Issued at claims parameter ("iat"). Then every time when you validate token you should check the token's "age". If it older than 5 min you load data from DB and create new token with current "iat" value.
When permissions change you should invalidate the issued tokens for this user. There are different techniques to use. See Invalidating client side JWT session
But consider that revoking tokens is not a recommended practice because you lose one of the main advantages of JWT: It does not require server storage.
The objective of Refresh tokens, as defined in Oauth2.0, is allow applications to obtain a new access token without re-authenticate
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires,
If the permissions do not change frequently it may be easier to re-authenticate user, and if they change much consider whether they really should be included in the token
If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).
I'm writing a Box App for enterprise use. The scenario is the application scans the user account, and changes the permission of certain file (which we believe it's sensitive) to 'disallow download'. Good thing is it can be done, however, when user logins, he/she can easily change the permission back to 'allow download' from webpage. Is there any way to prevent user changing the permission back? Any idea?
Lock unlock functionality is coming soon in the V2 API. Stay tuned for a blog post in the next week or so.
When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.