Use spring-social facebook in stateless mode?

[sappenin]

Is it possible to run spring-social-facebook in stateless mode (i.e., with sessions disabled)? Currently, when trying to do Facebook login, a bunch of data gets stuffed into the session inside of ProviderSignInController. However, I would like to operate a stateless app, and am wondering if this can be done.

[yonimoses]

Hi,

you can still use the controller and destroy the session after the callback.
since sessions are opened anyhow (unless you explicitly denied it) it will not affect your *stateless* mode.
Another approach I can think of is using cookies (but again, session cookie is the same).. store the value in the cookie and expire it after the return from FB.


HTH,
Yoni

[habuma]

For the most part, Spring Social does *not* use sessions. It does create request-scoped beans on occasion, but since those are request-scoped, they are effectively stateless (that is, they don't survive the current request).

But ProviderSignInController and ConnectController may put a few things in the session. For OAuth 1, the request token may be kept in session. And for ProviderSignInController, when the authentication has failed, a pending connection will be kept in session so that the app can create a session after the user has registered with the site.

I suppose that in the latter case, there could be a setting that disables that--effectively saying that you have no intention of creating a connection after registration. I could consider making that work. If that would be useful for you, may I suggest that you create an improvement issue in JIRA for this and I'll consider it.

In the former case, I know of no way to reliably carry the request token without putting it *somewhere*. It can't be carried as parameters in the request for many reasons (security being one of them, the likelihood that the provider would drop it in the redirect being another). If I don't put it in session, I could place it in a key-value store like Redis...but that would still be server-side state carried between requests, no different than session.

[sappenin]

@habuma: Thanks for your response. I'm getting tripped up by ProviderSignInController#handleSignIn, line 197 (using oauth2) -- I think this is similar to your "former case".

From what I can tell, the important information being stored into the session in this case is the ConnectionData object, in particular the access token.

What about storing some serialization of ConnectionData into a Secure (possibly persistent) cookie? This would present some challenges for apps that don't run SSL, but seems like it might work for those that do and want to be stateless.

On your "latter case" idea, couldn't the information found in my secure Cookie idea be used to connect the user after a Registration attempt?

Thanks for your thoughts here...