Adding Federated Login(OAuth2) Support

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

Whenever a user logs in using his Google, Facebook, GitHub (or any other site) account, he sees a popup as this one-

new-auth-2.png
Once the user grants the permissions, he can log in via his external account on the client app in future (without any other authentication). If you’re interested in the working of OAuth2, you can read here. And if you’re really, really interested in going into more depth, refer this.
I’ve been working on implementing OAuth2 in Ruqola [Link to code]. But sadly, our backend server, the Rocket.Chat server, does not support Realtime OAuth login API. Rocket.Chat doc for OAuth is not updated and thus I spent quite some time trying to implement it. Talking to a Rocket.Chat team member, I got to know this functionality is currently not available. Though I’ve created a support request for it at the Rocket.Chat GitHub, but it would take time to process and implement.

So for now, our backend is complete(well, except OAuth) and it’s time to move to the UI. I’m excited to be working on the UI as using QML for UI will be fun. Also, we’ll also be moving Ruqola to mobile soon!

If you’d like to work on Ruqola (or contribute to WikiToLearn in general), talk to us, or just hangout and chill, meet WikiToLearn people at the annual world summit of KDE, Akademy, from the 22.07.2017 – 27.07.2017! 🙂

Network Management

For managing network, I had to handle any kind of network condition that may arise. It took 80% time planning out the design of the code and the rest for implementing.
First we (Ruphy and I) thought of having a queue for caching the messages which are not sent to the server (due to any reason) [Link to the code]. But this design had problems with it. It was not generalised; it handled only text messages sent to the server.
Then we decided to have a separate class altogether to handle the unsent messages. Talking in technical terms, Ruqola uses Meteor APIs to send messages over the network and DDPClient class implements Meteor’s DDP. DDPClient is a generalised class and we tried to keep it that way. Now DDPClient class contains an abstract internal queue which handles all requests. It delegates the work of processing this queue to a separate class, the MessageQueue class. MessageQueue class tries to re-send these messages,until it succeeds, as soon as the network is restored.

During this, Ruphy always taught me to write elegant code and that it will be worth it (and I’ve begin to realise that it is).

I also learned some golden rules-

“Never expose your internal data storage until you are really out of other options.”

“Double arrows in a workflow create mess.” (Yes, this means I did mess up a lot :p )

Finally network management was handled as can be seen  here.

Next up, I have to add support for federated login (OAuth).

Extending Data Models

May30-June4
My first task was to extend the data models. I had to represent the message object and room object to have a 1:1 correspondence with the Rocket.Chat internally. Then I added support for sending images over the network. The functionality goes like this- let the user select an image from a file, upload it, encode it to base64 to send it over the network, recieve it at the other end, decode it from base64, save the file on a local cache and then finally display it to the client. The backend works perfectly; I’ll get to the front end after July. Here is a link to the code where this part was accomplished.

During GSoc

The first month is for community bonding. I had previously known WikiToLearn peeps so my community bonding included knowing people from KDE and other organizations. The common GSoC groups made the members aware of how diverse students,from 72 countries, will be working with a record 201 open source organizations this summer. That’s a huge number. During this time I, along with my mentors, Riccardo Iaconelli and Gabriele Lazzaro Falasca, planned out our timeline, set up the phabricator and made our etherpad notes. We decided to first tackle the backend and then the front end. And we were set to roll.

From May30,2017 the coding period started.

Before GSoC

I have been working on Ruqola since January this year. My first task was to add notifications support on desktop app. Since I was new to Qt/QML and Rocket.Chat, it took me quite a while to get familiar with the code base and technology. Finally my PR (my first PR ever) got merged into the original code for Ruqola. That felt very satisfying.

Ruqola-Notification-Screenshot.jpg

There was no looking back from here. I wrote a proposal for Ruqola, got it reviewed by a lot of people, modified, got it reviwed again, and repeated till it looked satisfying enough. While writing the proposal my mentor, Riccardo Iaconelli, told me to write it as how “I” would like it to be and that it’s my baby project, I gotta care of it! Ruphy has always been very humble and supportive.

Between the coding, I got to know the WikiToLearn community. I must emphasize on how positive and friendly each one of them is. I still remember the moment how I was welcomed in the community when I joined WikiToLearn Chat; so many unknown people welcoming you with such smiles wanting to know you and help you out. I’m more than happy to be a part of this amazing community. The journey form being welcomed to myself welcoming new people in the community has been incredible (the good part being that it has just started) and gave me a bunch of as amazing friends too.

On May4,2017, I got selected as a student developer in the Google Summer of Code 2017 for project Ruqola under KDE.