Allow alternate callback ports on localhost

[idpaterson]

A common use case for end-user authentication in apps is establishing a single-request web server to receive the authentication token from the Wunderlist API authorization. For example, a developer might have the server listen on port 6200 providing a callback URL such as http://localhost:6200 in the Wunderlist config. This may not be possible on every platform, but where it is possible, it is an extremely convenient way to access the token after authentication.

However, it is impossible to guarantee that a specific predetermined port number will be available on all end-user machines. For example, if another application is already listening on port 6200, the developer may advance the port number to 6201, 6300, 7200, etc. until an open port is discovered. Currently this is of no use with the Wunderlist API since the callback hostname and port must match exactly.

It would be excellent to be able to specify http://localhost as the callback in the API and then respond with the actual callback url specified in the request provided that it is localhost or some port on localhost. This would maintain the ability to keep the token delivery directly between Wunderlist and the end-user machine while supporting cases where the default port is in use.

Dynamic ports in OAuth callbacks are not unprecedented; the Google OAuth 2.0 API has a special provision for localhost allowing any port.

Workaround

It would be possible to set up a public static URL to receive the token in the callback and then in turn make a request to localhost (CORS, JSONP script tag, img tag, or some other means that would allow notification of success/failure without browser security issues). This would require a known sequence of ports that the application would attempt to open. If localhost:6200 fails, try localhost:6201.

This is certainly an inferior approach as it requires more work and injects a middleman receiving and then transmitting the token. Additionally, the services listening on those in-use ports may not be robust enough to handle the unexpected data or may even return a successful response before the algorithm hits the actual token handling server.

localhost only?

Hopefully an application server under the developer's control is capable of receiving tokens on a dedicated port. It is easily justifiable that outside of localhost (which may also be specified as a loopback IP 127.0.0.1—technically 127.0.0.0/8—on IPv4 and ::1 on IPv6), allowing any port within the given public hostname is quite dangerous.

[jgitter]

Seconded! This would be very helpful indeed.

[idpaterson]

My workaround was to allow the localhost URL to be pasted into the app via a help screen for those who cannot log in. It's ugly but enough users had encountered this problem since I originally recorded this issue that a workaround was necessary.

[jgitter]

Thanks for the insight. I was essentially planning on doing something like that if needed. "Ugly but works" is sort of the name of the game. :-)