Announcement Announcement Module
No announcement yet.
Developing an app accessing multiple FB or twitter apps Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Developing an app accessing multiple FB or twitter apps

    developing a (server side) app that connects to a facebok (or twitter, or whatever) app implies writing (o rcopying) a lot of boiler plate configurations and code and I'd like to develop a service that is able to use multiple facebook or twitter applications.

    Since the configuration of the facebook config is usually static (i.e. something like: <facebook:config app-id="${facebook.clientId}" app-secret="${facebook.clientSecret}" /> in the configuration files) what would it be the best approach to have it dinamical so that a "generic" server application able to use multiple facebook applications (whose client ids and secrets are kept in a database) could be developed?

    Is that even possible with the current spring social libraries?

    Thanks for any suggestions!

  • #2
    It's not possible in Spring Social at this time, nor is it sanctioned by many of the providers in question. The terms of use for many providers explicitly state that each app should have only one client ID/secret pair. I'm not sure if Facebook has such a limitation, but they might.

    I suspect that the reason some providers restrict multiple IDs per app is to avoid having the app use a pool of IDs that they use to work around rate limits and that kind of thing. There may be other reasons, though...all in the interest of not having any one client abuse the platform.

    That said, if you were to fall back to *not* using the XML namespace and explicitly declare the various beans involved, you *MIGHT* be able to configure a connection factory in request scope and wire its client ID/pair using the Spring Expression Language such that its client ID/pair isn't determined until request-time. But I can't say that I've tried it, so I can't say that it'd even work.

    I'm curious what your use-case is for this. Why do you need a single application to present itself as multiple applications when dealing with Facebook or Twitter?


    • #3
      Thank you Craig for your reply.

      The use case is this one: I have multiple (native) app, each one uses exactly one pair of clientid/secret and each of them has to access some server resources (using a REST protocol right now), for some "standard" services like storing the user data, managing IAPs, requesting list of FB friends and so on.

      Now, of course I could develop a different server side app for every native app, but since they share 99% of the code except that ID/secret pair of credentials it would be silly to do so

      So, to summarize: I use exactly one couple of credentials for every native app (thus following providers guidelines), but I want to develop only one server side app that is able to serve requests to all of them.


      • #4
        Since it's not so clear, I try to better describe a use case.
        Let's suppose I develop a game named G1 that runs on tablets and that needs some server side services to do some things like:
        - saving the user profile and InAppPurchases
        - invite my facebook friends to play the game against me
        - tweet my awesome scores

        Now we would create a scheme of this kind:
        G1 -- MyServer -- FaceBook
        where G1 asks the server to store my score and invite my friends to play.
        MyServer runs a great app using spring social and is able to do all that.

        Not let's suppose I develop a couple others tablet game, those ones are called G2 and G3.
        G2 and G3 could being played by different people, and those players should not need to know that G1 exists (for them it's irrilevant).
        Like G1, G2 and G3 need a server side service to make exactly the same operations of G1: store profiles, invite FB friends and tweet their scores.

        Now, on MyServer I could setup two other instances of my app (one for G2, and another for G3) where all the code is completely the same and the only difference are the clientid/secret pair of each app, but that would be wasteful.

        I would prefer to have a single server side application, able to serve the needs of all my games (and their users), in a scheme like that one:

        G1 \
        G2 - MyServer - FaceBook
        G3 /

        But that means that when the service running on MyServer is being used by G1 it must be able to connect to Facebook with G1 clientid/secret pair, and using the other pairs when serving requests for different games.

        I hope this all make sense to you



        • #5
          Well, that does kinda make sense and I now have a better feel for what you're trying to do. As for me, I'd still be inclined to deploy the server side app once for each game you have, unless there's a reason such that the different games are aware of each other.

          In any case, Spring Social currently does not support this model. And I can't think of any way to "hack" it in.

          If I were to decide to support this model, however, how would you recommend that your server-side app identify which client-side app it should represent? At connection-time, I could see something like ConnectController handling a pattern like /{app-name}/connect/{provider ID}. But then there'd need to be a way of identifying each client-side app when you call the API binding methods--that's where things get messy.

          I'm open to ideas and will consider them...but at this time, this is not something I plan to implement. But what you can do is open a new feature issue at and if it gets enough votes to warrant more attention, then I'll certainly give it higher priority.