We have a web site that uses the google people API to let people log in through Google. Back when it was originally written, there was no google supplied API, so we wrote our own (using the legacy google+ OAuth2 documentation).
So, now we have a new website that needs to use google login. And... I can't use the legacy people api for new apps. SO, I need to upgrade to the new people API.
The OAuth stuff seems to work just the same (I log in, get a token, and their email and user_id etc without trouble). However, when I try to get a user's name, the syntax seems to have changed.
I used to go to https://www.googleapi.com/auth/userinfo.email/[user_id]?fields=displayName,name&access_token=[access token]
but this no longer works (I get a 403 forbidden).
I've tried changing to the new api, but I'm getting something wrong about the syntax. Here's what I've tried:
https://people.googelapi.com/v1/{resourceName=names}/*?access_token=[access token]
but this returns a 404.
Anyone know what url I need to go to (and the syntax) to get the user's first and last name?
TIA,
Owen
Never fails. Bang my head on the wall for days, then finally ask the question on stackoverflow and within a few hours I've figured it out.
The new call syntax is:
https://people.googleapis.com/v1/people/me?personFields=names&access_token=[access_token]
And a completely new object is returned - so looks like I'm going to have to upgrade all the sites to the new api...
Cheers.
Reference:
Method: people.get
Related
What is the correct way to start using Instagram oEmbed feature? Documentation (https://developers.facebook.com/docs/instagram/oembed/) claims that I have to pass App Review to start using the feature. And application form says Please provide a URL where we can test Oembed Read. Which I don't have because I have no access to the feature.
What I have tried with no success:
I requested instagram_oembed resource with:
app token of application in live mode
app token of application in
development mode
passed URL to a post by official Instagram account
(e.g. https://www.instagram.com/p/CQG4gZxMzzO/)
passed URL to a post
of a user who is Admin of the app
In all cases I receive (#10) To use 'Oembed Read', your use of this endpoint must be reviewed and approved by Facebook. To submit this 'Oembed Read' feature for review please read our documentation on reviewable features: https://developers.facebook.com/docs/apps/review.
Example of the request I do https://graph.facebook.com/v11.0/instagram_oembed?url=https%3A%2F%2Fwww.instagram.com%2Fp%2FCQG4gZxMzzO%2F&access_token=appAccessToken
We're also suffering from this issue, but so far, we thought we already figured out how to do that.
Big picture
Facebook had not sorted this thing out correctly. Or at least, we don't know why they put such a restriction to this API.
The official document is not correct. (or at least not accurate for now, for some part)
Which part was not correct?
The access token part is not right. Or at least, it's the most confusion part.
How can we resolve this?
Use the Graph API Explorer
Adjust your token(App token, Client access token, user token) with the official URLs(see below) to see if you can get the result
most of us should be able to get the result with user access token, which means you have to access this API after login!
Integrate into your app for review
The review page is also confusing:
Please provide a URL where we can test Oembed Read. Include the URL of a page, post or video from our official Facebook or Instagram pages, or the pages themselves., it means you can only use links like https://www.facebook.com/instagram or https://www.facebook.com/facebook
With that in mind, so far, the only way to get approved is integrate your oembed usage into your normal UI with facebook user access token ready
Question to the big picture
So, we have to ask user to login with our facebook app, then we can provide this oembed read API returned embed HTML? I'm afraid that's what we have now.
big companies might be able to apply for App Token, I guess in that scenario, facebook login is not necessary
for small companies, indie developers, hmmm, I don't know any better solutions so far.
I have run into this too. I do not have an answer at this time, I just want to report on the frustrations of their 'app review' process. Which makes it feel like you are unlikely to get it to work any time soon.
We have a custom embed code for our weblog authors to use (a shortcode kind of thing) which does the oEmbed call. We just take the HTML from the resulting JSON, and insert it into the weblog article page, and that is it. It stopped working, presenting this same error - in live mode, and in development mode.
The kicker is, I then tried submitting it for app review. Filled out everything I could to the best of my knowledge. Provided them a test account and post on our weblog to show the shortcode editing and expected placement. We got rejected. Why? Your embedding resulted in an error, we can't see it in action to approve you.
Yes. The error I am getting is that I need my 'app' to be reviewed and approved.
This is an infuriating process. This is the only Facebook / Instagram API feature we use at this point. No user data. No attempt to make an Instagram clone app or anything like that. Just an embed.
And they are making this simple use case as impossible to use as they can. And the documentation also feels like an infinite loop. They say users of the old Instagram embed call have until September 7 2021 to get approved. But the call does not work at all because we are not approved. So we cannot get approved.
Same loop here. I've managed to report it to Facebook team and get answer "Just submit your Instagram post URL"! I can't believe it, its can't be so simple. I've confirmed it few times with Facebook team person and.... get rejected!
Also, second form in App Review process will LOWERCASE all of your links and I've spent few days just to explain it to reviewers and support person. Still rejected after submitting proper url. This is insane.
My another attempt was about to build a test page where I can auth via Facebook account, parse connected Instagram accounts and GET embed endpoint with user access key in hope that reviewer HAS access to oembed feature - REJECTED. I can't even find what permission I need to add to auth URL to obtain oembed thing.
Will update my answer with new information later.
UPDATE: After reporting about the issue with lowercase URL in submission form they just APPROVED my app without APP REVIEW. Well... Facebook style...
I had exactly the same problem recently. Updated the packages with compose, changed the API version from 10 to 11... without any change.
The error was also occurring in development mode, it didn't make sense that Facebook was asking to approve in dev mode.
For me, the problem came from the management of scopes in my application, depending on the version of the Facebook API used.
My advice: check the scopes defined with API version in your code first.
I had the same issue and the solution is very simple. The only thing you need to do is copy paste an instagram url in the input field saying: Please provide a URL where we can test Oembed Read.
I did the this link: https://www.instagram.com/p/G/
Which is actually the first instagram post :) Got approved. Hope this helps everybody!
This issue is very common in stackoverflow, and there's a lot of different questions and answers about it, yet I couldn't find exactly what I need.
First, I'd like to define exactly what I need: the option to let users log in to my app using their Facebook credentials. The app will save a matching classic Django user. I will only need to use the user's profile picture and to make sure that each time the same Facebook user will be related to the matching Django user.
Unfortunately, I find it really frustrating to implement for the following reasons:
By now, after reading a lot, I couldn't find out what is the best package for this task.
Some people recommend django-social-auth and praise its functionality and documentation. Personally, I don't understand why, since it's not specifically for Facebook and there are no explanations about the client side, i.e the Facebook login button and how the whole flow works.
When you go to Facebook developers, you suddenly find yourself reading about some magical javascript sdk, and about a promise that that's all you need. Then you get frustrated again and can't understand how a client side related sdk can sign up users to your app.
I know developers somehow implement Facebook auth packages in their apps, but I just can't figure out how to do it.
If anyone could tell me: at this time point, what is the best way to add Facebook authentication to my Django app? I would also ask for detailed documentation / tutorial that explains how to log in a Facebook user, from settings and configuration level through signup to Django app and to client side code.
There are multiple ways to approach the problem, what is the "best" way is really subjective.
Subjectively speaking, you could opt for django-allauth. Here are a few pointers to help you get started:
If you want to keep the signup simple, set SOCIALACCOUNT_AUTO_SIGNUP to True in order to achieve a "no questions asked" login. Users simply approve the FB dialog and they end up logged in in your site right away.
Adding a login button to your template is merely a matter of:
Sign In
The app offers support for the JS SDK login (pro: users are accustomed to the typical FB popup that appears), or you can use your own OAuth flow. Whatever you please.
The fastest way understand FB's Oauth 2.0 flow is to play with FB's Javascript SDK. Once you get the hang of it, the FB's PHP library is similar. Also, other OAuth sites like Google, Twitter or Dropbox have almost identical implementation.
In baby steps:
Learn how to install FB Javascript SDK onto a simple page
Use FB.login to determine login status and obtain the login url.
Lastly, use FB.Event.Subscribe and subscribe to auth.statusChange to detect the login/logout changes.
Also, good to check out https://developers.facebook.com/roadmap/ on the upcoming features or features being removed.
django-social-auth is not just for Facebook, but that doesn't mean you should use all the backends available.
Project documentation is at http://django-social-auth.readthedocs.org/en/latest/index.html and Facebook backend details at http://django-social-auth.readthedocs.org/en/latest/backends/facebook.html.
I am working on an app that uses facebook's check in feature from mobile phones. I have created multiple versions of the app on facebook so that i can keep production, test and development separated. All good. However, all my checkins whether test or dev or prod are going to the live facebook platform leading to check ins like "this is a test" or "blah blah" on live facebook pages. Is there a way to be able to check in but not on these real/live pages? In other words, is there a sandbox or development version where developers can freely update content?
Thanks you guys!
Best,
Sachin
So, as with many other things in life, banging my head against the problem helped a bit. I found out that I can create test users for my app - upto 500 of them. The documentation is at http://developers.facebook.com/docs/test_users/. I was able to create test users for my app, login to facebook with those test users and verify that my actions did not show up on public pages. Phew, now i need to deface these public property no more. :-) When doing this, you need to use the app access token not the regular user accesss token. To get that, follow this link: https://developers.facebook.com/docs/authentication/applications/. The last gotcha I faced was that the second link above states that you should have a parameter named grant_type=client_credentials in your graph request. I kept looking for types of client credentials that i could substitute what i thought was a place holder named "client_credentials". That term needs to go in verbatim. (GOTCHA). Also, twice when I tried to create a user, facebook responded with an error json saying that an "unknown error has occured". I was almost ready to give up... but like i said before, banging head against the problem helps. Facebook responded with a json like so after the third request:
{
"id":"*******1832",
"access_token":"*****",
"login_url":"https://www.facebook.com/platform/test_account_login.php?user_id=*****&n=*****",
"email":"****",
"password":"*****"
}
Hope this helps someone else who might also be looking for this info.
Before you start yelling at me, I know many users already asked for something like this, but I read all of them and couldn't find any reply related to my specific case: I eventually managed to get something working but it's not what I think I (and other developers) are looking for. I want to share my experience about this with all of you, so I'll try and describe my scenario and the steps I followed to look into how to take care of this, so please indulge me for this long post: I'm sure it will help some developers in the same situation as I am to clear their minds too, just as I hope it will give others the right information to help me (and others) with it.
I wrote a native Android application that makes use of the Facebook API. I DO NOT make use of the Facebook SDK, because I don't want to rely on the official app being installed on the device (as a matter of fact, my app is in part an alternative to that app so it would be silly to need it installed anyway in the first place), but I rather issue Graph API calls directly via HTTP and handle the responses myself. So if that is the answer you're thinking of giving me, please don't because I won't take that road.
As such, I made use of the Client-side authentication to authorize my app, displaying the URL in a WebView and getting the access_token at the end. I requested offline_access among the other permissions.
Since offline_access is going to be deprecated in May, I started investigating how to get long lived tokens anyway, and so read almost everything I could find related to that, including of course the official guidelines. Long story short, nothing worked for me, and I'm still stuck with very short-lived access_tokens that I can do nothing about.
This is what I did to begin:
Deprecated the offline_access for my app (well not THE app since it's being used by many users right now, but another one which is basically the same and I use for testing purposes only so that's the same thing) in the settings.
Authorized a user using Client-side authentication: https://www.facebook.com/dialog/oauth?client_id=MY_APP_ID&redirect_uri=http://my.domain.com/yeah.htmlscope=publish_stream,read_stream,user_photos,friends_photos,offline_access&response_type=token&display=wap
I got my access_token, but I immediately noticed how it was not long-lived at all, quite the opposite: expires_in was set to something like 6800 seconds (less than two hours). So the first assumption I had made (access_tokens will be longer lived by default) was already wrong.
I looked into how this access_token lifetime could be extended then, and tried almost every alternative out there. Needless to say, every attempt failed. That's what I tried, to be precise:
First of all, I of course tried the "official" approach, that is extending the token through the new endpoint. Skipping for now the rant about how stupid it is to request the client secret for such an operation (as many folks already pointed out, such secret would need to be embedded in the Android app, which is a security nightmare as far as we developers are concerned, and moving this bit server-side to extend the token life on behalf of the user is a nightmare for what concerns them instead, since they'd need to trust me with messing with their access_token), I tried issuing a GET request to that address using the correct parameters: 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 ...The request was apparently successful, but it did NOT extend the lifetime of anything. The request just returned the same access_token as before, with an expires_in parameter that just reflected the sand of time flowing away (the same as before minus the seconds passed since I authorized). Basically, that method only told me how much the already available access_token would live, without refreshing or changing anything, so, despite the obvious security concerns it raises, it is pretty useless too.
I then tried what someone else suggested, that is using the old REST API to do the job, issuing a GET request to the following address: https://api.facebook.com/method/auth.extendSSOAccessToken?access_token=EXISTING_ACCESS_TOKEN which obviously failed too with the infamous "The access token was not obtained using single sign-on" error.
After those failed attempte, I started thinking about what may be the cause of all of them failing. As I anticipated, my app runs on Android devices but makes triggers HTTP requests to the API directly, which I guess may be the root of the problem.
In the advanced section of my developer apps page, my app was configured as "Web" rather than "Native/Desktop". That said, changing it to "Native/Desktop" did nothing but give me a longer-lived access_token at the first logout (about 24 hours rather than 1-2), while the already described attempts at extending its life failed just as before.
The official guideline has an interesting and quite creepy paragraph: "Desktop applications will not be able to extend the life of an existing access_token and the user must login to facebook once the token has expired". While this seems to have been overlooked by many, I started to think this may be the cause of my problems, so I tried an alternative approach, that is, I tried the server-side authentication rather than the client side one: again, this requires client_secret so would be a dumb solution for an Android app but I wanted to try that anyway. So, I got the code first, and then the access_token after that (as described in http://developers.facebook.com/docs/authentication/server-side/). This resulted in a much longer lived access_token (5183882 seconds, that is about 59 days), but then again, both the known means for extending it (even if not really needed in this case) resulted in the same thing: the former not refreshing anything, the latter complaining about the fact it was not obtained via SSO.
So, very long story short (I know, too late), the deadline for deprecating offline_access is so close you can feel it breathing on your neck, and nothing seems to work. What is your experience with all of this and, if you're on the same boat as I am and you managed to get it working, how did you do it?
Thanks for your patience.
I'm working on a django site, which I want the authentication part to work exactly like how Stack Overflow works. A new user comes to the site, they click on "create new account", choose their OpenID provider, get validated, then an account is created for them with "openiduser4356" or something as the username. The user can then go into preferences and change the username to whatever they want. I don't want any kind of local account sign-ups at all.
I pretty much spent all day getting django-authopenid working and it seems the only way this plugin works is by adding OpenID identities to already existing accounts. Heck, you can't even run your site when you have django-authopenid installed unless you have django-registration installed as well...
Before I spend another day wrestling with this thing to try getting it to do what I want, I'd rather just know off the bat if this kind of thing is even possible/a good idea. I noticed that there are a few other OpenID plugins for django out there. Are any of them any better at doing what I'm trying to do?
django-openid does not depend on django-registration.
You might also take a look at a fork of django-openid, django-openid-consumer. It works with the most recent python-openid libraries.
If you don't mind using rpxnow.com, check out http://github.com/howthebodyworks/django-rpx/tree/master