View Full Version : signin multiple appilication with one provider (facebook)
Sep 21st, 2011, 08:30 AM
I have multiple Facebook applications that my spring social app will handle. From reading the doc and view the source it looks like that I will need to create multiple ConnectionFactoryRegistry (one for every Facebook app). Another solution will be to create multiple FacebookConnectionFactory and change the way I store them within the ConnectionFactoryRegistry.
Has anyone did something like that?
Sep 21st, 2011, 08:47 AM
The ConnectionFactoryRegistry won't allow multiple connection factories for the sample API type or for the same provider ID. So, if you try to register more than one FacebookConnectionFactory, an IllegalArgumentException will be thrown for the 2nd one indicating that there's already a connection factory for that provider ID. One option you have is to create a custom implementation of ConnectionFactoryLocator to allow for multiple connection factories of the same type. The registration of those connection factories should be easy to do, but you'll need to figure out how you want to implement the getConnectionFactory() methods to deal with the fact that there might be multiple matches.
All that said, I wonder why you would want to do this anyway. You have a single application, right? Why have multiple Facebook applications? I'm struggling to see a case where that would be needed. And even then, wouldn't it create a confusing situation with your users? Help me understand the use-case that would require a single application to connect to Facebook as if it were multiple applications.
Sep 22nd, 2011, 01:58 AM
Thanks for you replay, I will try to explain the motivation for my request.
We have one application server that serves many client widgets that located on client pages. Each client widget can be for example a game,chat,poll etc. Some of those client widgets are based on facebook app (for example a game or a chat). Until now each client widget handle the connection to the social provider (facebook for example) by itself. That cause many difficulties such as domains issue for facebook authentication, API changes etc. With spring social our one application server will handle all connections to the social providers while all the client widgets will talk to it. That is the reason for one application serving many facebook application. We already wrote a POC and some small implementation and it seem to be working great, however we still have to solve the above issue.
Sep 22nd, 2011, 10:43 AM
I would not recommend creating a custom ConnectionFactoryLocator implementation for this - provider ids should be unique within a registry based on the defined ConnectionFactoryLocator contract.
I believe the right way to do this is register each ConnectionFactory instance under a unique id. This could be achieved by constructing each FacebookConnectionFactory instance with a different id, e.g. "facebook-game", "facebook-chat". However, since FacebookConnectionFactory does not define a constructor that accepts a custom id, and always specifies the id "facebook" internally, you'll need to define your own FacebookConnectionFactory subclass of OAuth2ConnectionFactory that does. This should be trivial to do, as FacebookConnectionFactory is a composite that's only a few lines of code: https://github.com/SpringSource/spring-social-facebook/blob/master/spring-social-facebook/src/main/java/org/springframework/social/facebook/connect/FacebookConnectionFactory.java.
Let us know how that goes.
Oct 3rd, 2011, 03:00 AM
I register FacebookConnectionFactory for every appId that we have. I did it by creating my on FacebookConnectionFactory that changed the getProviderId API to be facebook-"appId". I also created my own ConnectionFactoryRegistry to make it work. All GET/POST request for signin/connect are now in the format of provider-appId. It seem to be working great. I am registering multiple facebook application according to my config files.
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.