This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Implementing Facebook "Like" in the presence of Implicit Sign Up with Spring SocialPage Title Module

Implementing Facebook "Like" in the presence of Implicit Sign Up with Spring Social

Nov 3rd, 2011, 04:34 AM

First up, a hearty thanks to all the Spring Social Developers !

Background:
I am developing a Spring 3.0.5 based web application which makes use of Spring Social 1.0.0 and Spring Social Facebook 1.0.0. I have successfully integrated implicit sign up (via Facebook) and now wish to implement the Facebook "Like" action.

Options (as best I see them):
So far as I can see there are two distinct ways to implement Like using Spring Social. The first leverages the Facebook JS SDK (Spring specific tags for which are available from within Spring Social) and the second would use a server side Spring API Binding to get access to the "LikeOperations" supported in the LikeOperations sub-API interface (and accessed from the client button press via AJAX I would be responsible for).

My issues:
1) The Facebook JS SDK implementation option does not appear to be compatible with an implicit sign-in implementation, as the social user connection obtained in the case where the user is not logged in is obtained independent to the "ConnectionSignup" mechanism
2) If my fundamental understanding is correct, then I presume this means that a Spring Social based Facebook implementation for Like (for my website) would require that the developer handle the implicit sign-in (with its Facebook authentication) and the "like" submission process when the user clicks an application specific "Like" button, as opposed to integration of a Like function sourced direct from Facebook as appears to be the case when I try to use the Facebook JS SDK option.

Conclusion:
So to sum up, this post is my attempt to seek out clarity on the best implementation option for the Facebook "Like" action on my web pages. I wish to confirm that using Facebook JS SDK is as "extrinsic" as it appears when compared with the Facebook API Binding in Spring Social Facebook. This would validate my expectation of needing some AJAX based integration effort to facilitate the Like button based implicit sign in and subsequent Like action submission as an integrated and seamless process for the user (so their experience is as per the JS SDK implementation for non Spring Social "Facebook" API based implementations where one click leads you seamlessly to a successful Like, regardless of your login state).

I think that *most* of what you said is correct. When going through Spring Social's connection process, an access token is received server-side, but that doesn't necessarily mean that Facebook's JavaScript API has received authorization to do whatever it wants to do (such as offer a "Like" button).

However, I don't believe it would be incredibly difficult to get authorization to the browser side code. I suspect (have not tried it, though) that upon connecting server-side, a client-side page could also attempt the same authorization via the JS API. Normally, attempting such authorization would pop up a dialog, but since the user has already authorized the app, I believe that the authorization dialog would only appear briefly (if at all) and the client-side would be ready to go. That is as long as the client-side does not ask for any additional permissions beyond what the server-side asked for.

Again, I haven't tried this (might be a fun experiment, though) so I can't promise that it will work. I'll make a point of trying that experiment soon and let you know the outcome. In the meantime, if you happen to try it out then please share the results here.

There may also be opportunity here to add a new feature to Spring Social to handle authorization mirroring between the client and the server (especially, if the experiment doesn't work). I'm not sure how this would be done, but if the client-side re-authorization experiment doesn't work or is not as seamless as you'd like, then it may be worth exploring a better approach. To track this, I've created https://jira.springsource.org/browse/SOCIALFB-40.

Comment

FWIW, it's just an initial experiment, but try out http://spring-social-quickstart.cloudfoundry.com (note that I'll keep this URL live on CloudFoundry for a few days, but may remove it once the experiment is over and springzen has seen it). That's basically the Spring Social Quickstart app, but I put the Like button on the home page after you sign in. I did *nothing* more than put the JS API initialization and Like button on the page (e.g., I did no follow-up authorization on the client). For me, it seemed to work fine....but again, this is just an initial experiment, so maybe there's something I'm overlooking.

I *think* the reason this works is because ultimately the Like button is rendered in an iframe with content served from Facebook. Since the JS API was initialized with the same App ID as the server-side, that content is rendered from Facebook who knows that you have already authorized the application. This may or may not work as well with other JS API calls or FB social plugins...but it seems to work fine for the Like button.

Comment

Thank you kindly for your prompt response and the initial experiment based on Spring Social Quickstart. The behaviour exhibited in your sample correlates with my own experience when making my own initial attempts at "Like" Integration.

With a little re-adjustment of my expectations I'm not so far from where I want to be:
1) My own tests of client side Like implementation using the following tags in my web page JSP

suggest that if I relent on the expectation of implicit sign-in when the user "Likes" when not currently logged in as a social user, you get a "reasonably" seamless experience ... involving a browser page invocation to authenticate followed by typical "Like" button behaviour (this being for an already authorised user ... I've not checked out the experience for a first timer... but expect/hope it won't complicate the issue). Of course, under the current situation the user is not logged into the local application, but the Facebook login button (ie. the implicit sign in button) is there if they wish to do so.

2) I tried a few variations of client side Like->server side login->client side Like->server side logout etc etc and it all works seamlessly, particularly after we have a Facebook social user connection (ie. session)

3) I cannot yet figure out by what mechanism I can get access to the Facebook JS SDK so that I can use the following client side JS based Facebook event script (this is just the Facebook Dev sample code to give an idea what I'm talking about):

On the one hand I'm using Spring Social tag based integration of Facebook JS SDK (or so I'm thinking) but I cannot find any documentation to clarify the way forward if you wish to hook into the Facebook JS API to achieve more complex client side behaviours. To be clear my knowledge of Javascript is weak at the moment, so perhaps its my own knowledge gap in this case that's leading to my confusion (?).

Comment

On the one hand I'm using Spring Social tag based integration of Facebook JS SDK (or so I'm thinking) but I cannot find any documentation to clarify the way forward if you wish to hook into the Facebook JS API to achieve more complex client side behaviours.

I haven't tried it with the Spring Social tag, but I would think that the FB object would be available once the JS API is initialized, whether done through Spring Social's tag or otherwise. Ultimately, that tag just adds the same markup to the page that you would otherwise do manually (albeit, it does the synchronous load, as opposed to the asynchronous approach described at https://developers.facebook.com/docs...ce/javascript/ ...that's something I should fix or at least offer as an option).