We have deployed the chrome service worker on our website in July 2015 and have over 380K active subscribers of which over 90% are mobile devices.
But we are encountering issues with the service worker. When a user's cache gets cleared or when many of the mobile apps like cleanmaster and other utility apps on a phone clear cache on a user's mobile. In that case we do not have any access to device token of that user. And hence even with 380K active users for which google sends us message ids we only get 50K impressions which is a very low ratio.
Our push notification subscription is implemented on a seperate subdomain as we could not make the entire site https then.
I have 2 queries:
We would love to know if Google is working on setting up a canonical system (Which is there in GCM for mobile apps) through which even if the user's cache gets cleared via these apps he might be able to get push notifications. Our users have complained again and again that even after subscription they are not receiving push that's when we went deeper and figured this out.
Also is there a way through which we can ensure we get back those users ?
When a user clears their cache in Chrome, it also unregisters service workers and clears the window cache as well. By unregistering the service workers it will unsubscribe the push subscriptions.
I agree that it's hard to understand the link between clearing a cache / cookies and how that relates to service worker and push notifications from the UI - the Chrome team are aware of this.
The best advice with respect to getting those users back is to ensure that when ever a user enables notifications and you get a subscription object, keep track of that decision as their last known decision and when the user re-visits your site, if they should be subscribed and you have permission, you can get a new subscription and send that back to your server.
Update
I put together this blog post: https://gauntface.com/blog/2016/05/01/push-debugging-analytics
Looking at your site there are a few issues in your code:
it seems that you have several broken promise chains and and overall it's hard to reason with what is going on in the push event, I'd strongly recommend tidying it up.
There is a minor but obvious bug when the service worker start ups and tries to examine the push subscription, which doesn't exist.
You are registering two service workers but only one of them gets used for push.
Checkout the blog post above, it covers how I came to that conclusion and some advice on how to fix it.
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.
I'm creating a web app for my company that will keep a number of files in sync with the files on Box. This will be done by using a cron job running every hour.
I have the application working by setting the developer token in my account, this was done for testing whilst I was building the application.
Now this is working I want to get the authentication working so I can just leaving this running. So I'm trying to work out if there is a way I can have an API key for our enterprise account or if I will have to implement OAuth and connect one user to the application, which seems to be a bit overkill?
You should probably use one of the SDKs, which take care of refreshing the tokens for you.
Essentially what you'll need is a keystore to store the tokens. You could store the Refresh-token only. When your cron wakes up, use the refresh token to get a new access-token and refresh-token. Store the new refresh token in your keystore. Then make your API calls using the Access-token, and then go back to sleep.
According to MSDN, MPNS will put the notification requests in queue for delivery, so there is always time delay for them to get to device. My problem is that, sometimes, for example when the device goes to Temp Disconnected mode, the time delay is so long that the toast notifications become outdated when they arrive. Is there a way to discard/ignore these old toast notifications without renew the current push channel? If not, is it all right for me to renew push channel every time I open app?
As far as I know, it's OK to renew the channel every time you open the app. If your app is not running and you don't have a background task getting these notifications, you will automatically be discarding them anyway. Also, if my memory serves me correctly, should you use the channel request with an object that has been previously used to receive stuff from the channel, you can get the same channel (I might be wrong here). In this case, if you get old messages, you probably have to handle the local discarding manually.
I'm in the middle of developing an application that integrates Box with an identity management environment for the purposes of SSO and user lifecycle management. Basically, our users use SAML to sign into their Box accounts, and then the status of their Box accounts is managed based on the status of their corporate accounts - if we terminate a user, the user's Box account needs to get disabled. This is one of many use cases that were in progress before the OAuth2 change.
Prior to the OAuth2 change, I was able to authenticate my enterprise admin account with the api_key and auth_token. This worked very well.
Now, with OAuth2, I'm not sure how to proceed. There is no UI for this at all, and I have no place to handle a redirect for the authorization token. Moreover, this is a nightly process that runs using the enterprise admin account, so I would have to get a new refresh token and bearer token every time this runs.
This doesn't make a lot of sense for my use case. Is there an alternative?
I am busy writing the same code with the same frustration as you have. However the refresh token does live for 14 days and what I plan to do is store the returned values encrypted in the registry. Each run my first action is to refresh the bearer key.
There however is no current timeline on the phasing out of the V1 Auth method and since some of the Enterprise stuff is yet to be ported to API V2 I suspect that if enough Enterprises push the BOX API team for a solution on this I am sure they will listen.
If I am honest I prefer the OAuth2 solution as it stops the key to your whole Enterprise data been sent in clear text across the internet as a URL param in API V1 and if someone did manage to break the SSL then only get a access token that is worth 60 mins max.
Not sure what language your writing the routines in but I am working with the API V2 SDK written by John Hoerr on GitHub and apart from a few little issues that he has fixed straight away from a .Net perspective it makes hitting the API a much more pleasant experience with all the de\serialisation handled by the SDK.
We currently have an implementation that uses boxes API. Our authentication process follows the process outlined here:
http://developers.box.com/get-started/#authenticating
Sometime in the recent past this has stopped working. When we go to the oauth URL (for example, https://www.box.net/api/1.0/auth/rev37d850p6pixlemm5ok8doxj2g77kg), it will initially show the login credentials page, but faster than a user could reasonably enter their credentials the page starts returning "expired ticket". If I immediately go to the token's page after creating it I can reload the page a few times before it goes into the "expired ticket" state. This is clearly not consistent with the expected 10 minute expiry time stated in the documentation.
We've had this authentication working correctly up to now, so it seems like something has changed.
We are investigating. More news once we have some additional information.
New info>> We've identified the bug, and will be pushing a fix this afternoon.
The fix has been rolled out. Please let us know if you are still experiencing any problems with SSO.
Our Android app has the same problem. As far as I investigated it, using get_auth_token API causes the ticket to expire. So you have to make sure the user has successfully logged in BEFORE attempting to get the authentication token (which is not the case with Box SDK for Android). But I don't see a viable way to check whether the user has logged in.