Callbacks and multihomed hosts

[-alex-]

First of all I'd like to say that Spring Social is a nice project indeed

However, it seems that using it on a host servicing multiple domains with the same app is not as straightforward as it could be. At least when you are using ProviderSignInController and ConnectController. The reason is - callbackUrl which you can't change to match your site. When creating a bean, you have to supply an applicationUrl as an argument to the constructor. That applicationUrl is then used to form a callbackUrl. The problem is that:

a) You can't specify a relative URL - it should be absolute or you will not be redirected back by the remote party (say twitter).

b) You can't override callbackUrl method which is declared private (well, not in easy way at least)

So let's take for example siteA.com and siteB.com, which are both serviced by your application. If you start your sign in process on siteA.com by POSt'ing to /signin/twitter and your applicationUrl is set to http://siteA.com/..., it will work fine. If you try to start the same sign in process on siteB.com, then after you bounce back to your callbackUrl (which is http://siteA.com/...) you may see something like this:

java.lang.NullPointerException
org.springframework.social.oauth1.AuthorizedReques tToken.getValue(AuthorizedRequestToken.java:44)

It would be nice to actually support relative URLs and form callback URLs in a way that current domain and protocol are taken in account. Making "callbackUrl" protected instead of private would be helpful too.

I have attached two patch files for ProviderSignInController and ConnectController in M3 which should resolve the issue. The idea is that you can still use absolute applicationUrl, but if you use relative URL instead, then callback URL will be automatically prefixed with the current protocol/host/port. And callbackUrl method could be overridden as well if needed. I hope you could include this or similar implementation in your next release.

Regards,

Alexander.

[habuma]

This sounds like a nice change for us to consider. I see your point regarding hosting your site on multiple domains and can see how your patch would fix that.

One thing I wonder about, though, is how well this would work with some providers (OAuth 2-based providers, specifically) where the callback URI is verified against the registered application. The latest draft of the OAuth 2 spec says "The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path. If a redirection URI was registered, the authorization server MUST compare any redirection URI received at the authorization endpoint with the registered URI." Gowalla, for example, requires that you preregister the callback URL. Facebook allows for subdomains, but requires that the callback match the main domain. In contrast, Twitter allows you to register multiple domains, specifically for the case you have.

Nevertheless, it's a good thing to consider for Spring Social. May I suggest that you submit a pull request in GitHub for this change? If you're unsure of how to do this, there are instructions at https://github.com/SpringSource/spri...-Spring-Social to help.

[-alex-]

I have submitted a pull request now. As for those more restrictive providers, I wonder how the check for the host is done actually - if it is not just FQDN blindly matched as a string but hostname is resolved and then verified as IP, then it might still work. I guess I will look into that when the time allows