Potential issue with app approvals in FreeAgent production (works in sandbox)

Authentication
1

Hi there

We have discovered that users of our app are not able to authenticate with FreeAgent in our production environment. The error we are receiving is:

Sorry, there’s been a problem
The redirect URI is invalid for this app. Please get in touch with the author of the application you’re trying to approve.

We have done some analysis and can confirm the following:

  1. Our staging and production environments are running identical code, and are configured exactly the same in FreeAgent (Redirect URI, etc)
  2. Our production code has not changed in 10 days and was working previously
  3. Approving an app still works as expected in staging but not production
  4. The approval URLs appear to match across environments (therefore the Redirect URI check should pass for both):

Staging

https://duecourse.sandbox.freeagent.com/app_approvals/new?client_id=REDACTED&redirect_uri=https%3A%2F%2Fintegrations.duecourse.rocks%2Fproviders%2Ffreeagent%2Fcallback%3FcompanyId%3DREDACTED%26origin%3Dhttps%3A%2F%2Fapp.duecourse.rocks&response_type=code&state=REDACTED

The Redirect URI(s) configured are:

https://integrations.duecourse.rocks/providers/freeagent/callback

Production

https://duecourse1.freeagent.com/app_approvals/new?client_id=REDACTED&redirect_uri=https%3A%2F%2Fintegrations.duecourse.com%2Fproviders%2Ffreeagent%2Fcallback%3FcompanyId%3DREDACTED%26origin%3Dhttps%3A%2F%2Fapp.duecourse.com&response_type=code&state=REDACTED

The Redirect URI(s) configured are:

https://integrations.duecourse.com/providers/freeagent/callback

Has there been a recent change to this area of FreeAgent? This is an urgent issue for us.

Update: we have reviewed Forthcoming API OAuth Restriction change but our Redirect URIs have been configured for some months and they appear to be valid and correct.

@Paul_Smith can you please take a look at this? Are you able to debug what the cause of the rejection is on your end?

2

@Paul_Smith I’ve isolated the problem to the query string on our Redirect URI.

If we hit https://api.freeagent.com/v2/approve_app?client_id=REDACTED&redirect_uri=https%3A%2F%2Fintegrations.duecourse.com%2Fproviders%2Ffreeagent%2Fcallback&response_type=code&scope=full_access&state=REDACTED then the approval works as expected.

If we hit https://api.freeagent.com/v2/approve_app?client_id=REDACTED&redirect_uri=https%3A%2F%2Fintegrations.duecourse.com%2Fproviders%2Ffreeagent%2Fcallback%3Ffoo&response_type=code&scope=full_access&state=REDACTED then it fails.

However, we are using a query string in our requested against the sandbox with no issue. Could this be a parsing issue with the recent Redirect URI validation changes?

UPDATE: Some things we’ve discovered while testing:

  1. If you specify a Redirect URI of https://foo.com/bar?* then it will match https://foo.com/bar?baz but not https://foo.com/bar?baz&qux
  2. We cannot include URL-encoded characters in the query string or as subpaths, even if they are double-encoded, e.g. https://duecourse1.freeagent.com/app_approvals/new?client_id=REDACTED&redirect_uri=https%3A%2F%2Fintegrations.duecourse.com%2Fproviders%2Ffreeagent%2Fcallback%2Fhttps%253A%252F%252Fapp.duecourse.com&response_type=code&state=REDACTED

It seems like our only solution here would be to two-way hash (e.g. hex encode) the data we need to pass.

3

Can someone at FreeAgent please acknowledge this issue? It’s been 20days since it was reported.

4

@dylansmith - it’s a truck but you can change Redirect URI into https://foo.com/bar?& and then it works for https://foo.com/bar?baz&qux

  • replace only alphaumeric chars, not slashes or dashes.