I have a Web Service subscription for Push, by calling the the subscribe() method. I then save this endpoint on my server, and push using this, great... this all works fine.
Then the user goes home for the weekend, and 24 hours passes, the old endpoint is now expired. Even if the user now starts his computer, he may or may not visit my site, meaning there isn't a chance to refresh the subscription.
What is the reliable way to handle this? or is there a way to ask for a longer subscription?
I see pushsubscriptionchange is only supported on Firefox - https://caniuse.com/mdn-api_serviceworkerglobalscope_pushsubscriptionchange_event
Related
Last year I was building an application to create my own YT dashboard.
It was based only the code of a tutorial
They basically authenticate a user via OAuth and send requests to get channel data or playlists of the authenticated user.
I was trying out both the original tutorial app and my own (after a few dormant months) and they suddenly don't work anymore.
Meaning: I can authenticate on both, but on the original version I get a 403 error telling me: "The request is missing a valid API key." (on requesting channel data)
This is confusing because the API key is never used because only the OAuth client id was necessary.
And on my own fancy version, I get a 403 error telling me that I've exceeded my getting started quota. (on requesting the users playlists)
Looking at my quota page:
I can see, that queries per day (why is it there twice?) is somehow set to 0.
Perhaps creating a new OAuth 2.0 Client ID or a new API key would solve these errors, as was suggested in another post.
But since I'm planning to use the YT Data API in a real project soon and want to prevent this from ever happening I would like to understand what was going on. Why the daily quota limit is suddenly turned to 0 and how to go about it when that happens.
Or at least how to contact google about it.
Perhaps some of you have some insights.
UPDATE:
I've just found this post reporting, that after 90 inactive days, the quota is automatically set to 0.
Now I created a new OAuth Client Id and replaced the constant in my code. Nothing changed so far. Perhaps I have to wait 24h. Or perhaps I have to fill out this form which apparently can lead to months of back and forth email nonsense. I sure hope not.
It seemed the only viable option was to create a new project with new credentials.
(And one should not forget that the YT Data API has to be enabled again for the new project.)
I am a little confused about this migration path, as described in a recent aws blog post, and its aftermath:
It seems like quite a bit of trouble to have to rely on all my users to update in a timely fashion so that GCMSenderIDs can be attached to my existing parse data along with modified/valid device tokens.
Also, what happens to new installations after the migration is complete? In the guide it says no changes need to be made to client side code, but doesn't this require that the SNS sdk is installed so that new installations can be added to the client list?
Considering all this, wouldn't it make a lot more sense to simply forget about the old parse data and just push a client/app update that works solely with SNS and reregister all the devices that way? Why go through all the trouble to integrate with Parse when we are getting rid of it anyways?
AllTheTime,
Your existing Android user push tokens on Parse.com will no longer be valid after January 28, 2017 as Parse owns the API Server Key associated with the Sender ID that was granted the token. If you wish to reach those existing users via Push Notifications after January, you must update the existing Parse.com client app with your own Sender ID and have the app generate a new registration Id (token) associated with your Sender ID. There is no other way for you to convert the existing tokens over to SNS or any another 3rd party.
The SNS SDK is not required for the migration but it would make sense to integrate the SNS SDK when you update the app to retrieve new tokens using your Sender ID. At the time of token registration, the app can update the Parse.com database with the newly issued token AND also create a new Platform Endpoint with SNS.
As for post Parse Push migration and handling the new app installations, my suggestion is to build an after-save “webhook” on the _Installation class on Parse.com. The “webhook” would trigger any http endpoint when a row is created or updated in the _Installation class. The hook could trigger an API Gateway http endpoint that takes the newly generated or updated token and creates a new SNS platform endpoint. At this point, if you haven’t fully migrated from Parse.com, you can either publish to those tokens via Parse.com or SNS. By the time Jan 28, 2017 rolls around, nearly all your existing users would have launched the updated app and generated a new token or they no longer use your app.
Starting over with just SNS is another option but if you need to reach any of the users who have not updated the app then you would need to continue sending push notifications through Parse.com for those legacy users who have not updated the app AND you would then continue to send push notifications via SNS to those new app installs.
I hope this clarifies the migration for you.
Check out my other SO post regarding the Parse.com GCM Sender ID:
How to migrate off Parse to different SENDER_ID
-Dennis
As per FB policies, when a user logs out of my site they are logged out of FB too.
However, my sessions are destroyed after 20mins inactivity, can I somehow destroy the FB session too?
The issue is: another user goes onto the site not knowing that another user is still logged into FB, and my system trying to be a good UI logs them auto back in if it sees a FB user active.
Assuming you're using the JSSDK, there's a method to log the user out. You can call this when you're invalidating your session, assuming you can trigger some client-side code when that happens.
See https://developers.facebook.com/docs/reference/javascript/FB.logout/
I need to migrate my FB app away from using the offline_access permission. As I understand it, server-side OAuth should return a long-lived (60 days) access_token once the user has authenticated.
Once those 60 days are up, I have to request a new token. But, can I do this transparently without requiring the user to revisit Facebook? I understand that the user won't be prompted for the same permissions, but:
a) the redirect_uri parameter must point to a URL where I can process the OAuth request, which makes it difficult for a transparent operation
b) many of my Graph API calls are initiated from AJAX requests hitting my server. If these are rejected due to an expired token, I can't redirect the user away without breaking my application flow.
So my question is, can this be done in a completely transparent manner? I'm assuming the answer is 'No' but bugging the user every 60 days - especially if they've been using the app regularly for 59 days - seems overkill.
It does indeed look like the answer is "No"... Under Scenario 3
Note: The user must access your application before you're able to get
a valid "authorization Code" to be able to make the server-side OAuth
call again. Apps will not be able to setup a background/cron job that
tries to automatically extend the expiration time, because the
"authorization code" is short-lived and will have expired.
We're facing the same problem and it looks like we're going to be forced to bug the user every 60 days. Thankfully this is a relatively minor part of our system and all the AJAX calls are made to our servers which in turn query fb - so we've got a layer of abstraction there where we can hand back cached data/control messages to manage application flow which gives us some wiggle room in terms of failing gracefully until we can get pending data stored and redirect the user appropriately.
Incidentally, it's worth noting that according to the roadmap offline_access will officially become deprecated on 3rd Oct 2012.
Is it posible to notify user that session has expired? Can browser act as server and receive such notifications?
One solution would be to generate JavaScript that does countdown on client side and notifies client in the end, but I am iterested if it is postible to do it the first way?
And what are the consequences of first approach? Are there any security concerns?
What would be posable implementation in django, for example?
You could have the JavaScript periodically poll the server for notifications (every 30 seconds, say), using XMLHTTPRequest to check a URL. If the session times out, the server could put something at that URL that indicates it, and then a notification could be popped up. This is how Stackoverflow implements the notifications that someone else has answered a question already if you're in the middle of composing an answer.
You may wish to look at comet, although I think a javascript timer would be a much better solution being less likely to break, and easier to implement.
I can't think of any security implications as you are only providing an expiration notice, not actually doing any authenticating in that step.
You're looking for some sort of comet-type thing. Probably the easiest "server-push" you can do is polling the server.
In fact in Django, there is not server-side expiration if you use filesystem or database engine => is it your client cookie session id wich expires. Otherwise, if you use cache-based session, you could set the cache expiration to a greater value than the session cookie expiration.
An then, simply declare a cookie without expiration to flag the client browser at login, and check in every page the session id :
if there is no session id cookie but your "cookie flag", the session is expired. There is no need to check the server.