Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xero Node.js SDK: Inconsistent State Key Handling on Reconnection #683

Open
sanchyanchakraborty opened this issue Apr 29, 2024 · 3 comments

Comments

@sanchyanchakraborty
Copy link

sanchyanchakraborty commented Apr 29, 2024

SDK you're using (please complete the following information):

  • Version [5.1.0]

Describe the bug

Hi,
As I debugging into this issue, here's what I've observed:
When I swiftly log in with Xero using their Node.js SDK (xero-node) and promptly disconnect, then attempt to reconnect:

This issue only occurs when the disconnection happens from Xero's Website > Connected Apps. Here's the sequence:

  1. Connect with the Node.js SDK.
  2. Disconnect from Xero's website.
  3. Then reconnect again using the Node.js SDK

========================================================================================

  1. Initially, I send a state key under the key = 662f065f05170899644a5a28.
  2. Upon receiving the callback from the Xero API endpoints, it echoes back the same state key = 662f065f05170899644a5a28.
  3. Upon attempting to reconnect (after disconnection from xero's website), I send a new state key = 662f081ed32ff9d3e845ecd7.
  4. However, on the second attempt, the Xero callback API endpoint still sends back the first state key = 62f065f05170899644a5a28.

The state key serves as an identifier to verify if the user is genuine and if the authentication request has been duly validated.
As I have meticulously reviewed the live server logs at every step, I am confident that I have not sent the wrong ID, and there is no possibility of error on my part in this matter.

To Reproduce

  1. Steps to reproduce the behavior:
  2. Begin by installing the latest version of the xero-node SDK, version 5.1.0.
  3. Set up the SDK with authentication and callback for a static user.
  4. On the initial connection, set the value in the state key to 1.
  5. After successfully establishing the connection, disconnect it from xero's website.
  6. Initiate the authentication process for the second time.
  7. This time, change the value in the state key to 2.
  8. Perform the connection, disconnection, and reconnection process promptly, within 30 seconds or a minute.
  9. Upon inspecting the callback API response during the second connection attempt, observe that Xero is sending the state key as 1 instead of 2. Ideally, it should reflect the updated value of 2.

Expected behavior
As described in the steps to reproduce the issue, during the first API callback, the state parameter correctly reflects the value of 1. However, upon the second callback, it is expected to send 2 as illustrated in the example. Instead, it continues to send 1.

Copy link

PETOSS-415

Copy link

Thanks for raising an issue, a ticket has been created to track your request

@sangeet-joy-tw
Copy link
Contributor

Hey @sanchyanchakraborty ,

I tried following the above steps in our sample app - xero-node-oauth2-react-app.

I have disconnected from xero's connected apps, changed the state value and re connected back however I do not see any state inconsistency.

While using the sample app please comment out the connect button disable logic, so that you can re-connect after changing the state.

Could you please be on latest version of node SDK v9.1.0 and try the scenario in the above sample app & let me know if you are still facing the issue.

note - When you connect to xero it makes a call to https://login.xero.com/identity/connect/authorize?<query_params> with the payload which should have the latest state key. what ever paylod is sent in this call, the same you will get back in the callback params.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants