I'm trying to get my head round Facebook's recent deprecation of offline_access with access tokens. I'm using a JS plugin called neosmart FB Wall, which uses an AJAX call, with the access token appended, to request wall data. As I understand it and from just testing this morning, now if the Facebook user logs out, a new access token will be required and the previous one will be invalidated.
So basically I think I have to extend the plugin so that it checks the response from Facebook and if necessary, sends login credentials to request a new access token. The slightly confusing thing for me is that I have 5 sites which have been using the same plugin for over a year, and none of them have had any issues yet with the access token expiring, even though the Facebook accounts have been logged in and out of several times! Can anyone shed any light on what might be happening here? Thanks in advance for any help.
Since offline_access is deprecated you can create a long-life Facebook Access token. The developers of fb.wall released a new plugin: neosmart STREAM - the offical successor of fb.wall - This plugin contains a Facebook Access Token Creator which creates long-life access tokens. Project website: https://neosmart-stream.de
Related
I want to fetch the data(Pageview, Session, Users and all) from Google analytics and show it on another website but my problem is that I don't know how to get access token using JavaScript.
I referred some Google docs for getting access token Query Explorer, OAuth 2.0 Playground but this access token is expired in 60 minute and I want to save this access token for future use(long live access token). Anyone know about how to get access token using js or how to get refresh token for using future use.
Whenever I used expired access token and fire the API so I got this error:
{"error":{"errors":[{"domain":"global","reason":"authError","message":"Invalid Credentials","locationType":"header","location":"Authorization"}],"code":401,"message":"Invalid Credentials"}}
And my Google analytics API which is generated by Query Explorer included access_token.
https://www.googleapis.com/analytics/v3/data/ga?ids=ga%3A123456&start-date=2016-10-21&end-date=2016-11-20&metrics=ga%3Asessions%2Cga%3Apageviews&dimensions=ga%3AlandingPagePath&start-index=3&max-results=1&access_token=za29.aaaaaaaaabbbbbbbbbccccccccdddddddmmvermrm
Access tokens are only good for 60 minutes.
What you are looking for is a Refresh Token. Refresh tokens are used are good as long as they are valid. They can be used to request a new access token from the server at anytime.
Answer: It is not possible to extend the time that an access token is good for. It is not possible to get a refresh token with JavaScript. This is probably for security reasons.
Option: Switch to a server sided programing language if you want to get a refresh token. If this is your own personal account and you wont be accessing user data I would recommend you looking into service accounts instead. You will need to use a server sided language for service accounts as well.
We're are developing a javascript facebook app which searches for users by using the graph api.
Currently we were informed by facebook that our app is using a graph search endpoint without an access token. Since we are doing all FB api calls from the js-sdk we thought a valid access token is always provided. I crosschecked this and e.g. the following request is made by the sdk:
https://graph.facebook.com/search?type=user&limit=10&offset=450&q=max&method=get&access_token=<TOKEN>&pretty=0&sdk=joey&callback=FB.__globalCallbacks.f3d041460c As you can see the call provides a valid access_token.
Our app is requesting the following scope from the user when he wants to use our app:
email read_friendlists read_stream user_events user_groups user_photos user_status
Checking this token with the graph api explorer's debug method does not show any errors: The token is valid, expires in one hour and it's assigned to me (a user).
What are we doing wrong? I haven't found a special scope for searching for users. Thank you.
On the roadmap Facebook states that they will make changes to the way we get accesstokens. Will this affect the way we login with Javascript SDK?
New security restrictions for OAuth authorization codes
We will only
allow authorization codes to be exchanged for access tokens once and
will require that they be exchanged for an access token within 10
minutes of their creation. This is in line with the OAuth 2.0 Spec
which from the start has stated that "authorization codes MUST be
short lived and single use". For more information, check out our
Authentication documentation.
Link: http://developers.facebook.com/roadmap/
On the roadmap Facebook states that they will make changes to the way we get accesstokens. Will this affect the way we login with Javascript SDK?
Of course it does not:
“We will only allow authorization codes to be exchanged for access tokens once, […]”
Did you ever have to exchange an authorization code for a token yourself when using the JS SDK to log in?
No, since FB.login returns an access token directly.
So I'm developing my own API for my website - I'm mimicking the Facebook JS SDK in regards to how my system works. API client displays a button, popup comes up and the user can log in. Login popup issues an event to the opener window and the parent window now knows the user is logged in. That all works.
What I'm having trouble understanding is how they can verify that the refresh requests are valid. If the API client needs to send a request to the server to ask if the user is logged in and it's all in JS, then everything is transparent. The API client says, "Hi, I'm application 4jhkk2l3bnm389, is the user that's logged in on Facebook also authenticated with me? If so, can you send me a new token so I can make API calls?" and Facebook says, "Oh, you're application 4jhkk2l3bnm389? Yeah, the user is logged in and has allowed you to access their information, here's an access token."
But how does Facebook prevent an outside application that isn't the authentic application from saying, "Hey, I'M actually application 4jhkk2l3bnm389, I promise I'm not lying. Can I have an access token?"
I have no idea how they determine the difference. Obviously if it was all done through AJAX calls in modern browsers then you could just provide an Access-Control-Allow-Origin header. But if a malicious client were to use cURL then I don't think I could ever tell the difference. How does Facebook do it? A good explanation is much appreciated! Thanks!
All access tokens belongs to an app/user pair, and in order for Facebook to return such an access token to the app, these has to be verified.
The app, or client_id, is verified against the domain specified in the redirect_uri - if the page tries to use a client_id/redirect_uri pair it does not own, then it will not receive the access token as this will be passed to the valid redirect_uri (the mechanism the JS SDK uses follows the same rule).
The user, or uid, is verified using the cookie Facebook sets when you sign in.
While you can easily spoof the client_id/redirect_uri pair using curl, the same does not apply to the uid, as you would have to be in the possession of the users cookie. And if this is the case, well, then you could simply grant your own application access.
Facebook uses OAuth 2.0 for authentication. You can find details of how Facebook deals with OAuth right here: https://developers.facebook.com/docs/authentication/. There are many different ways OAuth can be used, depending on whether you're on a mobile device, a page on facebook.com itself, or, in your case, just a web page outside of facebook.com. The details of that final flow can be found here: https://developers.facebook.com/docs/authentication/client-side/.
Basically, Facebook knows what applications you have given permission to view your information. When you run one of those applications, they first make sure you are logged in to Facebook, then they request a user access token from Facebook, essentially saying, "Hey Facebook, I don't know this person, nor should I. Can I get access to their information?". And then Facebook looks internally and if it decides this particular application should have access to this user's information, it sends a user token.
That's the simple way of describing it. There are many different ways the authentication flow can happen, depending as I said earlier on what kind of device the request is happening from, whether this is a page on facebook.com, etc., essentially based on your security constraints. Best to read the Facebook authentication docs referred to earlier for the details since it can get quite tricky.
I've written a bit of JavaScript that will fetch all of the posts on a Facebook Page. The URL with which I do that is this:
http://graph.facebook.com/cocacola/feed?limit=5&callback=facebookResponse
and this worked fine and dandy, right up until last week sometime, when I started seeing oauth errors.
I've searched for an hour or so on Stack, and seen plenty of other people are trying to do this, - but none have been asked after all of my requests to FB started returning these oauth errors.
It really doesn't make sense, - I'm trying to access publicly available data from company pages. I can still do so without oauth (albeit in a limited fashion) via RSS.
Anyhow, I'm hoping someone can clue me in as to how to get this PUBLICLY AVAILABLE information without having to go through the rigmarole of getting an application ID, an authorization token, etc.
This is a recent not-so-recent change, but you now need an access token to access /feed and /posts. Annoying, but at least it's navigable.
Edit: updated the link, which has broken in the many years since this post was relevant. Here's the relevant text from that post for future posterity:
Breaking change: Graph API PROFILE_ID/feed and PROFILE_ID/posts requires access_token
The Graph API PROFILE_ID/feed/ for a Page, Application, User or Group and PROFILE_ID/posts for a Page or User will now require a vaild [sic] access_token to access the wall or posts of the corresponding object (where previously no access_token was required). This will also affect direct FQL queries to the stream table, when querying for posts on a wall.
You will need to pass a valid app or user access_token to access this functionality. Please update your code if you are calling this API without an access token. This change will go live a week from today - Friday(June 3rd). We have updated the Roadmap to reflect this change.
Moving forward, you should always pass a valid app or user access_token with all API requests.