I have an application (php) that handles the API for years.
However a few weeks ago it started giving the error sporadically:
(400) API key not valid. Please pass a valid API key.
In the end the error was continuous and stopped responding.
I related it to Google Calendar API - no longer authorized for reads?
After several days of inactivity, the application worked again for a few days, but the pattern has been repeated again:
It has been giving the error more and more frequently until it has stopped working.
Edited:
The application can be viewed at:
http://intraneteina.unizar.es/intraneteina/index.php?r=calendarioGoo/index
When selecting any option from the dropdown, the application reads information from a google calendar and displays it in html.
It has been working for years, and without touching the code, now it gives the described API error key not valid.
I had been experiencing a similar issue. I found some documentation, eventually, that said there was a limit of 50 (or possibly 100) "active" authorisation tokens allowed for an app unless you are running it via a service account. Typically once the limit is reached Google just drops authorisations off the end of the "active list" it maintains and you are unaware of this happening. This is a problem if you are relying on the expiry of your access token and don't generate a refresh token until you think you need to - i.e. When you generate/refresh your access token you record the expiry date and only refresh it when you system tells you that your token has expired.
Because Google may have disabled that token (dropped it off the active list) in the background and you are unaware of this you try to use that token which hasn't expired - the result is a typically uninformative error message with no indication of what has happened. In our case in the short term setting up a service account was too difficult (implementing RSA256 for the authorisation process) so we got around this by just ignoring the recorded expiry timestamp and requesting a refresh token every time we made a call to the API. I'm sorry I can't link you to the documentation, but I believe I found it via an answer in another S.O. post.
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've been working with the Podio API for nearly a year now and have rarely had issues, but I recently ran into one that I can't figure out. I'm not even sure how to test what is going on. When an item is created, I have a webhook to a script which will send an http GET request to an item and perform a number of functions. The script runs just fine and has never run into any issues, unless I create a number of items in quick succession (15 or so). If I do this, a certain number will finish successfully, and then I will suddenly get the following error with each new call:
2016-11-14 16:41:14 401 GET /item/514610204
2016-11-14 16:41:14 Reponse: {"error_parameters":{},"error_detail":null,"error_propagate":false,"request":{"url":"http:\/\/api.podio.com\/item\/514610204","query_string":"","method":"GET "},"error_description":"invalid_request","error":"unauthorized"}
If I wait a minute or so, it begins working again.
I'm authenticating with username and password. Does anyone know what is going on or how to check what is going on? The podio.log has not been helpful in this situation.
(UPDATE)
The issue is that I am hitting an authentication request rate limit because I haven't been using a session manager. I'm now attempting to do this, but having issues. My code using the Redis setup is as follows:
require_once 'models/PodioRedisSession.php';
Podio::set_debug(true, 'file');
Podio::setup($client_id, $client_secret,array(
"session_manager" => "PodioRedisSession"
));
Podio::$auth_type = array(
"type" => "password",
"identifier" => "MY_EMAIL"
);
Podio::$oauth = self::$session_manager->get(Podio::$auth_type); //ERROR IS ON THIS LINE
if (!Podio::is_authenticated()) {
Podio::authenticate_with_password('MY_EMAIL', 'MY_PASSWORD');
}
which gives me the following error: Cannot access self:: when no class scope is active.
Am I on the right track to get the session manager working with password authentication? The error occurs on the commented line.
(UPDATE)
I was finally able to get the system running properly. The code above is correct. The server just needed to be reset (Windows server) for Redis to take affect.
If your script is authenticating to Podio each time an item is created, it is possible that you are running into the Podio API’s rate limit on authentication requests.
Are you generating a new auth token each time the script is triggered by your webhook? The Podio client libraries include some general documentation on session management that may be useful!
To avoid hitting this limit you should authenticate with the API once and then store the oauth and refresh tokens that at are returned from the API. Redis will do the trick. Then you use the oauth token for all subsequent requests.
An example can be found here [1]
Your oauth token will be valid for at most 28 days. When it's no longer valid you will need to obtain a new oauth token using the refresh token you received when you first authenticated. [2]
[1] https://developers.podio.com/authentication/username_password
[2] https://developers.podio.com/authentication
I've been using the QuickBooks PHP DevKit for some time now in production with no issues.
However, recently I've been getting the following error from my create_invoice ajax script when I spit out:
if($resp = $InvoiceService->add($Context, $realm, $Invoice)){
//create invoice code here
} else
{
echo $InvoiceService->lastError();
}
I get the following error:
3200: [message=ApplicationAuthenticationFailed; errorCode=003200; statusCode=401, ]
The only documentation I can find about this error is that error code 3200 means "Outdated edit sequence" but I am creating an Invoice.
So why is this error all of a sudden appearing?
It seems to have started giving me this error since July 11th. Before then everything was working fine.
Do I need to refresh my access tokens, and how would I go about doing that?
The only documentation I can find about this error is that error code 3200 means "Outdated edit sequence" but I am creating an Invoice.
Error code 3200 (for qbXML) is entirely separate from error code 003200 (for IPP/v3), so "outdated edit sequence" isn't really relevant here at all.
So why is this error all of a sudden appearing?
Generally a "401 Authentication Failed" error pretty much means exactly what it says - authentication against the app failed.
This could be because of several reasons:
Your OAuth tokens expired (they expire after 6 months if you don't renew them)
Your OAuth tokens/connection were disconnected (this can be done from within the UI Intuit provides)
You're not sending the correct OAuth tokens anymore
Did you check your OAuth tokens? Are they still valid? Are you sending the correct ones?
Do I need to refresh my access tokens, and how would I go about doing that?
Maybe.
You can go back through the connection process (e.g. click the "Connect to QuickBooks" button again) to renew them.
If they have expired (e.g. you didn't renew within 6 months) you should implement the reconnect call to avoid this in the future:
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/reconnect.php
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/
https://github.com/consolibyte/quickbooks-php
According to paypal rest docs, for every transaction to paypal I need to submit an 'Authorization:Bearer' which is an access token that is generated from a previous request. I wasn't able to glean from the docs whether or not the 'access_token' can be re-used for multiple requests over it's lifetime? My thought here is to cache the response (on my end) for 6 hours, so I can limit the number of requests to paypal, which should be fine, because the expiry from paypal is 8 hours.
Anyone know if I can re-use the generated access_token for multiple, exclusive transactions?
Yes, the access token can be reused over multiple requests for the lifetime of the token.
In fact, I would recommend it; like you said it cuts down on the number of requests you need to make to us.
I searched for an answer to this as well. It is obvious that this token should be reusable but I failed to find out how and its duration.
Finally, I found a valid resource at the last paragraph here , stating that it is reusable, for the duration provided as the response header (or variable? (NVP)) "expires_in".
But note that nowadays the SDK has the capability to do this for you. Say no more and head straight to this page for more information.
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.