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-

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).