You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Initially, I send a state key under the key = 662f065f05170899644a5a28.
Upon receiving the callback from the Xero API endpoints, it echoes back the same state key = 662f065f05170899644a5a28.
Upon attempting to reconnect (after disconnection from xero's website), I send a new state key = 662f081ed32ff9d3e845ecd7.
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
Steps to reproduce the behavior:
Begin by installing the latest version of the xero-node SDK, version 5.1.0.
Set up the SDK with authentication and callback for a static user.
On the initial connection, set the value in the state key to 1.
After successfully establishing the connection, disconnect it from xero's website.
Initiate the authentication process for the second time.
This time, change the value in the state key to 2.
Perform the connection, disconnection, and reconnection process promptly, within 30 seconds or a minute.
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.
The text was updated successfully, but these errors were encountered:
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.
SDK you're using (please complete the following information):
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:
========================================================================================
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
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.
The text was updated successfully, but these errors were encountered: