My php app is integrated with Facebook's Graph API. I recently conducted load testing and found out that I hit the 600 requests per 600 seconds limit rather easily with a low number of users(1 large single batch request per user). In order to make my app work I feel that I would need to rely on user tokens(client side) instead of my single app token(server side).
My question is: Is what I want to do even possible and does my proposed solution make sense and how could I implement it?
1) Use JS sdk to login the user to FB and obtain a user token
2) Pass the user token to the php side
3) Make the graph api call using the user token
I am reading http://developers.facebook.com/blog/post/534/.
It says "this allows you to connect the user to your site or app using the JavaScript SDK (FB.login or the Login Button) and then call Platform APIs from server-side PHP without doing additional work". Does this mean using the user token or app token?
I am not looking to be spoon fed code, but could someone please point me in the right direction and give their opinion on my proposed solution?
Thanks
Related
I am migrating to Xero and want to set an invoicing process to run once a month at a specific time using a cron job, I can get the cron job to fire and I have set up a php page based on https://github.com/XeroAPI/xero-php-oauth2-app which I can run manually and it works perfectly.
I've also used https://github.com/XeroAPI/xoauth to retrieve the tokens and store them in the keychain, I can see that they are there.
I've got a bit lost where xoauth says "Piping the access_token, id_token and refresh_token to stdout, so you can use them in a script workflow"
I'm hoping someone has done something similar and can point me in the right direction or even better give me an example as I can't find one online.
I assume I am missing a link between the 2 examples which transfers the token values.
When the cron runs I get the following error
'Fatal error: Uncaught BadMethodCallException: Required parameter not passed: "refresh_token" in /Applications/MAMP/htdocs/vendor/league/oauth2-client/src/Tool/RequiredParameterTrait.php:35'
which is not really a surprise as I'm not giving it a refresh_token as far as I can see.
I am using localhost on a Mac as a development environment.
I have seen a number of questions related to this from more experienced developers but no answers.
Thanks Gordon
thanks for your question. We have gotten this one a lot so I used this as the base for a XeroAPI community-corner video that I will share back here soon that walks through getting access/refresh tokens from xoauth, making api calls, and refreshing to get a new token set.
Answer
What you want to do is after you generate the access token with the xoauth repo. In your PHP script - plug in the access_token & xero-tenant-id (as 2 headers in your api call).
Authorization: "Bearer " + access_token
xero-tenant-id: tenantId
Ensure the API call returns your data. Then create a function in your script that does the following before future API calls
Refreshes for a new token_set
Saves new token_set to a DB or static file
Use that token_set 'access_token' to make your Invoice API call
Repeat step (1-3) at least once every 60 days
NOTE: you will need some kind of persistence to store the continually
refreshed token_set.
Hope this clarifies it for you. I will post back the video for an in depth walkthrough asap.
OAuth2.0 Background:
Essentially our move to simplify and standardize our API authentication came with some challenges in how to setup longstanding API connections for use cases that didn’t need to onboard an increasing number of new users. For instance, a lot of small businesses and accounting firms setup custom processes to batch import/export invoices.
The use case often did not have the need for an application user interface, so standing one up just to get a valid access token was a lot of extra work if the integration only needed to connect to single ‘admin’ type user for a specific Xero Organisation.
I have a client that wants to take orders via an online form, with the idea being that an order can be submitted and stored in a database via my application while simultaneously generating an invoice on submission in QuickBooks.
How do I do this in PHP when the person entering in the order is not the client but a client of the client? It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order. How do I think about this?
I'm not interested in anyone having to hit a button that says "connect to quickbooks" especially not the person filling the order because again, that person is a customer and doesn't need to know about the internals of the customer's invoicing system.
I just really want to use the Accounting API to generate invoices. Is there no way to simply link my backend to my one company directly in the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens. I'm unclear about what direction I should be going in and don't want to waste time with a client-side library if I don't need it to do backend logic.
Here's some example code that does exactly what you're looking for:
https://github.com/consolibyte/quickbooks-php
Along with a quick-start guide:
http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Intuit_Partner_Platform_Quick-Start
Also see notes about your comments below -- you're on the right track, you're just misunderstanding how OAuth works:
It seems like Quickbooks uses Oauth tokens and a javascript library to generate them to connect a company to an app, but I'm simply writing a backend for one company and want that backend to create invoices when saving an order.
Correct, Intuit uses OAuth, and a little Javascript thing to kick off the OAuth process.
I'm not interested in anyone having to hit a button that says "connect to quickbooks"
Someone needs to hit this button... BUT only ONE PERSON needs to hit the button ONCE, EVER, and then NEVER again.
The owner of the company (e.g. your boss) needs to click the button ONCE, which gives the OAuth creds (and the realm ID) to you. Once your boss has done this ONCE, then you have the creds to use forever, for all of the actual customers.
Your customers (e.g. the people actually checking out/placing orders) DO NOT click any buttons, nor do they see or have any idea at all that you're even using QuickBooks.
just really want to use the Accounting API to generate invoices.
Cool, you can totally do that!
Is there no way to simply link my backend to my one company directly in > the Quickbooks SDK configuration and achieve this, or do they need to use a javascript library to get tokens.
Follow the quick-start above. It should take you about 15 minutes to get a working OAuth connection, and then you never need to use the client-side stuff ever again.
You only need to authenticate every 180 days btw.
If you use the reconnect script, you only need to authenticate ONCE, and can automatically renew the tokens every 180 days, no user-interaction required.
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/reconnect.php
Well with the realm_id for example, I don't understand how that relates to ouath.
The realm ID is just a unique identifier for the particular QuickBooks Online company you're trying to connect to. Yes, you need to store it. If you use our libs, this is done for you automatically.
I guess I don't understand if I'm developing for one client why can't I just get their realm_id from them and then keep using it rather than making them do some form of authentication?
Again, they only have to authenticate ONCE. That's Intuit's way of giving you the realm ID and credentials you need to connect. Once you've done it ONCE, you never need to do it again. It takes all of about 30 seconds.
If they were to just give you OAuth creds without any authentication, it would be a gigantic security hole. If you read the Wikipedia article on OAuth it talks in depth about this, and the goals of OAuth.
Okay I think I get it, so they have to authenticate once every 180 days?
Once every 180 days, UNLESS you use a reconnect script, in which case they just authenticate once and then never ever have to worry about it again.
So I can store the token and the realm_id in a database before it expires and just use that?
Yes.
In this way my client can authenticate and then my scripts can generate invoices for them when their customers visit our website?
Yes!
I have a website I'm working on. It enables users to register and post stuffs within the site. Can I get a link to some sort of api that allows people to add their facebook account (once) and then automatically post what they posted on my site on their facebook newsfeed (the sort of thing that happens when you connect your facebook account to your twitter account) .I've searched and can't seem to get exactly what I want
What you want is pretty common and if you searched you clearly didn't do a good job on the search.
Using the Facebook PHP SDK is pretty straight forward. There is a PHP Library available with a demo of the functionality you want. In your case you need to do some stuff more, so I'll explain globally what you should do:
Get the Facebook PHP SDK and load it into your website, determine what scope you need to perform the actions what you are going to do, in your case you need to have access to their timeline which is called the publish_stream scope. In order to get the Facebook PHP SDK working you need to create an app at http://developers.facebook.com
If a user grants access you need to save the authentication token that the user provides and save it in your database for later use. I'm not 100% sure how long they are valid, I think it's maximum of 30 days at the moment, but you have the ability to refresh the toking in the requests you make (correct me if I'm wrong, it's been a while..)
Everytime an action is done using the Facebook API you inject the usertoken in the request, thus performing the "post" action onto their timeline.
What you are looking for is pretty straight forward and easy to find..
This is in relation to the online version of Quickbooks, QBO (not the desktop).
We need our serverside code to be able to log-in and query some data from quickbooks (just like your API provides) and supply this information to our billing system. This would not involved a browser and use something like curl but this means there is no browser and no human to 'log in' and 'request access' each time. I have not found a way to do this yet. Any ideas?
Your question was already answered over here:
https://intuitpartnerplatform.lc.intuit.com/questions/767273-how-can-i-use-api-to-get-quickbooks-data-without-browser-based-oauth
Alas, for the sake of verboseness:
No matter which API you choose, you can do what you're asking.
Regardless of which API you go with (qbXML, or Intuit Anywhere/OAuth) you only need a human to get things connected the very first time you connect.
After that very first time, you can fetch data at any time you want (as you suggest, with CURL) with zero interaction with an actual user. All you have to do is store the OAuth credentials that Intuit gives you. This is how all OAuth implementations work - you store the credentials you get back, so you can request data unattended later.
If that's not the behavior you're seeing, it just means you've implemented something incorrectly (and should probably post your code, so we can help you troubleshoot).
You might want to check out the QuickBooks PHP DevKit, which has examples of doing just what you're asking for:
http://consolibyte.com/quickbooks-open-source/
Best approach is to generate the access token and the refresh token manually via the Quickbooks OAuth playground https://developer.intuit.com/app/developer/playground, save these values and then refresh token every hour.
This process however need to be repeated every 101 days because of refresh token expiry.
I am doing some benchmark testing on my web app and notice that the responses from Facebooks API are a lot slower than Twitters.
** For the record, I am using the twitter-async library for Twitter API integration and Facebooks own library here
With the Twitter library I can save an oAuth token & secret, I then use these to create an instance and make calls, simple. For Facebook, unless I ask for offline_permission, I must store an oAuth code and recreate an oAuth access token each time the user logs into my app.
Given the above I can:
Retrieve a Twitter users timeline in 0.02 seconds.
Get a FB oAuth Access Code in 1.16 seconds, then I can get the users details in 2.31 seconds, totalling 3.47 seconds to get the users details.
These statistics are from using functions Facebook has provided in their PHP API library. I also tried implementing my own CURL functions to get this information via a request and the results are not much better.
Is this the same kind of response times others are getting using the Facebook API?
Besides requesting offline permission and storing the permanent access token, how else can I speed up these requests, is the problem on my end or Facebooks?
Thanks,
Chris
I also have the experience the Facebook API is quite slow. I believe the facebook PHP API does not much more than wrap around CURL in the case of API calls so it makes sense that this didn't improve the speeds.
I work on a canvas page, which means for existing users, I get an access token and fb_UID as he/she comes in. At first, I did a /me graph call and sometimes a /me/friends. The first takes like 0.6 secs, the second usually a bit more. So in that case I can (to some extend) confirm your findings.
That's why I've now switched to storing important stuff locally and updating it only when needed (real time update API). Basically, I don't need any API calls during 'normal' operation.
I realize you are probably integrating FB on your own page, and perhaps use a bit more info than just name, fb-UID & friends, and that this solution is not totally answering your question. But perhaps it can still function as a small piece of the puzzle ;)
I am looking forward to other perspectives on this as well!
My application calls multiple URL's from Facebook. It does take some time :/
This is why I decided to write a function which stores the results in $_SESSION so I can use it again later, along with a timestamp to see if the data is too old.
This doesn't solve the actual problem, it just saves you having to keep fetching it.
What I like to do for end user experience, is forward them to page with a loading .gif - then have javascript request the page that actually fetches data. That way, the user remains on a loading page with a nice gif to stare at, until the next page is ready.