You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use urn:ietf:wg:oauth:2.0:oob as default parameter for a redirect URI both when first registering an app with an instance (AppMethods.createApp()) and when performing OAuth (multiple methods in OAuthMethods).
This URI is a special case in that it does not actually redirect anywhere (most likely to a URL that will be intercepted by the app starting the OAuth flow), but will just display a valid code in a browser window. This might be useful in some development contexts, but makes no sense for production code.
I already argued in #68 that we shouldn't use the URI in any sample code. I now think we should not use this URI as default parameter in any of the methods mentioned above, either, but instead make the library user explicitly define a redirect URI in every case. Keeping it as a default parameter might lead to hard-to-debug situations where an actually sensible parameter is omitted and authentication fails as a result of this.
This would not remove the possibility of using this URI, its use would just need to be made explicit - we could even define it as a constant for easy access, if considered useful.
The text was updated successfully, but these errors were encountered:
We currently use
urn:ietf:wg:oauth:2.0:oob
as default parameter for a redirect URI both when first registering an app with an instance (AppMethods.createApp()
) and when performing OAuth (multiple methods inOAuthMethods
).This URI is a special case in that it does not actually redirect anywhere (most likely to a URL that will be intercepted by the app starting the OAuth flow), but will just display a valid code in a browser window. This might be useful in some development contexts, but makes no sense for production code.
I already argued in #68 that we shouldn't use the URI in any sample code. I now think we should not use this URI as default parameter in any of the methods mentioned above, either, but instead make the library user explicitly define a redirect URI in every case. Keeping it as a default parameter might lead to hard-to-debug situations where an actually sensible parameter is omitted and authentication fails as a result of this.
This would not remove the possibility of using this URI, its use would just need to be made explicit - we could even define it as a constant for easy access, if considered useful.
The text was updated successfully, but these errors were encountered: