Hi,
I have setup a Xero application as follows:
The configuration is as follows:
When I try and authorise, I get this:
I don’t get a code and clicking the back button on the browser shows this:
I know that there has been some sort of authorisation because when I try and authorise again, I get a message as follows:
This indicates that some sort of authorisation has already happened as it it says continue with 1 organisation…
Any ideas?
Thanks
Shaheed
Hello @Shaheed_Fazal !
Please, change redirect URI both in EasyMorph and in Xero web app configuration from https://localhost to something like http://locahost:1234 (note the https → http part).
This should be done both in web configuration and data connector configuration and these URIs have to match.
Thanks for the reply. Does it matter about the port number or can I just choose any at random?
Yes, any free non-blocked port would do
I’m really sorry to be a pain but I just can’t seem to get past this error.
Please, show the updated configuration screenshots 
Sorry I made a silly mistake and still left the s in https. Thanks for your help @olysak. I really appreciate it!
Hi,
Now I am getting another issue. After a day or so, the status of the application on Xero’s website is showing as unauthorised again. I get a 401 error.
In order to resolve this issue, I have to reauthorise via EM connector screen. I don’t quite understand why as the Xero API says that if I add the scope offline_access to my initial request I can use it in offline mode.
Do you have any idea why?
NB: I have tried using both the web app and desktop/mobile app method as described in their docs.
Yes, your scopes look OK and Xero docs say offline_access should be enough for receiving a refresh token - and most certainly you do receive one, because their access token lives only for 30 minutes, not days. Maybe this is a good cause to contact their support.
Oh, I think I've found the cause
The response will contain a new access token and refresh token. You must save both tokens in order to maintain api access.
If, for whatever reason, your app doesn’t receive the response, or fails to save the new token, you can retry using your existing refresh token for a grace period of 30 minutes. After 30 minutes your previous refresh token will expire and the user will need to re-authorise your api application in order to generate a new refresh token.
It seems that Xero invalidates refresh token during refresh sequence and returns a new refresh_token alongside with access_token. Unfortunately, we do not support this scenario with generic WebLocation connector - we treat refresh_token, once received during interactive authorization, as immutable.
In the latest (v5) release we've added mutable state / shared memory system to handle these cases, but still not in generic way - every provider seems to invalidate refresh tokens in their own fashion.
Thanks for looking into this further. I have not downloaded v5 as I was waiting for it to become more stable first. If one is to use the shared memory system, how would we do this? Can you share an example of how to workaround this issue?
Did you perhaps find a way around this as I`m dealing with the same issue regarding the refresh token?
Hi @marius
In the latest EasyMorph this should be handled automatically, meaning that if during token refresh OAuth provider returns refresh_token alongside with new access token, this refresh_token will be saved as a replacement. But, all this will work only if OAuth provider (by OAuth provider I mean Xero, Google, Salesforce etc) is actually configured to send a new refresh token to the client. If OAuth provider’s API just silently expires refresh_token then there is no way to workaround that.
Also note that all this will not work in situations where you leave your token(s) inactive for the refresh_token expiration time (usually this is longer that one ~month). In this situation when EasyMorph tries to issue first request to the API after a long period of time it has already invalid token pair with no way to refresh it.
