MagmaFacebookPage edited by Simone GianniScopeThe integration between Magma and Facebook aims at giving fragments that will allow :
It does not aim at being a complete facade over Facebook nor a Facebook library. Interfacing with fragment userMagma already contains a fragment user, that supports basic user operations. This fragment offer a bean named "User", with a few common properties like name, surname, email, password and some utility boolean like active (wether it has confirmed its email address) and admin (wether it is an admin). It would be nice to have Facebook users be transparently integrated with users from this fragment, however there are a number of problems :
Moreover :
Canvas Facebook ApplicationsCanvas Facebook Applications are called by Facebook when the user enters the application. Facebook will give the application a few data about the current user, and permit a number of basic operations unless the user has granted proper rights. Magma could provide a specific Handler with a landing page for canvas applications. This landing page would read those parameters from Facebook, initialize a user as if it was a login, check for required permissions etc.. Facebook ConnectFacebook connect permits to sites to use Facebook as an authentication service. Once the user is authenticated with Facebook, and eventually granted permissions to the site, the site behaves like a Facebook application in regard to user authentication and REST interface. Magma could provide, in the Facebook fragment, support for the Facebook Connect button in its login box, as an alternative way of authenticating. Ease common Facebook functionalitiesCommonly a Facebook application or site will want to perform a number of operations on Facebook users.
Other operations, like writing on the user wall, sending chat or facebook messages, photos, groups etc.. are not in the scope for fragment-user and fragment-user-facebook integration. There will be a way to access the underlying Facebook client library to perform these advanced operations. User profile informationsFacebook implements very complex privacy settings, and forbid to cache user data so that those settings can be honored. So, getName and getSurname on a Facebook user should not be saved on the database, but should be fetched from Facebook directly. Also, the two setters should have no effect. Writing some advices to make these methods behave this way is not that hard, however these advices should be crafted well so that they don't create errors when the User is being saved or retrieved from the database. Email to Facebook usersFacebook does not disclose emails. However, it offers proxied email service, with which an application/site can send use Facebook to send an email to a user. Such an integration could be achieved saving in the User.email field a fake mail address (like fb-uid@facebook.com) and then hooking into Magma mail system to send mail to those addresses via Facebook proxied emails. Friends on FacebookFriends on Facebook, as seen from the application/site, are in two groups : friends which are or are not subscribed to the application/site. For the first group (friends already subscribed) there is a corresponding User bean on the application/site database, so a method to retrieve these entities could be provided. For the second group, there is no corresponding User bean on the database, however a method to retrieve them as non-persisted User entities could be provided. fragment-user does not currently has a notion of connections between users. ImplementationMagma will support multiple applications/sites in a single instance. This is because a typical instance might handle both a site supporting Facebook Connect and/or one or more applications. Each application is simply composed of :
These keys will be provided as parameters in Magma settings. One application will be the default one, and also cover the simple case where onl one facebook connect site or single application is being served. Switch between applications will be done at specific points in the web handling system. The first time the application is required, the default one will be instantiated unless previously another one had been. Instantiation of specific sub-applications may be done via annotations on do/handle methods or entire handlers, or via explicit call on the currentl Cycle. Facebook also requires a Session to be established to access user centric operations. Session is created differently on canvas application or on site applications, extracting different parameters from the request. Once the facebook session is created, it can be stored in the server's session. In Magma it could be wiser to store in directly, as a transient field, in the user, cause all facebook interactions will then be routed thru the current user object. Magma will offer a landing page. That page will interact with the facebook client library and :
To do this, a landing handler will be provided. This landing handler needs to be configured with the right application, a default method will be provided for the default application. This handler will expose a doLand method. This doLand method will be funnelled with a complete HttpRequest to permit interaction with the client library.
Change Notification Preferences
View Online
|
View Change
|
Add Comment
|
- [CONF] Apache Labs > MagmaFacebook confluence
- [CONF] Apache Labs > MagmaFacebook confluence
