OpenID should support non-action realms and return-to URLs

[AMcBain]

The OpenID implementation in Play! has the methods forRealm and returnTo which change the realm and the return URL given to the OpenID provider. They currently take a String that is a representation of an action (method on a Controller), which is looked up in the Router for a route that will point to that action. It would be extremely handy if a string, starting with http:// could be used instead which skips the look-up in the Router.

This would allow applications that run on servers which have more than one hostname resolving to them to specify one particular realm or allow Play! instances that are proxied to determine their outside realm and send that out instead (as the Play framework itself won't be able to tell it is proxied, but the app may be built with being proxied in mind).

Just a thought ... I'll see if I can work up a very simple patch (check string for startsWith("http://")) and attempt to run it, but no guarantees.

Technically, if OpenID was used and nobody bothered to test it, this could reveal that a particular Play! app was being proxied. It would reveal the IP address on the other side of the proxy and the port number. Not really a vulnerability of Play! but something of which developers should be aware!

[AMcBain (mcbain-asm)]

Another usage for this patch is if an app wants to have a login on one URL but have it handled by another on a different domain, for example. The returnTo and forRealm actions would have to be URLs for the destination.

Obviously this patch is very simplistic, given that not all URLs accessible by the internet start with http://, but I think for OpenID, only http://-reachable locations would be handling the results.

I tried to keep the apparent code formatting in the OpenID.java file, but some spacing may be needed before, after and between the if statements. Anyone wishing to try this patch can easily do so by making the indicated changes and compiling OpenID.java against play.jar then taking the two generated classfiles and replacing those in the Play! jar.

[AMcBain (mcbain-asm)]

The patch was generated by WinMerge, so sorry if it's not the right format (launchpad already complained at me), but the patch is small and simple enough to understand anyway.

[AMcBain (mcbain-asm)]

Not being able to edit your own comments suck. I believe my previous statement of

 "Another usage for this patch is if an app wants to have a login on one URL but have it handled by another on a different domain, for example."

is actually against the OpenID spec.* The real way to do that would be to have the target of the form be the receiver page and have them handle the rest of the authentication. So the only actual use-case for this patch is dealing with Play! instances behind proxies, in which case there may be a better way to accomplish this, which tells the Play! Router that it is proxied and what the actual outside URL is, since it appears that the server acting as the proxy (in my case, Apache) can't handle everything.

* Since the realm and domain don't match, the authority provider has the right to drop the request in the possible interest of security.