Unable to Reuse accessToken.oauth_token & accessToken.oauth_token_secret

[mcohen01]

Unable to Reuse accessToken.oauth_token & accessToken.oauth_token_secret

[mcohen01]

"I then created the Quickbooks object in the ecommerce service and I was able to output the accounts as expected.....However if I create the Quickbooks object in the example app, it will output the accounts information, recreating that Quickbooks object again in the ecommerce app with the same token/secret throws the authentication error."

There can only ever be one pair of credentials for a given realm id that are valid at any moment in time. Anytime you successfully complete the OAuth flow and are returned a pair credentials, the last pair of credentials you received for the realm id are invalidated. From what you wrote above it sounds like you are running into this issue. If you're using the example app unmodified, and going through the OAuth flow, then the credentials pair that gets dumped to the console is now the only valid credentials that will work for that realm id.

[mcohen01]

Ok, I'm not sure what QuickbooksAccounting is....are you using node-quickbooks and quickbooks npm libraries together and simply aliased one?

But, yes, you should instantiate a new Quickbooks object for every user/distinct credentials/request in your app.

[wmcbain]

So I've confirmed what I've expected above to be true. If I do not create the Quickbooks object in the example app, I can use the accessToken elsewhere to create this object. However this is not what I expected, as I was under the assumption that by saving the accessToken elsewhere, I could reconnect via the token and secret as many times as I pleased.

This is problematic for me as I will have multiple instances of an ecommerce app, not a typical Quickbooks App, where I can't necessarily inject the Oauth flow into. Users don't know who the provider is, and there will be multiple instances of the app who need to use the same connector. Furthermore it is easier for me to renew a single token rather than multiple tokens. Since I will have multiple instances of the app running, it would be convenient for them to share the tokens.

Based on what I see here I should expect to be able to use the token for 180 days: https://intuitdeveloper.lc.intuit.com/questions/1102089-how-to-use-quickbooks-payments-beta-like-any-other-payment-gateway-on-a-new-e-commerce-shopping-cart Is there any reason why I can't share the tokens across multiple instances of the app?

[wmcbain]

var QuickbooksAccounting = require('node-quickbooks'),
    QuickbooksPayments   = require('quickbooks');

[wmcbain]

Is a side effect of this being unable to connect to the Quickbooks Accounting API and the Payments API at the same time?

[mcohen01]

Sorry, I'm still somewhat confused as to what the problem might be here.

Are you setting the 'payments' and 'quickbooks' datasources to true, as described here?

The other thing that comes to mind is that every time you go through the OAuth dance, and so generate another credentials pair, Quickbooks invalidates all other credentials that existed for that realm id. That may be the problem here. As long as you don't go through the OAuth step again, the last set of credentials you generated will remain valid for 180 days.

[wmcbain]

I think I may just have a misunderstanding. What I'm trying to do is instantiate the Quickbooks multiple times using the same oauth tokens and token secrets that I captured using the example app.

I assumed this was but what I've found is that I can't create the Quickbooks object more than once using the oauth token and secret generated from the oauth flow in the example at. From what you said this is expected?

On Feb 28, 2016, at 10:08 AM, Michael Cohen [email protected] wrote:

Sorry, I'm still somewhat confused as to what the problem might be here.

Are you setting the 'payments' and 'quickbooks' datasources to true, as described here?

The other thing that comes to mind is that every time you go through the OAuth dance, and so generate another credentials pair, Quickbooks invalidates all other credentials that existed for that realm id. That may be the problem here. As long as you don't go through the OAuth step again, the last set of credentials you generated will remain valid for 180 days.

—
Reply to this email directly or view it on GitHub.

[mcohen01]

Yes, you can do new Quickbooks(...) as many times as you want. So you said you do in fact see the listing of Accounts printed to the console when you complete the OAuth dance using the example app. Let me ask a stupid question....are you positive you're capturing the oauth_token and oauth_token_secret printed out here?

In a real app you would probably capture and save those to some datastore and then some background process would periodically fire, get those credentials, and perform some kind of sync, from QBO to your system, or vice versa.

[wmcbain]

I'm fairly certain that I'm capturing the tokens/secret correctly.

As to debug the issue I didn't create the Quickbooks object in the example app. I then created the Quickbooks object in the ecommerce service and I was able to output the accounts as expected.

