Allowing redirect_uri to be different than the one specified in Box dev app options
We are recreating functionalities of our app which allows to sync its files with Box, using .Net SDK and OAuth2. The previous app permitted to have a blank redirect_uri :
which is not allowed anymore. Our customers can deploy our application with any URL so it is impossible for us to hardcode it or to ask them to each create a box dev account and set this.
How can we allow any redirect_uri to be accepted during authorization ?
-
Here is the official response I got, hope it can help you.
Due to vulnerabilities around having a wildcard redirect uri that were discovered around a year ago, we no longer support leaving the field empty.
We do support having a base url which can have a dynamic path, but it would require that at least the base matches. What I mean by this is that if you set the redirect uri in the application to
https://www.example.com/
When generating the url for the authentication process, you can have `&redirect_uri=https://www.example.com/customer1_redirect`
We will check that the base url matches (the https://www.example.com/) and then allow you to have the dynamic path afterwards, and we'll send the redirect to the uri specified during the auth process instead of the base url set in the app.
If the base url does not match, we will reject the authentication request with a redirect_uri_mismatch error. Currently, we do not support having multiple base url redirects in a single application, so you would either need to build a custom flow that redirects to the correct customer's redirect from your service for them to attain the token, or you would need to create multiple applications for each customer to have their own environment set up.
Sorry for any inconvenience this may cause, but unfortunately due to the strict security requirements we are under, we are unable to change this behavior. -
I have run into the same issue, having the redirect_uri in the dev console for development is great and makes sense. But when you get to production it causes complications. I can fully understand the security issues you are referring to, having the ability to add &redirect_uri= to the url could be subverted.
The issue I have is two fold
1. we use sub-domains, eg.
beta.example.com
prerelease.example.com
staging.example.com
The examples given in the official reply only show sub directories, do sub domains work too.
If I define the base uri as example.com, would the uri's above throw an error if added as a redirect_uri?
2. I am using the v2 SDK and there is no mention of the redirect_uri, probably because of the security issues
Is it possible to add &redirect_uri=beta.example.com to the url used in the SDK to modify the redirect uri?
-
To check this myself I changed the redirect_uri in the dev console to the base domain, and then attempted to set the redirect_uri to a subdomain.
Unless I did anything wrong this failed, so I suspect the test for domain does not deconstruct the uri to extract the base domain, just doing a straight text check on the first n chars will fail with subdomains so I suspect that is what the API is doing.
Is it on the development plan to allow subdomains, or can you give me any workaround to use several subdomains.
Thanks
Dave
-
Just sharing I had this issue, until I chanced upon the Box File Picker API here: https://box-content.readme.io/docs/the-box-file-picker
It doesn't require the whole Oauth process using the redirect uri and I manage to get this box feature in my app for external users to upload content to my app.
The problem now is that this API have it's limitation in UI editing but I guess it's an old API..
-
Hello All-
Thank you to everyone that has shared their feedback on this thread. We've definitely heard you and have gone ahead and filed a feature request to the product team. You can track that request here (its currently awaiting approval but will be up soon) and I encourage you all to go give it up an upvote!
Best,
Kourtney
サインインしてコメントを残してください。
コメント
8件のコメント