Introduction to my module
My project for Drupal during Google Summer of Code 2015 is to create a Drupal 8 module for a protocol called Hawk. Hawk allows the users to identify themselves and provide an alternative to the standard cookie-based authentication that takes place by browsers. It is mainly meant to be used alongside the REST module, however there are no hard restrictions. Another developer or user can use it as they please. The module itself identifies the user amongst other things such as handling special Hawk end points and header values.
The Hawk Protocol
It is similar to OAuth and HTTP Digest Access Authentication in the sense that it uses a specially generated string to identify the user to the web server. One of its key points is its simplicity, when compared to OAuth while trying to identify a user to the server, the user can identify themselves without complicating the process with multiple requests. They just have to send a specifically carved security key and let the server handle the rest. For more details, feel free to check out the official Hawk page.
Beginning with the module itself
As stated above, my project is to implement the hawk protocol for Drupal 8. The initial part of that is to create a PHP library for Hawk, fortunately that already existed in the form of dflydev/php-hawk. However, I felt it wasn’t up to the level I wanted it to be, so I forked it at Dragooon/php-hawk and improved it as well as added a couple of new features I felt were necessary. Once I was done with the library after my initial few weeks, I started implementing the module into Drupal.
Drupal and its sandbox
A full project gets a unique URL at drupal.org, for example drupal.org/project/oauth. Only projects that have gone through the Drupal Project Application and get approved are allowed to have a unique URL as well as have releases via drupal.org. Initially anyone can create a sandbox to get their project started, this gives the module a full-fledged issue tracker, git repository amongst other drupal.org features for developers.
I started my module as a sandbox module, spent about 3 weeks implementing the hawk protocol as well as build the UI around it. I added basic features that were determined by me and my mentor to be necessary as well as basic documentation to get started. It is by no means finished but we felt it was enough to apply for full project status.
The Review Bonus program
Once me and my mentor felt the prototype module was built well enough to be considered for acceptance, I moved on to apply for Drupal project application. Drupal.org has a review bonus program which basically states that anyone who has done three or more reviews of other’s project application gets their applications bumped up to the highest priority list. Knowing that it is a long queue, I figured it’s a good idea to have the application process sped up, plus I get to help out the community and look at other modules so it’s a win-win.
The reviewing of other modules isn’t hard, if you’re new I’d say pick up something small to get the hang of it, which is what I did. The default template of a review comment itself will help you get an idea on how to approach it, doing it once or twice will make you familiar with it enough to be able to do it comfortably. In a nutshell you have to ensure that the module follows guidelines related to licensing, third party assets, readme, code and anything else related to a module. Reviewing can make you somewhat nervous, at least it made me. What if I missed something? But something that assured me was that most of the time there would be someone else reviewing the same module as well, in case I missed anything. Since it’s an open community and project, things that were not caught or are less obvious can be corrected later. So far, I’ve reviewed three modules but I intend to do more as I get time.
The approval process
Other reviewers found a few issues in my project, for starters there were a few code style issues (as reviewed by pareview.sh). Drupal has certain code guidelines, which are expected to be followed by modules. I had few issues in my project, which took about 2 days to fix. Most of them were minor style issues (a missing full stop or comment) and nothing which required any significant changes. Once that was done, I ran into a small problem regarding licensing. Drupal.org only allows GPLv2 license but mine was The MIT License. I personally don't prefer GPL but it still was a minor inconvenience.
Once I had fixed that, my project got approved and I received maintainer access for the project. This meant that I could now get a full-fledged url (which I did, it’s drupal.org/project/hawk_auth) as well as have releases. This entire process took two weeks which was fairly quick, all things considered and I think being Drupal 8 only helped since that queue was barely existent.
To any other student or module developer reading this
I know the process can appear a little intimidating but it’s a necessary step, it also allows an outside perspective into your module and give feedback which can help make it better. People all around are really helpful and the feedback I received was encouraging. Once you feel you have a module complete enough to showcase its purpose, I say go ahead and try to get it approved. Make sure to read the various guidelines (module guidelines, coding guidelines etcetera) and run the project through pareview.sh and similar tools to identify most of the issues someone else might identify before submitting. This would help cut down your application time. Also, get in on the review bonus program, it’s really simple to review other modules and helps the community out further.
I am happy with getting maintainer access, there is still a significant amount of work left with the module but it’s a great feedback for me to know that it’s heading in the right direction. By the end of the summer of code period, I hope to have a full-fledged module ready for distribution with documentation.
Thank you for reading!