Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3706 closed enhancement (fixed)

Allow custom URL protocols or schemes when registering a client application (for OAuth)

Reported by: mendhak Owned by: Tom Hughes
Priority: minor Milestone:
Component: website Version:
Keywords: oauth, custom, url, scheme, android, iphone Cc:


When registering an application for usage with OSM, the application registration page asks for a Callback URL. This works perfectly fine if it's a common URI scheme such as http:// as after authorizing the application, the user is redirected to that Callback URL.

With mobile/desktop apps the user will authorize the app but then has to presumably copy some text from the website and paste it into the mobile/desktop app.

However, since desktop and mobile apps can register to listen to custom URI schemes such as myapp://, it would make things easier for the user if the Callback URL did allow custom URI schemes so that the user simply authorizes, browser redirects to myapp://, application handles it and takes care of the tokens it receives.

At the moment, when specifying a Callback URL on the registration page

the Callback URL field does not allow anything other than http:// or https://

I have placed this under the 'website' component but please let me know if it should be elsewhere (or change it).

Change History (5)

comment:1 Changed 8 years ago by mendhak

I followed the instructions on the OSM wiki and made the change in a fork on github:

comment:2 Changed 8 years ago by Tom Hughes

Priority: majorminor

Your change doesn't actually seem to match what you say in the bug description though. You stated that only http and https were allowed but it looks to me like any sequence of one of more word characters (plus hyphens) was allowed as the scheme name?

All your change really seems to have done is to add restrictions (like requiring the scheme name to start with an alphabetic character) and possibly allow a few extra characters like the plus sign and full stop.

Can you explain more clearly exactly what the problem you encountered was (perhaps if you said what scheme name didn't work that would help explain) and why your change fixes it, as well as why the extra restrictions you have introduced are necessary?

comment:3 Changed 8 years ago by mendhak

Hi TomH, I'm sorry for the confusion - The link I pasted above is showing a diff of a previous change I made (I did two versions of the fix). In the original regex, only http and https are allows like so:

validates_format_of :callback_url, :with => /\Ahttp(s?):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?/i, :allow_blank=>true

The first change I made changed it to allow words and hyphens

validates_format_of :callback_url, :with => /\A([\w\-])+:\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?/i, :allow_blank=>true

The second change is a bit more detailed because I was reading up on the RFC 3986

validates_format_of :callback_url, :with => /\A([a-z]){1}([\w0-9\.\+\-])*:\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?/i, :allow_blank=>true

I didn't know which you would have preferred which is why I did it twice.

To explain the problem more clearly - in a third party website, a user will click 'authorize' which will redirect to the website.

Then, the user will sign in and grant permissions to the third party website. At this point, normally, the website will redirect the user back to the callback url that had originally been specified. This callback url would have been specified by the author of the third party website. (

Currently, the callback url is being restricted to http:// and https:// addresses which doesn't work for mobile apps. This means that mobile app users will need to copy the code given to them by and paste that into the mobile app. What would be nice is if anything:// is allowed.

The reason - on a smartphone, the mobile browser will attempt to redirect the user to anything:// and this will in turn invoke the original mobile app which has registered itself to listen to anything://. As far as I know, Android OS and iOS currently allow applications to register against custom schemes.

The anything:// URL would contain the OAuth tokens it needs to communicate with which it can process and use. This provides the user with a seamless experience.

Hope I'm clear, please let me know if my description is still lacking.

comment:4 Changed 8 years ago by Tom Hughes

Resolution: fixed
Status: newclosed

Applied and deployed. Thanks for the patch.

comment:5 in reply to:  4 Changed 8 years ago by mendhak

Replying to TomH:

Applied and deployed. Thanks for the patch.

Hi TomH, thanks for applying this and for your time, it is appreciated. Just did an end-to-end test of my mobile app and the OAuth process is very smooth.

Note: See TracTickets for help on using tickets.