I'm extending client-side access tokens as documented here: https://developers.facebook.com/roadmap/offline-access-removal/#extend_token
But I've noticed that very frequently the request returns the short lived access token instead of extending it. Across all of our users, this appears to be the case ~70% of the time after enabling the migration.
Is there something that we can do to fix it? Why might this be failing so frequently?
Thanks!
Related
I'm developing an web API and I'm trying to follow the principles of REST. I'm now at the stage of creating the endpoint where a user can delete its own account. I have also implemented JWT functionality where the JWT is valid for 1 day.
I want to add an extra layer of security when the user is deleting its own account. My idea is that the user have to provide its current password in the body of the delete request. I did some googling which pointed to having a body in a delete request is a bad idea because some entities does not support it, e.g. the Angular HttpClient, some web services might strip the body, etc.
I know GitHub have a similar functionality when deleting a repository, you have to provide your password. I like this feature because it prevents unauthorized persons from spoofing the JWT on critical operations, right?
What are your recommendations
Proceed with using DELETE and deal with the potential problems that might come along with this approach?
Instead use POST, PUT or PATCH even though it would look semantically wrong?
Other solution?
I would not recommend to use other http methods like put or patch if you really want to delete it and not only disable it. That would not be intuitive for the API user and could lead to misunderstandings.
One solution for your use case is to introduce an additional resource (e. g. deletionRequest) to request (but not immediately execute) the deletion of the profile with a post call. Then you could do the actual deletion with a delay (preferably longer than the token life span). You could then inform the user via email about the deletion, so the real user has the chance to revoke the deletion. If the user does not react in time, the deletion is executed.
This is basically the same question as How to get an access token without Box’s authorization page. I see that the Python package mentioned at the end (box.py) is no longer maintained because of support issues with Box. I suspect the solutions given might no longer work.
I'm just getting started with boxsdk and I want a way to periodically list the contents of my folder without requiring user interaction. This looks like the answer but it also seems very odd that a Developer Token, which is temporary, could be used for long-term queries like this.
I'm trying to work through boxsdk to see how I can implement the solution provided in 2014 but it would sure help to know whether or not it's still possible.
I just stumbled across this:
Introducing Developer Tokens
"There is no refresh token paired with the token"
That's from February 18, 2014.
We are using Doorkeeper to handle authentication with a Ruby On Rails API. When I was looking through a database on the server, I noticed that there are a lot of records in the oauth_tokens table, a good number have expired already! To be fair, our tokens expire every 2 hours...but that still will add up for a lot of users over time.
I have looked through the documentation, and the code and am still lost
Is there a way for doorkeeper to automatically delete old, expired access tokens? (I'd prefer a set and forget sort of solution.)
I am trying to find a way to automatically validate multiple facebook access tokens at once.
I am storing user access tokens into sql database and (as expected) after some time some of the tokens will expire or becomes invalid. (due to user change password/de-authorized app, log out, etc.)
Is there any way to check/validate all access tokens from a .txt file/database and delete those tokens that are invalid: doing this manually for more than 100 tokens is very difficult.
Options
checking access tokens from a .txt file (using PHP) and remove invalid tokens simultaneously so that at the end we will have a list with only valid tokens.
directly remove invalid tokens from the database.
Any insight?
This has become a very common problem now a days not only me but most of us are still googling like i did before posting it here but no one has ever found a way to solve this problem and i believe is this is the only forum where this thing can be fixed.
No, there is no endpoint where you could check multiple tokens at once. The most similar method to achieve the functionality you want is to batch the requests. You should be good to batch them in sets of 25.
So, your flow would be this: Get 25 tokens from the SQL database. Call /me endpoint with each token. IE, your batch call with look like
batch=[{"method":"GET","relative_url":"me?fields=id&access_token=TOKEN1"},{"method":"GET","relative_url":"me?fields=id&access_token=TOKEN2"},...,{"method":"GET","relative_url":"me?fields=id&access_token=TOKEN25"}]
Loop through the response, if its checks out, you're good. If an error is thrown, its not. Deal with each access_token accordingly. The responses will be in the same order as you gave Facebook.
I am using Facebook long time tokens(2 months), but FB starts to be nondeterminic and gives me sometimes this return
{
"error": {
"message": "Cannot access application using the specified access_token",
"type": "OAuthException",
"code": 1
}
}
I am using PHP SDK.
I am using this link to get 2 months token
https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRETgrant_type=fb_exchange_token&fb_exchange_token=SHORT_TIME_TOKEN
Any ideas?
I was experiencing this issue, and got some support direct from FB staff. The most likely cause of this error is "demographic checks" for the user.
Our app had an age-gate as it was alcohol related. Certain users' profiles did not contain enough information for FB to ensure they were above the drinking age for their location, so the session creation failed. Why this only happened on this call and not on earlier ones, I don't know.
Does your app have an age-gate, or anything similar?
You have the missing & between APP_SECRET and grant_type.
Also, there seem to be a Fb bug on this issue - http://developers.facebook.com/bugs/536272816386515?browse=search_50a37bb1c333b4253892226
Be sure that you extend the tokens immediately after you get the "SHORT_TIME_TOKEN". You can extend user tokens only ( not page tokens ). Be sure that you get a correct "Short time token" before you extend it.
Also, check for "sandbox mode " in your app. It may cause problems when extending tokens. Try switching it to "false".
Hope that helps.
Your query is missing an & after APP_SECRET, before grant_type. It should read:
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=SHORT_LIVED_ACCESS_TOKEN
Source: Extending Access Tokens on Facebook Developers.
Edit: If the OP means that out of the current app user base, some users experienced expired sessions and reported the issue, the wrong query string is a possible explanation.
The error would result in the access_token not being extended, but log-in will be still be granted with the shorter-lived access token. In this case the faulty query string was in the code base all along, but was only discovered when live users' access_tokens expired earlier than expected, coinciding with "the app [..] used by many people".
If the OP means that using the correct query (and not the one stated in the question) out of many calls from the same client a subset returns with error, then my explanation isn't valid.
It sounds as if some of your users are erroneously being issued tokens that have a short lifespan instead of the extended ones you ask for.
It is possible you have stumbled upon a known bug with the extended access tokens. Check this bug report on facebook for more information about it as well as this question, although to my knowledge there's no real workaround.