However if I create the Quickbooks object in the example app, it will output the accounts information, recreating that Quickbooks object again in the ecommerce app with the same token/secret throws the authentication error.

So for some reason I'm unable to recreate the Quickbooks object without authentication errors.

Unfortunately I'm out today so I can't share more probably until tomorrow evening. I really do appreciate the help and I'll provide more info when I get the chance.

Sincerely,
Wyatt McBain

On Feb 28, 2016, at 12:00 PM, Michael Cohen [email protected] wrote:

Yes, you can do new Quickbooks(...) as many times as you want. So you said you do in fact see the listing of Accounts printed to the console when you complete the OAuth dance using the example app. Let me ask a stupid question....are you positive you're capturing the oauth_token and oauth_token_secret printed out here?

In a real app you would probably capture and save those to some datastore and then some background process would periodically fire, get those credentials, and perform some kind of sync, from QBO to your system, or vice versa.

—
Reply to this email directly or view it on GitHub.

[wmcbain]

No I am not running into that. I am using the latest credentials to create the Quickbooks objects.

In your comment above you said I should be able to instantiate multiple Quickbooks objects with the same credentials, as long as those credentials are valid.

My issue is that I am unable to use the credentials to create more than one Quickbooks object. Doing so causes authentication errors on any request transmitted by the Quickbooks object that was not the first to be created.

On Feb 28, 2016, at 12:29 PM, Michael Cohen [email protected] wrote:

"I then created the Quickbooks object in the ecommerce service and I was able to output the accounts as expected.....However if I create the Quickbooks object in the example app, it will output the accounts information, recreating that Quickbooks object again in the ecommerce app with the same token/secret throws the authentication error."

There can only ever be one pair of credentials for a given realm id that are valid at any moment in time. Anytime you successfully complete the OAuth flow and are returned a pair credentials, the last pair of credentials you received for the realm id are invalidated. From what you wrote above it sounds like you are running into this issue. If you're using the example app unmodified, and going through the OAuth flow, then the credentials pair that gets dumped to the console is now the only valid credentials that will work for that realm id.

—
Reply to this email directly or view it on GitHub.

[wmcbain]

Yeah I just want to confirm on the above that I am not invalidating the tokens/secrets from the example app that I'm using in my ecommerce app.

Per the example app:

  request.post(postBody, function (e, r, data) {
    var accessToken = qs.parse(data)

    // save the access token somewhere on behalf of the logged in user
    qbo = new QuickBooks(consumerKey,
                         consumerSecret,
                         accessToken.oauth_token,
                         accessToken.oauth_token_secret,
                         postBody.oauth.realmId,
                         true, // use the Sandbox
                         true); // turn debugging on

    // test out account access
    qbo.findAccounts(function(err, accounts) {
      accounts.QueryResponse.Account.forEach(function(account) {
        console.log(account.Name)
      })
    })
  })

The findAccounts request behaves as expected and outputs various accounts information.

I save accessToken.oauth_token, accessToken.oauth_token_secret, and postBody.oauth.realmId and use them to recreate the Quickbooks object, renamed QuickbooksAccounting to accomodate the Payments API, in my ecommerce app:

var QuickbooksAccounting = require('node-quickbooks');

var qboa = new QuickbooksAccounting(config.consumerKeys[env],
                         config.consumerSecrets[env],
                         config.oauthTokens[env],    // accessToken.oauth_token
                         config.oauthSecrets[env],   // accessToken.oauth_token_secret
                         config.realmIds[env],       // postBody.oauth.realmId`
                         true,
                         true);

qbo.findAccounts(function(err, accounts) {
      accounts.QueryResponse.Account.forEach(function(account) {
        console.log(account.Name)
      })
})

Making the call to findAccounts with the saved credentials now throws an authentication error.

[mcohen01]

Without seeing all of your code it's hard to diagnose. Are you using the example app unchanged? If so, the javascript call to start the OAuth flow is probably not pointing at the sandbox environment, yet you appear to be using the sandbox environment later on. If you're consistently getting 401s I would try to use the live environment with the example unchanged other than your consumer key and secret.

[wmcbain]

So I've been able to get the Quickbooks object to persist and to be able to create multiple instances from the same token & token secrets. What I ended up doing was create an internal network api to centralize the calls to Quickbooks. Only leaving this open as I've only been working against the sandbox so far. Will close once I test production.