# Potential issue with app approvals in FreeAgent production (works in sandbox) **URL:** \ **Category:** Authentication\ **Created:** [6 April 2017 10:49 UTC](https://api-discuss.freeagent.com/t/potential-issue-with-app-approvals-in-freeagent-production-works-in-sandbox/752 "2017-04-06T10:49:25Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dylansmith](https://api-discuss.freeagent.com/user_avatar/api-discuss.freeagent.com/dylansmith/32/79_2.png) [@dylansmith](https://api-discuss.freeagent.com/u/dylansmith)\ **Post date:** [6 April 2017 10:49 UTC](https://api-discuss.freeagent.com/t/potential-issue-with-app-approvals-in-freeagent-production-works-in-sandbox/752/1 "2017-04-06T10:49:25Z")
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](https://api-discuss.freeagent.com/t/forthcoming-api-oauth-restriction-change/643) 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? ---
**Author:** ![dylansmith](https://api-discuss.freeagent.com/user_avatar/api-discuss.freeagent.com/dylansmith/32/79_2.png) [@dylansmith](https://api-discuss.freeagent.com/u/dylansmith)\ **Post date:** [6 April 2017 12:03 UTC](https://api-discuss.freeagent.com/t/potential-issue-with-app-approvals-in-freeagent-production-works-in-sandbox/752/2 "2017-04-06T12:03:16Z")
@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. ---
**Author:** ![dylansmith](https://api-discuss.freeagent.com/user_avatar/api-discuss.freeagent.com/dylansmith/32/79_2.png) [@dylansmith](https://api-discuss.freeagent.com/u/dylansmith)\ **Post date:** [26 April 2017 14:14 UTC](https://api-discuss.freeagent.com/t/potential-issue-with-app-approvals-in-freeagent-production-works-in-sandbox/752/3 "2017-04-26T14:14:57Z")
Can someone at FreeAgent please acknowledge this issue? It’s been 20days since it was reported. ---
**Author:** ![Sebastian\_Bobrowski](https://api-discuss.freeagent.com/user_avatar/api-discuss.freeagent.com/sebastian_bobrowski/32/96_2.png) [@Sebastian\_Bobrowski](https://api-discuss.freeagent.com/u/Sebastian_Bobrowski)\ **Post date:** [4 May 2017 13:51 UTC](https://api-discuss.freeagent.com/t/potential-issue-with-app-approvals-in-freeagent-production-works-in-sandbox/752/4 "2017-05-04T13:51:28Z")
@dylansmith - it’s a truck but you can change Redirect URI into [https://foo.com/bar](https://foo.com/bar)?_&_ and then it works for [https://foo.com/bar?baz&qux](https://foo.com/bar?baz&qux) - replace only alphaumeric chars, not slashes or dashes.