Spring Social
  1. Spring Social
  2. SOCIAL-255

Support interceptors in ProviderSignInController flow

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 1.0.0.RELEASE
    • Fix Version/s: 1.1.0.M2
    • Component/s: Connection Web
    • Labels:
      None

      Description

      ProviderSignInController should have interceptors just like ConnectController has.

        Activity

        Hide
        Keith Donald added a comment -

        You're going to need to provide more information on why you need this capability, or preferably, implement it yourself and contribute it back so it can be integrated. It's trickier to implement interceptor functionality since no user has yet authenticated at the time of the preConnect event.

        Show
        Keith Donald added a comment - You're going to need to provide more information on why you need this capability, or preferably, implement it yourself and contribute it back so it can be integrated. It's trickier to implement interceptor functionality since no user has yet authenticated at the time of the preConnect event.
        Hide
        joshefin added a comment -

        I would use the interceptor to set the scope and display parameters for Facebook sign in, instead of specifying them like hidden fields on the page.

        Show
        joshefin added a comment - I would use the interceptor to set the scope and display parameters for Facebook sign in, instead of specifying them like hidden fields on the page.
        Hide
        Mehmet Elicin added a comment -

        I agree. I ran into this problem when I tried to implement the pop-up version of the sign-in flow. The pop-up sample in github works perfectly fine for the "connect" flow because it injects "display: popup" additional parameter using the interceptor framework. However, ProviderSignInController does not support interceptors so we are not able to implement the sign-in flow in a popup as we are in the connect flow.

        Btw, adding the display parameter as hidden form field also doesn't work because the spring-social library deliberately only extracts the "scope" parameter from the form and ignore everything else.

        Show
        Mehmet Elicin added a comment - I agree. I ran into this problem when I tried to implement the pop-up version of the sign-in flow. The pop-up sample in github works perfectly fine for the "connect" flow because it injects "display: popup" additional parameter using the interceptor framework. However, ProviderSignInController does not support interceptors so we are not able to implement the sign-in flow in a popup as we are in the connect flow. Btw, adding the display parameter as hidden form field also doesn't work because the spring-social library deliberately only extracts the "scope" parameter from the form and ignore everything else.
        Hide
        Luc Pezet added a comment -

        I'd like interceptors too for ProviderSignInController to handle redirects post sign in. I would pass an extra parameter (preConnect) so that the callback URL contains a redirect URL I would use post sign in to redirect to. In the end, this sign in process would behave the same way Spring Security does (i.e. redirecting to the content that required authentication).

        Show
        Luc Pezet added a comment - I'd like interceptors too for ProviderSignInController to handle redirects post sign in. I would pass an extra parameter (preConnect) so that the callback URL contains a redirect URL I would use post sign in to redirect to. In the end, this sign in process would behave the same way Spring Security does (i.e. redirecting to the content that required authentication).
        Hide
        Gerrit Hübbers added a comment -

        Maybe a SignInAdapter implementation that gets passed to ProviderSignInController's constructor already fulfills your requirements.
        SignInAdapter.signIn(...) gets called by ProviderSignInController after a successful sign-in. This mimicks the behavior of ConnectInterceptor.postConnect(...) which gets called by ConnectController.postConnect(...) after a successful "connect-up".

        I successfully used this strategy to do some Facebook-user-specific computations whenever that user signs in into my application.

        Show
        Gerrit Hübbers added a comment - Maybe a SignInAdapter implementation that gets passed to ProviderSignInController's constructor already fulfills your requirements. SignInAdapter.signIn(...) gets called by ProviderSignInController after a successful sign-in. This mimicks the behavior of ConnectInterceptor.postConnect(...) which gets called by ConnectController.postConnect(...) after a successful "connect-up". I successfully used this strategy to do some Facebook-user-specific computations whenever that user signs in into my application.
        Hide
        Craig Walls added a comment -

        In an effort to re-establish momentum with Spring Social releases, I've pushed this issue out to 1.1.0.M2. I agree that it's important, but want to be sure that I fully understand and consider the desired use-cases before just pushing it in.

        Show
        Craig Walls added a comment - In an effort to re-establish momentum with Spring Social releases, I've pushed this issue out to 1.1.0.M2. I agree that it's important, but want to be sure that I fully understand and consider the desired use-cases before just pushing it in.
        Hide
        Gerrit Hübbers added a comment -

        Here is one use case:

        Whenever a user of my websites signs in using Facebook, I want to update that user's account in my website's database.
        Provided that my website has offline_access permissions, my website could do this anytime. But with a ProviderSignInController.postSignIn(...) hook, my website can do this right at the moment when fresh data is actually required (i.e., when the user comes back to my website after a long time).

        Show
        Gerrit Hübbers added a comment - Here is one use case: Whenever a user of my websites signs in using Facebook, I want to update that user's account in my website's database. Provided that my website has offline_access permissions, my website could do this anytime. But with a ProviderSignInController.postSignIn(...) hook, my website can do this right at the moment when fresh data is actually required (i.e., when the user comes back to my website after a long time).
        Hide
        Craig Walls added a comment -

        This is reasonably simple to support in the ProviderSignInConroller flow (e.g., pre-signin, post-signin). Where it gets tricky is in the case where no matching connections are found and the flow turns from being a sign-in flow to a sign-up flow. At that point, ProviderSignInController hands things off to an application-defined signup page along with a ProviderSignInAttempt to complete a connection after the signup is performed.

        In that case, it's completely up to the application to handle the signin after signup and to handle the post-signup connection (via SignInAttempt).

        One option is to pass the list of interceptors along with the ProviderSignInAttempt. But this creates a potentially nasty situation carrying a list of interceptors around in a session attribute. I'm not particularly fond of this option.

        The other option is for the interceptors to only participate in the ProviderSignInController flow and leave any post-signup behavior in the purview of the application's own post-signup code. I favor this approach as it's cleaner from a Spring Social perspective. But I also favorite it because there's no reason to pass around some interceptor in session so that application code can call it after signup when the application code can just implement that post-signup code on its own...the ProviderSignInAttempt object has everything it needs to do post-signup logic with a connection.

        For now I've addressed the interceptor issue within the scope of ProviderSignInController's signin flow with a new ProviderSignInInterceptor that includes preSignIn() and postSignIn() methods.

        With that, I will now mark this issue as resolved. If there's a need for additional interceptor events to be handled in ProviderSignInInterceptor, I ask that you open a new improvement issue to address the specific interception case you have in mind.

        Show
        Craig Walls added a comment - This is reasonably simple to support in the ProviderSignInConroller flow (e.g., pre-signin, post-signin). Where it gets tricky is in the case where no matching connections are found and the flow turns from being a sign-in flow to a sign-up flow. At that point, ProviderSignInController hands things off to an application-defined signup page along with a ProviderSignInAttempt to complete a connection after the signup is performed. In that case, it's completely up to the application to handle the signin after signup and to handle the post-signup connection (via SignInAttempt). One option is to pass the list of interceptors along with the ProviderSignInAttempt. But this creates a potentially nasty situation carrying a list of interceptors around in a session attribute. I'm not particularly fond of this option. The other option is for the interceptors to only participate in the ProviderSignInController flow and leave any post-signup behavior in the purview of the application's own post-signup code. I favor this approach as it's cleaner from a Spring Social perspective. But I also favorite it because there's no reason to pass around some interceptor in session so that application code can call it after signup when the application code can just implement that post-signup code on its own...the ProviderSignInAttempt object has everything it needs to do post-signup logic with a connection. For now I've addressed the interceptor issue within the scope of ProviderSignInController's signin flow with a new ProviderSignInInterceptor that includes preSignIn() and postSignIn() methods. With that, I will now mark this issue as resolved. If there's a need for additional interceptor events to be handled in ProviderSignInInterceptor, I ask that you open a new improvement issue to address the specific interception case you have in mind.

          People

          • Assignee:
            Craig Walls
            Reporter:
            joshefin
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: