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.
Related
I wrote two small Google Scripts that present simple forms to fill in. Most of my user community has no trouble using them. A small minority of users can never open the forms, instead they get "Sorry, unable to open the file at this time" error page for both forms. I can't find any common thread for why only some users fail. I've tested on multiple browsers on multiple machines, even on android devices, it never fails for me.
A couple of things I've noted:
when it fails for them the URL is re-written. The proper url starts with https://script.google.com/macros/s/... but for broken users when they paste that in they instead get https://script.google.com/macros/u/3/s/... (notice the "u/3" at the end)
There is no execution log created when they try to access the site, so I have no way to debug what's going on.
The app is permissioned so "Anyone" can access it, and it runs as my account
Sorry, I realize this problem description is impossibly vague. Any debug suggestions would be extremely welcome. I'm not a regular Google App Script developer, so I'm kinda stumbling in the dark with this one. Thanks in advance.
/u/3 means that the user have signed-in into multiple Google accounts, the number correspond to the zero-based index of the account in the order that the user followed to sign-in, 0 is for the default account, 1 is to de second account, 2 is for the thirds account and so on.
So, on your test include this use case, a user signed-in into multiple Google accounts.
NOTE: It's known that the HTML Service do not handle as expected this use case.
Related
AuthMode gets confused w/ multiple logged in users
We're sorry, a server error occurred while reading from storage. Error code PERMISSION_DENIED
Why is my script pushing an incorrect URL? [/u/2 inserted into script URL] (possible duplicate)
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
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.
What is the ejabbered behavior for user who is un-expectedly disconnected from internet
vs
user who explicitly sent an 'unavailable' presence?
Would they both be considered offline (for both single user chat or MUC)?
I want a behavior where if a user is disconnected from internet, offline messages to be sent
If user sent a explicit unavailble presence, I dont want offline messages to be sent.
How can that be accomplished? I can write my hook. But I need to know in which situations, the hook will be called.
When the user gets offline, the default behaviour is the same, no matter which method is used (explicit session close or unvoluntary disconnect). This is per XMPP specification.
If you want to customise the behaviour, it will not be easy as there is no way to know the reason why a user if offline.
What I would do: I would use the last module and support an optional reason for disconnect and store it. When you disconnect unvoluntarily, I would modify code to store reason being something like "timeout". When you disconnect explicitely, I would store another flag. When you get an offline message, you can then check the reason from being offline coming from mod_last storage.
I would like to know what is the clean & correct way to notify my WP8 app that the ChannelUri has changed?
I read that i need to handle this in the ChannelUpdatedUri method. But i have a few queries here. Doesn't this require my app to be running all the time?
Second query is suppose i use ChannelUpdatedUri to listen for changes to the Uri. If there is a change will the app be notified as soon as it launches? Or will it be notified at a later time?
The trouble is if the app is not notified on launch then there is a possibility that it may re-register for a new channel uri before ChannelUpdatedUri is invoked. Isnt it?
Please help!
You'll only get notified of a change in the ChannelUri when you have the listener attached and the app running.
The best approach is to always check for the current Uri and pass it to the server when the app starts. You could leave the listener attached for the lifetime of your app and get a new one if it's lost while the app is running but in reality it's far more likely that the channel will be dropped/disconnected when the phone isn't in use.
There is, of course, the scenario where a channelUri may expire when the app isn't in use but the utility of the app is primarily around sending notifications. Obviously you need the user to restart the app to get a new connection but you can't tell them to restart the app.
This is a generic problem: how do you tell someone that you can't talk to them?
The reality of this situation is that if you really need to tell someone to launch the app again you'll need another way to do it.
Unfortunately, it's not possible to get an updated channelUri from a background agent, but you could query your backend to see if you need one and then raise a toast to the user to prompt them to reopen the app. Or you could just update the tile from the agent when this happens.
Alternatively you'll need to send them the prompt in another way (e.g. email or SMS?) but this is reliant on you capturing and securely storing these details.
There is no perfect solution to this scenario other than creating an app that the user opens regularly regardless of whether there are notifications or not and simply having the notifications as an extra feature.