Announcement Announcement Module
No announcement yet.
Suggestion.. please make callbackUrl() protected Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggestion.. please make callbackUrl() protected

    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 access to

    private String callbackUrl(String providerId) {
    return baseCallbackUrl + "/" + providerId;

    as protected so we could return something like
    super.callbackUrl() + "/" + ourInternalAccountId

    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}/{accountId} 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 {accountId} aka userProfileId 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.