QuickBooks IPP v3 getting error 3200 when adding Invoice - php

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

Related

Google Calendar API- API key is no longer valid without reason (400)

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.

How do I authorise a cron job php file to access Xero?

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.

Podio authentication fails after multiple calls

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

oAuth request token issue Codeigniter/Magento2

Been going around in circles with this and not getting a definitive answer... The error I am facing is:
oauth_problem=Cannot+create+request+token+because+consumer+token+is+not+a+verifier+token
Everything is correctly set with regards to my oAuth request header and sending to magento path /oauth/token/request. I have, even though the documentation says it doesn't require it (but for testing) added the verifier string to the request...
Pasting the code in here would make for a very long post and the code is working fine albeit it seems something is missing? If I use the verifier string in the consumer key it gives me the following error instead:
oauth_problem=Consumer+key+is+not+the+correct+length
Does anyone have any nuggets of information that the following links are missing that's tripping me up?
http://devdocs.magento.com/guides/v2.0/howdoi/webapi/integration.html
http://devdocs.magento.com/guides/v2.0/get-started/authentication/gs-authentication-oauth.html#pre-auth-token
I have found this on github, some people have seemed to work it out but not forthcoming with the details of how? github
This error occurs if you already have a request token created in Magento DB table oauth_token (if you're like me and developing an app and raising requests over and over to test), clear this table of its entries (request and verify) before retrying and this error won't appear.
2020 UPDATE:
This answer is still valid. Sometimes you may need to clear the Magento cache also after clearing the oauth_token table entries.

google-api-php-client apiAuthException refreshing OAuth2

I'm developing a PHP script to display a page with some charts and stats about my Analytics profile. I'm sending 3 or 4 ajax asynchronous calls to the server; the server then fetch data using google-api-php-client . There are about 10 requests to Google for each page refresh.
The problem is i'm getting totally random exceptions from the api:
Fatal error: Uncaught exception 'apiAuthException' with message 'Error
refreshing the OAuth2 token, message: ' in apiOAuth2.php on line 242
One time i successfully get the data, one time not. This is very annoying because i cannot find why. What could be? The asynch calls maybe?
User quota is set to 1000 requests/second just to be sure. Eventually i get 'User quota exceded' from the api, something quite impossible.
I answer to myself because i found the problem (was my bad):
I store the access token into an encrypted file
Even if the access token should be offline it's not really offline: it expires but contains a refresh token that APIs will send to get a new fresh access token
The new access token should be saved again into the file (i save it into __destruct() method of my wrapper class) and used for the next request (i was not saving it!)

Categories