AuthApi.authorizeUrl Doesn't encode redirectUrl
btilford opened this issue · 6 comments
Describe the problem you'd like to have solved
When calling AuthApi.authorizeUrl it creates an invalid AuthorizationUrlBuilder instance because it does not encode the redirectUrl parameter.
On AuthApi.java L202 it requires that it be a valid (unencoded) URL but then in AuthorizedUrlBuilder L43 it is added to the query parameters as an encoded query parameter (without making sure it is encoded).
Describe the ideal solution
Either AuthorizedUrlBuilder or AuthApi should encoded the redirectUri or should call the OkHTTP addQueryParameter instead which will handle encoding it instead of addEncodedQueryParameter which expects it to be pre-encoded.
Alternatives and current work-arounds
Manually building the URL without auth0-java utilities.
Additional information, if any
Thanks for catching this, you are correct. The JavaDoc for AuthAPI#authorizeURL states that the redirectUri Must be already URL Encoded, but as you raised, passing an already encoded URI results in a validation exception 🤦. We'll look into a fix. Thanks again!
Also, the same issue would apply to AuthAPI#logoutUrl, so we should fix both.
@btilford do you have an example of a redirectUrl that is a valid Allowed Callback URL in your Auth0 application, but is being rejected as invalid by authorizeUrl()? I'm still investigating, but I haven't found a valid Application Callback URL that fails validation of authorizeUrl(). At a minimum there's some Javadocs changes needed as "URL Encoded" is too vague or misleading, but I'd like to reproduce the issue to understand further. Thanks!
@jimmyjames I ended using OkHttp directly so I don't have a specific example handy. But I think if you use a redirect URL with query parameters in it (the redirect url) you will be able to reproduce it.
Something like
redirectUrl = 'https://my.domain/callback?a=b&x=y'
@btilford thanks. I see the issue, and think we can fix it without any unintended side effects since passing in a previously encoded URL would fail validation as you mentioned.
After further investigation, we've updated the documentation to reflect the actual current behavior. We may change the code in a future release, but that could have unintended consequences, so addressing this through documentation for now.