Spring Social
  1. Spring Social
  2. SOCIAL-155

Evaluate reusability / flexibility of ConnectController and ProviderSignInController

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.0.RC1
    • Component/s: None
    • Labels:
      None

      Description

      Following points have been brought up:

      • I want to invoke ConnectController's logic in the context of another web framework e.g. from a javax.servlet.Filter, as part of Spring Security integration.
      • I don't have a UrlBasedViewResolver configured yet the redirect strings ConnectController returns require this (or redirects don't get interpreted)
      • I want to connect and invoke a post-connect interceptor but not persist the connection (seems limited in usefulness, but nevertheless it's been requested)

        Issue Links

          Activity

          Hide
          Keith Donald added a comment -

          Agreement to switch from Strings to RedirectViews in ConnectController.

          Show
          Keith Donald added a comment - Agreement to switch from Strings to RedirectViews in ConnectController.
          Hide
          Parwiz Rezai added a comment -

          Copying from my posting in the spring social forum:

          Hi guys,

          i was hoping to talk a little on what we are currently doing and hoping to request a few changes for ConnectController. We are extending ConnectController and using that to make oauth to facebook/twitter. We don't have a user table but another model object with an id. So upon oauth we save the accessToken/secret for using later in backend to post to user's wall. Right now we basically shove the id of this model that stores the oauth later in our table in the session
          before doing a connect() with ConnectController..
          I was hoping we could get a modified callbackUrl from this:

          private String callbackUrl(String providerId)

          { return baseCallbackUrl + "/" + providerId; }

          to something like so:
          protected String callbackUrl(String providerId, Long (can be serializable or string if desired) internalAccountId)

          { return baseCallbackUrl + "/" + providerId + "/" + internalAccountId; }

          and in our oauth1Callback and oauth2Callback
          have it wired like so

          @RequestMapping(value = "/

          {providerId}/{internalAccountId}", method = RequestMethod.GET, params = "oauth_token")

          and update the ConnectController oauth1Callback/oauth2Callback to taken this extra param as well.

          This will remove the need to "remember" or store our internal account id in session and later on callback retrieve it again and go save the accessToken.
          It is cleaner and more in line with the rest api as far as saving/updating/fetching a single item by using an underlying id.... yes i know we are using the provider id but with the provider id we would like to give the user the ability to create multiple accounts with facebook oauth tokens and each account has its own id. but the callback is always straigh to {providerId}

          . I think it makes more sense to have the callback to

          {providerId}

          /

          {internalAccountId} so there won't be a need to store the account id in session before calling oauth to facebook/twitter and coming back and using it again. Also maybe connectin repository can also have access to {internalAccountId}

          from this callback instead of having to dig it out from somewhere else.

          So please take a look as I believe ConnectController is very valuable and i'm sure users will provide their own front end/account creation and are more interested in the callback and storage of the accessTokens for perhaps offline access later.

          we can wire in this internalAccountId directly into connection repository at this line as well
          getConnectionRepository(internalAccountId).addConnection(connection);
          which would allow it to go get our connectionreporisotry connected to this or perhaps inject internalaccountId into Connection so it's there for access.

          Show
          Parwiz Rezai added a comment - Copying from my posting in the spring social forum: Hi guys, i was hoping to talk a little on what we are currently doing and hoping to request a few changes for ConnectController. We are extending ConnectController and using that to make oauth to facebook/twitter. We don't have a user table but another model object with an id. So upon oauth we save the accessToken/secret for using later in backend to post to user's wall. Right now we basically shove the id of this model that stores the oauth later in our table in the session before doing a connect() with ConnectController.. I was hoping we could get a modified callbackUrl from this: private String callbackUrl(String providerId) { return baseCallbackUrl + "/" + providerId; } to something like so: protected String callbackUrl(String providerId, Long (can be serializable or string if desired) internalAccountId) { return baseCallbackUrl + "/" + providerId + "/" + internalAccountId; } and in our oauth1Callback and oauth2Callback have it wired like so @RequestMapping(value = "/ {providerId}/{internalAccountId}", method = RequestMethod.GET, params = "oauth_token") and update the ConnectController oauth1Callback/oauth2Callback to taken this extra param as well. This will remove the need to "remember" or store our internal account id in session and later on callback retrieve it again and go save the accessToken. It is cleaner and more in line with the rest api as far as saving/updating/fetching a single item by using an underlying id.... yes i know we are using the provider id but with the provider id we would like to give the user the ability to create multiple accounts with facebook oauth tokens and each account has its own id. but the callback is always straigh to {providerId} . I think it makes more sense to have the callback to {providerId} / {internalAccountId} so there won't be a need to store the account id in session before calling oauth to facebook/twitter and coming back and using it again. Also maybe connectin repository can also have access to {internalAccountId} from this callback instead of having to dig it out from somewhere else. So please take a look as I believe ConnectController is very valuable and i'm sure users will provide their own front end/account creation and are more interested in the callback and storage of the accessTokens for perhaps offline access later. we can wire in this internalAccountId directly into connection repository at this line as well getConnectionRepository(internalAccountId).addConnection(connection); which would allow it to go get our connectionreporisotry connected to this or perhaps inject internalaccountId into Connection so it's there for access.
          Hide
          Parwiz Rezai added a comment -

          along my above suggestion please modify connect that gets called at the end to also be along the same rest api methods meaning take in internalAccountId as path variable like so

          again internalAccountId can be seriablble or string or Long or whatever you guys choose.

          @RequestMapping(value="/

          {providerId}/{accountId}", method=RequestMethod.GET)
          public String connect(@PathVariable String providerId, @PathVariable Long internalAccountId, Model model);

          @RequestMapping(value="/{providerId}

          /

          {accountId}", method=RequestMethod.POST)
          public String connect(@PathVariable String providerId, @PathVariable Long accountId, WebRequest request);


          @RequestMapping(value="/{providerId}/{accountId}

          ", method=RequestMethod.GET, params="oauth_token")
          public String oauth1Callback(@PathVariable String providerId, @PathVariable Long accountId, @RequestParam("oauth_token") String token, @RequestParam(value="oauth_verifier", required=false) String verifier, WebRequest request);

          @RequestMapping(value="/

          {providerId}

          /

          {accountId}

          ", method=RequestMethod.GET, params="code")
          public String oauth2Callback(@PathVariable String providerId, @RequestParam("code") String code, WebRequest request);

          for these two callbacks please allow connection repository to be created with this accountId directly at getConnectionRepository() call

          protected String callbackUrl(String providerId, Long accountId)

          { return baseCallbackUrl + "/" + providerId + "/" + accountId; }

          protected String baseViewPath(String providerId, Long accountId)

          { return "connect/" + providerId + "/" + accountId; }

          protected String redirectToProviderConnect(String providerId, Long accountId)

          { return "redirect:/connect/" + providerId + "/" + accountId; }

          basically here's your oauth info and the account that will save it for your backend side in one place. each call back is specific to provider (facebook, twitter etc) and specific to that accountId.. after all we will connect one account at a time to oauth so shouldn't it be specific to that one account?

          thanks.

          Show
          Parwiz Rezai added a comment - along my above suggestion please modify connect that gets called at the end to also be along the same rest api methods meaning take in internalAccountId as path variable like so again internalAccountId can be seriablble or string or Long or whatever you guys choose. @RequestMapping(value="/ {providerId}/{accountId}", method=RequestMethod.GET) public String connect(@PathVariable String providerId, @PathVariable Long internalAccountId, Model model); @RequestMapping(value="/{providerId} / {accountId}", method=RequestMethod.POST) public String connect(@PathVariable String providerId, @PathVariable Long accountId, WebRequest request); @RequestMapping(value="/{providerId}/{accountId} ", method=RequestMethod.GET, params="oauth_token") public String oauth1Callback(@PathVariable String providerId, @PathVariable Long accountId, @RequestParam("oauth_token") String token, @RequestParam(value="oauth_verifier", required=false) String verifier, WebRequest request); @RequestMapping(value="/ {providerId} / {accountId} ", method=RequestMethod.GET, params="code") public String oauth2Callback(@PathVariable String providerId, @RequestParam("code") String code, WebRequest request); for these two callbacks please allow connection repository to be created with this accountId directly at getConnectionRepository() call protected String callbackUrl(String providerId, Long accountId) { return baseCallbackUrl + "/" + providerId + "/" + accountId; } protected String baseViewPath(String providerId, Long accountId) { return "connect/" + providerId + "/" + accountId; } protected String redirectToProviderConnect(String providerId, Long accountId) { return "redirect:/connect/" + providerId + "/" + accountId; } basically here's your oauth info and the account that will save it for your backend side in one place. each call back is specific to provider (facebook, twitter etc) and specific to that accountId.. after all we will connect one account at a time to oauth so shouldn't it be specific to that one account? thanks.
          Hide
          Keith Donald added a comment -

          The suggested approach of exposing a user's local id in the connect URL does not seem very secure to me. It would be possible for one user to modify another's connections.

          Show
          Keith Donald added a comment - The suggested approach of exposing a user's local id in the connect URL does not seem very secure to me. It would be possible for one user to modify another's connections.
          Hide
          Craig Walls added a comment -

          ConnectController and ProviderSignInController have been changed to work directly with RedirectView instead of relying on "redirect:" view names. Consequently, a URL-based view resolver is no longer required.

          With that portion of this issue addressed, I'm going to close this issue. If there is any further discussion regarding how ConnectController/ProviderSignInController may be more flexible or used with other web frameworks, I recommend we discuss it further in the forum and/or open new issues to track those items individually.

          Show
          Craig Walls added a comment - ConnectController and ProviderSignInController have been changed to work directly with RedirectView instead of relying on "redirect:" view names. Consequently, a URL-based view resolver is no longer required. With that portion of this issue addressed, I'm going to close this issue. If there is any further discussion regarding how ConnectController/ProviderSignInController may be more flexible or used with other web frameworks, I recommend we discuss it further in the forum and/or open new issues to track those items individually.

            People

            • Assignee:
              Unassigned
              Reporter:
              Keith Donald
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: