[GSoC 2016: Social API] Week 5: Checking abstraction of Social Auth

Date of publication: 06/29/2016
Source: GVSO Blog

During this last week, Google Summer of Code students must have submitted their midterm evaluation and waited for their mentors' evaluation. During these first weeks, I have been working on the main components of the Social API project. These components are:

• Social API: contains the basic and generic methods, routing settings, and permissions every Social API sub-module will need
• Social Auth: implements methods and templates that will be used by login-related modules
• Social Post: provides methods to allow autoposting to social network’s accounts
• Social Widgets: allows sub-modules to add functionality to add widgets (like buttons, embedded content) to node, blocks, etc.

There are other modules which are used to test and develop the abstraction of these projects. They can be found at the Drupal Social Initiative github repository.

Fortunately, on June 27th I received an email stating I have passed the midterm evaluation. This means I will have the chance to continue working on my project as a GSoC student!

Hi gvso,

Congratulations! You have passed the midterm evaluation

Social Auth abstraction

As a mentioned above, one of the four components of the Social API project is Social Auth (social_auth), which provides an abstract layer for modules which allow user registration/login in a Drupal Site.

To develop the Social Auth module, we created (actually adapted) a module for user login via Facebook to provide an and test the abstract layer. This implementation can be found at my github repository (simple_fb_connect). Nonetheless, to make sure that this abstraction works with other implementors, on June 10th we agreed to create another module for user login. For this purpose, we chose to work with Google API  as we believe most users would have a Google account. Therefore, during last week I have been working on a implementor called Google Login (google_login).

This module, Google Login, did not require any change in the Social Auth code. On the one hand, I am glad that it works with the current architecture. On the other hand, I am unhappy as I was looking for finding new requirements to challenge myself in re-adapting the Social Auth abstraction.

As of current, the Google Login settings form only allows to input the Client ID and Client Secret. It adds a Google+ icon which appears on the Social Auth Login block. Furthermore, It automatically redirects users who log in to the user page /user/{uid}.

After working on the module described above, I could conclude that the current abstraction proposed by the Social Auth works perfectly. However, we have tested it with two implementors (Facebook and Google) so far, so we can not assure that it would do so with any other social networking service. Nonetheless, we will keep refactoring the code if needed to adapt it to requirements.

Beta Release

We are happy to announce that we have released a beta version of Social API (social_api) and Social Auth (social_auth) modules. We invite you to test the projects and report any issue you find. And if you would like to add some new features, we will be glad to read your ideas in the issue queue.

Next week

In my last weekly summary, I described the module facebook_buttons which is based on Social Widgets to provide Facebook buttons. So far, it only allows to add Like buttons to teasers and nodes; nonetheless, it should also provide options for the Send and Share buttons. Therefore, I will be working on adding these features to the module and releasing a beta version of it in the Drupal project page.

As always, feel free to contact me if you have any question. You can also collaborate with the Social Initiative projects (social_api, social_auth, social_post, and social_widgets). We also have our weekly meetings, so follow the Social Initiative and join us on Fridays.

Stay tuned for the next weekly summary!