ProviderSignInController - preserve GET params

[balazsnemeth]

hey,

I have a web page and its URL looks like this:

https://mypage.com/login.htm?m=130&task=mytask&skin=myskin

And that's where I put my facebook-signin button:

	<form action="<c:url value="/social/signin/facebook" />" method="POST">
	    <button type="submit">Sign in with Facebook</button>
	    <input type="hidden" name="scope" value="email,publish_stream,offline_access" />		    
	</form>

What I'd like to do is to keep those parameters my page was called with, pass them to the spring social controller and when it's done and calls SignInAdapter.signIn() I can redirect the flow to

https://mypage.com/finishedwithsigningin.htm?m=130&task=mytask&skin=myskin

Could someone please tell me how to achieve this?

Thanks for your answer in advance!

Cheers,
b

[habuma]

I'd have to think about it some more, but I don't think that it's currently possible to do exactly what you want to do. Some enhancements that are coming up might make this possible, though...specifically, you might be able to do this with an interceptor (somewhat akin to how connection interceptors work with ConnectController). I'll keep this particular case in mind when I do that work and will (within reason) try to make it work.

But, I *think* your ultimate goal here is to send the user to some URL that requires authentication and, after authenticating them, send them to that same URL (parameters and all). If that's the case, and if you're using Spring Security, then Spring Security handles much of what you want already when it stores the original request in the request cache. All you need to do in your sign in adapter is extract the request from the request cache and use it. Spring Social Showcase does this in its SimpleSignInAdapter (https://github.com/SpringSource/spri...InAdapter.java).

If you're not using Spring Security, then you may want to do something like what Spring Security does and stow the original request somewhere (in the session) and then pull it out in the sign in adapter...or consider using Spring Security.

[balazsnemeth]

Thanks for your answer.

My first idea was to use the session of course but you don't want to do that manually :S That's why I thought there has to be something that helps me. I did not want to implement something that's already there, obviously

Unfortunately Spring Security is not an option for me right now but I'll try to implement it in a similar fashion.

Also your idea with the interceptor made me laugh a bit because that was my other suggestion as we discussed this today with one of my colleagues and he's not a big fan of them as he thinks sometimes they act in a too transparent way and our approach is "to keep it as simple as possible".