Announcement Announcement Module
Collapse
No announcement yet.
PostToWallAfterConnectInterceptor not working for sign up as facebook Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • PostToWallAfterConnectInterceptor not working for sign up as facebook

    Hi

    I am using spring social and its great (thanks Craig). I would like my users to be able to post to their wall when they initially register with Facebook. I noticed that the 'post to wall' feature works when you register locally then connect to facebook. However it doesn't work if you try to sign up using facebook and register locally afterwords. The connect interceptor is not called.

    After debugging I see that in the latter case the following method is not invoked.

    Code:
    	public void postConnect(Connection<Facebook> connection, WebRequest request) {
    I have verified this in the spring social showcase by making the following modification to signin.jsp

    Code:
    	<!-- FACEBOOK SIGNIN -->
    	<form name="fb_signin" id="fb_signin" action="<c:url value="/signin/facebook"/>" method="POST">
            <input type="hidden" name="scope" value="publish_stream,user_photos,offline_access" />
            <label for="postToWall"><input id="postToWall" type="checkbox" checked name="postToWall" />&nbsp;Post to wall</label>
    		<button type="submit"><img src="<c:url value="/resources/social/facebook/sign-in-with-facebook.png"/>" /></button>
    	</form>
    Is there a workaround or is this by design?? I really need to get this working as I have a big launch campaign coming up.

  • #2
    Are you using ProviderSignInController for the /signin/facebook piece or are you using the new (and still a work in progress) SocialAuthenticationFilter? Not that it matters a lot in my answer, but it would be helpful to know for future improvements to the framework.

    Either way, the answer is no...that is not directly supported. ConnectController supports it via connection interceptors, but those aren't available in ProviderSignInController nor when using SocialAuthenticationFilter.

    There is an open issue to add interceptor support to ProviderSignInController and I believe that you've given me one of the best reasons to do that. But it won't be available right away...perhaps in the next milestone release. Of course, you've also prompted me to consider this use-case in the context of SocialAuthenticationFilter.

    Even though it's not directly supported, you *could* configure ProviderSignInController's postSignInUrl property to land on another controller whose job is to post the message and then redirect wherever you want it to go after signin. It's a bit more hackish than with the interceptors, but it should work.

    Comment


    • #3
      Thanks for the quick response. I am using the ProviderSignInController. What does the SocialAuthenticationFilter provide?

      I would rather not have users adding and removing social accounts a lot. I would like the entry point to be a facebook auth which posts to the user's wall after local registration. I want to post a message like "I am using springsource.org".

      So perhaps ProvidorSigninController is not the right place, because if the local registration fails it would be premature to post on their wall. It might be better to do it in SignUpController (in the Spring Social Showcase). How would I go about doing this?

      Comment


      • #4
        FWIW, I pushed some code in late yesterday that adds interceptor support to ProviderSignInController. But, to be perfectly clear, it *only* handles events taking place during PSIC's flow. Once PSIC realizes that there is no connection to be made and transfers control over to the app-defined registration process, there will be no calls made to the interceptor(s).

        But it sounds like your case is a post-registration scenario...which is precisely what the code I pushed does not handle. But that's okay, because you still have everything you need to complete the job without an interceptor.

        Take a look at https://github.com/SpringSource/spri...ontroller.java. Notice that in the signup() method there is a call to ProviderSignInUtils.handlePostSignUp(account.getUs ername(), request); to complete the creation of a new connection if registration was successful. But ProviderSignInUtils also has a getConnection() method that takes a request. You can call that to get the Connection and from the Connection do whatever you need.

        For example, let's support that I wanted to post a message in that example's SignupController. It might look like this (disclaimer: I'm hacking this into the forum...none of this code has been tested):

        Code:
        @RequestMapping(value="/signup", method=RequestMethod.POST)
        public String signup(@Valid SignupForm form, BindingResult formBinding, WebRequest request) {
        	if (formBinding.hasErrors()) {
        		return null;
        	}
        	Account account = createAccount(form, formBinding);
        	if (account != null) {
        		SignInUtils.signin(account.getUsername());
        		Connection<Facebook> connection = (Connection<Facebook>) ProviderSignInUtils.getConnection(request);
        		Facebook facebook = connection.getApi();
        		facebook.feedOperations().updateStatus("Hey! I signed in!");
        		ProviderSignInUtils.handlePostSignUp(account.getUsername(), request);
        		return "redirect:/";
        	}
        	return null;
        }
        The important thing is that you call getConnection() before you call handlePostSignUp(). That's because getConnection() retrieves the connection from a ProviderSignInAttempt carried in the session and handlePostSignUp() removes the ProviderSignInAttempt from session.

        Comment


        • #5
          I had it working except that I was using connection.updateStatus(message) instead of facebook.feedOperations().updateStatus("Hey! I signed in!")

          Are they equivalent?

          Comment


          • #6
            Yeah, those are equivalent. I had forgotten that Connection will call through to FeedOperations (via an adapter that you don't see). So that's even simpler!

            Comment

            Working...
            X