I've been scouring the net for ages with this one, and I'm not sure if there is a solution at all, but thought I'd post and see if there's a response... thanks in advance!
Several of our customers (who we build websites for) have their Facebook feeds brought into their website (and their Twitter feeds). Before the removal of the offline_access permission, this was no problem. We'd set our app up, authenticate the account, get the access token and then we could bring in the live feed into their websites forever. However, now with the new system, there doesn't seem to be a way of doing this without human intervention.
Essentially, we have these websites bringing in the feeds from the relevant Facebook accounts, with the long access_token (60 day token). However, when this limit is reached, there is no "user" to re-authenticate the app, as its just the server that makes these requests. Is it a case of having to set reminders for all these accounts, and then every two months we (as the web agency) have to log in to all the accounts and get new access tokens to provide to the scripts so they can carry on working? Or is there an alternative which I am just not seeing?
Thanks again!
Neil.
There is no alternative that I know of. Once the token expires after 60 days, the user must re-authenticate.
No alternative way, user must login to provide you the new access token
https://developers.facebook.com/roadmap/offline-access-removal/
Related
I'm struggling with a the new OAuth verification process that Google has introduced. Earlier, my OAuth app was using sensitive scopes, and I made changes to ensure that the sensitive scopes are no longer required, and removed them from the OAuth consent screen configuration.
However, my OAuth consent screen is still being forced to go through the verification process (which is a black box and never seems to complete!)
I noticed the following user-cap being breached. Could the forced verification be because of this? How do I check which users are connected to my app, and also manually disconnect them? I have never bothered about this user-cap in the past, so it is quite possible that a number of these are internal/test users when the app was under active development and was being tested in production. Btw, if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap?
Possibly related to How can I confirm the user limit of my google cloud/API? -- but that doesn't answer this question in detail.
I noticed the following user-cap being breached. Could the forced verification be because of this?
probably but only google can really anwser that
How do I check which users are connected to my app, and also manually disconnect them?
You cant there is no way for you to know what users where connected to your app and disconnect them unless you have saved a refresh token for these users if you have then you could remove them using the revoke command.
However this is no guarantee that the number google is displaying is going to change as it could be just a running total of users who have consented to your application in the past and not the ones who have currently consented. There is no way of know ing this as google hasnt told use.
if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap
This may be true but that doesn't mean that the user has revoked your access to their application though their account. The only way to remove access is for the user to remove it in their account or for you to use the revoke endpoint to revoke them by force. Your application not having a refresh token doesn't mean that the user hasn't granted your application access.
Long story short your going to have to go though the verification process and wait for google to remove it when they see that you are no longer using the scopes that would require it.
Update: I have pinged someone on the team to see if this is working as intended or if it could be a bug. I will update this when i know more.
We have an app which could login via Facebook or Instagram. And we will pull some basic information of the user's from the site if you do so. We want to update all those basic informations at a certain period of time by the backend. It's not necessary for us to update informations while the user is using the app. I think update the basic information is just a test. The company might want to give some useful recommendations to the client for some commercial reasons. Any way, I checked that Facebook access token will live for 60 days,Instagram access token will not expire for now. May I refresh access token at backend without user involved?
There is no way to refresh the User Token automatically (on the server), it needs user interaction. Else, it would be pointless to implement a 60 days limit.
I am building an in-house application which would accumulate the information from several social networks at once. Possibly, the URL of the application will not be known or it will not be allowed anywhere outside localhost.
One of the information pieces I will be accumulating is FQL insights table information: https://developers.facebook.com/docs/reference/fql/insights/ . As you may notice, this information is private, so I just cannot fetch it anonymously.
The application itself is written in a "configure once and use forever" fashion, and possibly the person using the application will not be allowed to the Facebook login credentials at all.
My problem is the Facebook login. As I understand the login with "forever access" is now deprecated and Facebook does not allow API access the same way as Twitter does (creating the forever lasting key and forgetting about it). Question is:
Is there any way to overcome the fact that I need to ask the person for permissions every time I would like to fetch them? What can be the longest period between asking?
My current thoughts about it are:
Creating a dummy user for the 'manager' and giving him read-only
access to FB pages, therefore enabling him to log in to the account.
Then asking him for the permissions every (n) hours when I need them.
Automatic log in to the FB account given that we have the
login/password for the account and obtaining the API key myself.
Which is doable? Did anyone have any experience in doing this kind of things?
What can be the longest period between asking?
You can use Long-lived user access_token which is valid for 60 days.Use below FB call to get extended access token:
https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN
You can check more details here:
https://developers.facebook.com/roadmap/offline-access-removal/
One more point which is worth to note here:
When a user change his password, deauthorizes an app their OAuth token get expired.
Hope this help !
I've been digging through all docs I can find, but I cannot seem to verify this..
When I'm doing app authorization I'm asking for publish_stream from my visitor.
From to FB docs (http://developers.facebook.com/docs/reference/api/permissions/):
Enables your app to post content, comments, and likes to a user's stream and to the streams of the user's friends. With this permission, you can publish content to a user's feed at any time, without requiring offline_access. However, please note that Facebook recommends a user- initiated sharing model.
It very explicitly states that I'm able to post at ANY time. But, a regular user access token expires after a certain time. So that won't be usable to post.
However, an APPLICATION access token can be retrieved at any time, without any user interaction. And when I've tested, I can successfully publish to a users feed (yes on their feed, not my applications feed) using the app access token.
I haven't waited 2+ hours for the initially obtained User token to expire though, but even if the user session was logged out, I was still able to post using the app token.
So, this is what I want, right? Yes!
But this is not documented anywhere, so my question is:
Is this an allowed/recommended approach? Will I run into any problems around this?
Thank you
this is the right way to do it, so you'll not run into any problems etc.
Just use the App access_token to publish on you app users walls.
Greetings,
Fredyy
I have a question as to how / what the best approaches are to using OpenId and also providing the ability to stay logged in.
If i look at Stackoverflow for example i have logged in using Google and if i close by browser and come back it still has me as logged in.
However, i am not logged into Google and moreoever I have removed stackoverflow from the list of authorised services which have access to your Google account. I would naively expect that stackoverflow would prompt me to login again but it doesn't.
So my question is, what are the best practices regarding OpenId and remembering authenticated users across sessions?
OpenID is still pretty new and several relying parties are trying out new and different ways to implement OpenID. There is a work in progress best practices document for relying parties hosted by the OpenID foundation. In particular, they address the question of cookies and session lengths in their last section. Definitely an interesting idea to use persistent claimed_id cookies rather than persistent session cookies in order to make the user's life easier -- they only have to log out of their OP and close the browser.
Personally I find the behavior you're describing on StackOverflow pretty natural. If OpenID were out of the picture and you were logged into a username/password web site on two different computers with a persistent cookie (a very common scenario), and you changed your password on one, I wouldn't be surprised if the other computer still had me logged in. You could call that a security hole, but it's still normal practice. So normal in fact that Gmail recently added a display at the bottom of your Inbox screen that tells you where else you're logged in and gives you the opportunity to invalidate their session cookie.
I would suggest that a similar approach could be taken by any RP, regardless of the authentication method. And that would probably mitigate the security concern you have.
Stack overflow probably uses a cookie to remember you as user number xyz or session id 1234. After authentication, OpenID has nothing at all to do with the session anymore. SO doesn't have the ability to see if you are still logged in to Google so this seems only natural.