Announcement Announcement Module
Collapse
No announcement yet.
RestTemplate - POST request for "https://api.twitter.com/oauth/request_token" resulte Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • RestTemplate - POST request for "https://api.twitter.com/oauth/request_token" resulte

    Hi guys,
    since morning I'm struggling out to understund how to implement a SignIn capability between my webApp (Spring-MVC) and Spring-Social.
    I'm using XML configuration and it seems working good. I got troubles signIn using for exemple twitter. I show you my stack-trace prints out:

    Code:
     InvocableHandlerMethod - Invoking [signIn] method with arguments [twitter, ServletWebRequest: uri=/SitiPreventivi/signin/twitter;client=127.0.0.1;session=6EE8AE04F40C32C823646844BF36378B]
    2013-01-12 18:21:16,168 DEBUG [http-bio-8080-exec-7] HttpAccessor - Created POST request for "https://api.twitter.com/oauth/request_token"
    2013-01-12 18:21:16,169 DEBUG [http-bio-8080-exec-7] RestTemplate$AcceptHeaderRequestCallback - Setting request Accept header to [application/x-www-form-urlencoded, multipart/form-data]
    2013-01-12 18:21:17,317 WARN [http-bio-8080-exec-7] RestTemplate - POST request for "https://api.twitter.com/oauth/request_token" resulted in 406 (Not Acceptable); invoking error handler
    2013-01-12 18:21:17,326 DEBUG [http-bio-8080-exec-7] InvocableHandlerMethod - Method [signIn] returned [org.springframework.web.servlet.view.RedirectView: unnamed; URL [/signin?error=provider]]
    2013-01-12 18:21:17,326 DEBUG [http-bio-8080-exec-7] DispatcherServlet - Rendering view [org.springframework.web.servlet.view.RedirectView: unnamed; URL [/signin?error=provider]] in DispatcherServlet with name 'SitiPreventivi Servlet'
    2013-01-12 18:21:17,326 DEBUG [http-bio-8080-exec-7] AbstractView - Rendering view with name 'null' with model {} and static attributes {}
    I show you just the relevant part about my problem.
    As you can see the post request to the correct url is made, but I get a 406 error which I cannot explain.
    Is there a way to work the problem out?

    Thanks in advance.

    Claudio

  • #2
    Make sure your "Callback URL" setting in dev.twitter.com is set like "http://127.0.0.1:8080/SitiPreventivi/signin/twitter".

    HTH

    Comment


    • #3
      Thanks, it works, but not as we expected.
      After clicking on "Authorize App" I get redirected to signup page and not my webapp one.
      What's wrong now?

      Comment


      • #4
        Originally posted by brunifrancesco View Post
        Thanks, it works, but not as we expected.
        After clicking on "Authorize App" I get redirected to signup page and not my webapp one.
        What's wrong now?
        Remember, if user is using Twitter to sign in your app, and there is no account in your app for him/her yet, the Spring Social Connect Framework will redirect to signup page, by default it is "/signup", and you can change it in ProviderSignInController.

        If you want to do automatic signup, you have to plug your own ConnectionSignup bean into JdbcUsersConnectionRepository.

        Comment


        • #5
          It appears that you're using the new Spring Security integration stuff...is that right? Or are you using ProviderSignInController?

          Either way, in the common case the signin-with-{provider} functionality only works if there's already an existing connection for the user between your app and the provider. If there is, it should return back to your app with the user signed in. If not, it will redirect to the signup page so that the user can create a new account (or attempt to signin through other means). Essentially what's happening is that the user signs in via Facebook (for example) and Spring Social cannot find a local user who matches the Facebook user...that is, there's no existing connection. So, since it can't recognize the Facebook user it assumes that it's a new user and takes them to the signup page.

          There is another way of using it where the signup is implicit. In that case, the local app may not even maintain a user database and instead the Facebook (or Twitter) user data is used as the user data for the local app. Essentially, the provider acts as the app's user database. This is how the spring-social-quickstart app works (using ProviderSignInController), although it may not be readily apparent that is what is going on. Once the dust has settled on a few big items I'm working on for Spring Social, I hope to find some time to create a few more samples to highlight various cases like this.

          Comment


          • #6
            Thank you both.
            Just now I understood how Spring Social SignIn capabilities works!
            Thank you so much

            Comment

            Working...
            X