Handle Custom Schemes in callback URLs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a consumer with a callback url that uses something other than http or 
https (e.g. android-app:///)
2. Try to perform the OAuth protocol using the above registered consumer.

What is the expected output? What do you see instead?
Expect to see the user redirected to android-app:///, but instead errors are 
thrown since parse_url() doesn't handle custom schemes.

What version of the product are you using? On what operating system?
Revision 136 on Linux with PHP 5.3

Please provide any additional information below.
This sort of setup is going to become more common as things like iPhone and 
Android apps allow the developer to use these custom URL schemes to run their 
applications. For example, I create my application to handle android-app:/// 
and the browser redirects after allowing and my application launches and gets 
the token. This provides a more seamless experience to the end-user.

Original issue reported on code.google.com by tommo...@gmail.com on 12 Jul 2010 at 4:25

[GoogleCodeExporter]

hm, i think /// for anything other then file is not valid?! parse_url should 
work for "android-app://"? (2x "/")

Original comment by fiedler....@gmail.com on 12 Jul 2010 at 4:58

[GoogleCodeExporter]

Three slashes are only valid for the file-uri-sheme:

http://en.wikipedia.org/wiki/File_URI_scheme

More about uri-shemes:

http://en.wikipedia.org/wiki/URI_scheme

greetings,
André

Original comment by fiedler....@gmail.com on 12 Jul 2010 at 5:02

• Changed state: Invalid

[GoogleCodeExporter]

When I try the following, the warning below is what happens.
<?php
$url = 'android-app://?oauth_token=abc123';
print_r(parse_url($url));
?>

Warning: parse_url(android-app://?oauth_token=abc123): Unable to parse URL in 
/Users/tmmoyer/src/playground/parse.php on line 3

The other issue is that OAuthRequest.php's redirect() function checks for 
http:// and https:// and if it finds neither, it checks for :// and throws an 
exception.

Original comment by tommo...@gmail.com on 12 Jul 2010 at 5:04

[GoogleCodeExporter]

ok, last thing is a bug. :o)

I don´t think that 'android-app://?oauth_token=abc123' is a valid uri? Havn´t 
time to deeply look at this yet. 

greetings,
André

Original comment by fiedler....@gmail.com on 12 Jul 2010 at 5:07

• Changed state: Accepted

[GoogleCodeExporter]

One of my tasks this week was to get an android app calling into the server so 
will also let you know what i come up with

Original comment by pyhubltd on 12 Jul 2010 at 5:49

[GoogleCodeExporter]

@tommoyer android-app://?oauth_token=abc123 is invalid you would need a 
"hostname" android-app://callback?oauth_token=abc123 for it to be valid.

As with the callback problems the problems seem to be coming from 
oAuthRequest.php lines 784 > 793 commenting those out should allow you to use 
callbacks not in the form of http and https.

Original comment by pyhubltd on 12 Jul 2010 at 6:06

[GoogleCodeExporter]

That´s great. Btw. if you need svn write access, send a message to bruno (the 
project owner)! ;o)

Original comment by fiedler....@gmail.com on 12 Jul 2010 at 6:19

[GoogleCodeExporter]

Hey, that's me. But you people seem to have already solved the problem :)

oauth-php checks for http/https apparently for security. It makes some sense to 
avoid "file://", but clearly support for other protocols should be there. Lines 
784-793 are the only ones that need change, yeah.

I'm trying to devise a way to allow other protocols in the API... I think 
something in $params is the only clean choice. Any suggestions?

Original comment by brunobg%...@gtempaccount.com on 12 Jul 2010 at 8:17

[GoogleCodeExporter]

Well android lets you set custom url handlers and this is what most people are 
using to receive the oAuth callback to avoid oob. I can set my android app to 
handle X:// or blah:// in fact anything-i-like:// and receive the oAuth 
callback direct to the app, parse the result etc.

What we could do is have some form of config flag that enforces the callback 
url to be that which is specified in the oauth_server_registry table (this may 
already be possible *shrug*) otherwise disallow any potentially harmful 
callback formats. 

But then if the oauth provider or consumer is really being malicious what are 
we allowing them access right ;)

Original comment by pyhubltd on 12 Jul 2010 at 8:37

[GoogleCodeExporter]

Yes, for default the OAuth Server Library should work for all schemes. But a 
configuration parameter to allowed/disallowed some schemes would be nice.
Excessive security should be the option and flexibility the standard. ;o) OAuth 
2.0 tries this too.

Original comment by fiedler....@gmail.com on 12 Jul 2010 at 9:45

[GoogleCodeExporter]

So I got a bit bored and had a look at this, attached is diff with some changes 
to oAuthServer.php

I have added an options array to the constructor and at the moment it looks for 
and parses allowed_uri_schemes and disallowed_uri_schemes

e.g. Allow only http and https
$options = array(
    'authorised_uri_schemes' => array('http', 'https'),
    'disallowed_uri_schemes' => array()
);

e.g. Disallow callto, mailto and file
$options = array(
    'authorised_uri_schemes' => array(),
    'disallowed_uri_schemes' => array('callto', 'mailto', 'file')
);

e.g. Allow everything
$options = array(
    'authorised_uri_schemes' => array(),
    'disallowed_uri_schemes' => array()
);

default: same as current config allow only http and https

To create the server object:
$server = new OAuthServer($uri = null, $method = null, $params = null, $store, 
$store_options, $options);

Something like that anyway.

Original comment by pyhubltd on 13 Jul 2010 at 1:38

Attachments:

• oAuthServer.diff

[GoogleCodeExporter]

duhhhh thats allowed_uri_schemes, not authorized_uri_schemes as i put in the 
examples.

Original comment by pyhubltd on 13 Jul 2010 at 1:39

[GoogleCodeExporter]

Patched and commited to r137. Thanks!

Original comment by brunobg%...@gtempaccount.com on 15 Jul 2010 at 3:25

• Changed state: Fixed