Announcement Announcement Module
Collapse
No announcement yet.
Use spring-social facebook in stateless mode? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Use spring-social facebook in stateless mode?

    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.

  • #2
    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

    Comment


    • #3
      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.

      Comment


      • #4
        @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...

        Comment


        • #5
          Hi,

          You can do this by always adding the connection to the underlying database, even if the user has not registered with your site yet. Simply assign a user id to the new user and pass that user id back to the web browser.

          If the user creates his account immediately afterwards (passing the user id you gave him) everything is a-ok. If the user does not create an account after all, you have a user connection in your database corresponding to an unregistered user. But so what? If the user tries to sign up again, you simply detect that there is a user connection but no local user and you redirect the user to the sign up form (just like you do the first time).

          In my opinion this is the way that Spring Social should work by default. Http sessions suck.

          Comment


          • #6
            There has been some movement on this issue here: https://jira.spring.io/browse/SOCIAL-314

            Comment

            Working...
            X