Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnsupportedOperationException: This isn't a hierarchical URI #103

Closed
ricalo opened this issue Aug 26, 2016 · 5 comments
Closed

UnsupportedOperationException: This isn't a hierarchical URI #103

ricalo opened this issue Aug 26, 2016 · 5 comments

Comments

@ricalo
Copy link

ricalo commented Aug 26, 2016

Hi,

I'm trying to get this library to work with the Microsoft v2 Authentication Endpoint. I'm running into the following error:

java.lang.RuntimeException: Unable to start activity ComponentInfo{net.openid.appauthdemo/net.openid.appauth.RedirectUriReceiverActivity}: java.lang.UnsupportedOperationException: This isn't a hierarchical URI.

The exception is thrown in RedirectUriReceiverActivity.

The problem is that the Microsoft URI format is like this urn:ietf:wg:oauth:2.0:oob and Uri.getQueryParameter doesn't like it.

Is there any workaround to make it work with this provider?
Thanks for the great work, by the way.

@iainmcgin
Copy link
Member

We may be able to add support for this special URI, but we currently recommend either using a custom scheme reflecting your package name or an HTTPS app link. I'm on vacation right now, I'll comment further when I get back next week.

@WilliamDenniss
Copy link
Member

Unfortunately urn:ietf:wg:oauth:2.0:oob implies the use of WebView, as it's a redirect URI that embeds the authorization code in a HTML page which the app can then inspect. Apps being able to inspect and interact with the content of the page is one reason why AppAuth doesn't support WebView (and one reason why Google recently deprecated the use of OAuth in WebView).

Until this Authorization Server supports custom URI schemes, as a workaround you can potentially redirect to a page on your website, which can then 302 Redirect to your custom scheme. Iain has a demo of this workaround.

@ricalo
Copy link
Author

ricalo commented Aug 28, 2016

I don't see how the URI urn:ietf:wg:oauth:2.0:oob implies the use of WebView. I'm familiar with the Google post that you mention, but I don't see how that applies here.

Developers just have to declare the scheme in their app manifest, just as you describe in your ReadMe:

<intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <data android:scheme="urn"/>
</intent-filter>

No WebView required.

I successfully ran a small POC in my fork with the sample provided in this repo.

Am I missing something?

@WilliamDenniss
Copy link
Member

So is this Authorization Server passing the authorization code as a param on the oob URI? That's a little different how Google treats the same (deprecated) oob redirect where the authorization code is part of the HTML page (and requires extraction). So perhaps in this case oob doesn't require WebView but it was certainly was still designed for WebView.

oob isn't well suited to browser-based OAuth, there's a better and more standard way to do this which is custom URI schemes & claimed-HTTPS redirects. One issue I see with your implementation is that you've claimed urn globally which means that your app will be competing with all apps that use this redirect choice to get the return intent (as a side point, can you at least claim only urn:ietf:wg:oauth:2.0:oob so you're not getting non-OAuth related intents as well?). It may work OK in Chrome Custom Tab which preferences the app that launched it for the redirect intent, but if the request was launched in a different browser, then all apps claiming this scheme would compete for the authorization response's redirect intent which would confuse the user (at best).

Since supporting the older WebView OAuth patterns is a non-goal for AppAuth, I don't see us supporting this redirect option in the main repo.

@ricalo
Copy link
Author

ricalo commented Aug 29, 2016

Yes, the authorization code is passed as a param on oob.

Thanks for the feedback on the POC. I'd definitely use a specific path along with the urn scheme in production code.

Not supporting old patterns sounds reasonable. I appreciate the explanation and will look for alternatives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants