Developer Role Call!

archard

Joined: Jan 11 2007

Yes, I'd really love to get an environment set up where we can all contribute.

Right now I'm working on a login app that will handle authentication across the whole site. It gets tricky because the new discourse forum will be a completely separate app running on a different subdomain, but it must reference the login information that will be stored only on the main site (using a single sign-on technique). I suspect we will add on other apps that use SSO in the future (like Disqus comments or something similar).

I have just about completed the backend for this app, and soon I will start focusing on the frontend. My focus right now is on getting it deployed so that we can actually start using the new forum. But after that I will work on setting up a collaboration environment for that app. Since it's a fairly small app we can use it as a guinea pig to model collaboration on more complex apps in the future.

archard

Joined: Jan 11 2007

SpiderTemplarius said

In everyday work we use https://circleci.com (it integrates with Github), it's easy to setup it for node projects, first worker is free, and for such project it seems enough.

Cool. We use Semaphore at my work. I'll do some research to see what's best.

BigHeadClan

Joined: Jan 20 2012

I did some Javascript, PhP ,Web design & Security courses back in school but that was 6 years ago so I'm very out of touch, my current skill set is hardware side Data Centre Design & Tier 1-3 desktop support. I could help with a functionally test but an in-depth security audit is outside my current skill set.

Clanver

Pixelfingers cant play

Location: Germany, Kiel

Joined: Jan 03 2009

archard said

Would any of you be willing to do a security audit of my code?

I've got some complex stuff going on to get the logins synced between the main site and the Discourse forum and I'd love to get an extra pair of eyes on it since there are big security implications.

Hmm, well, not like im an expert in security but i could try to look for possible exploit weaknesses.

Clanver

Pixelfingers cant play

Location: Germany, Kiel

Joined: Jan 03 2009

haha, ok, well you mentioned an audit, the last time i did an audit i had to write a 30 page report about a company and their security situation ;D (was only for university, my company is more . .laidback?), phew ~

archard

Joined: Jan 11 2007

I'm going to post a detailed plain-English description of how the process works first, and I'd like to get comments on that before I post code.

I know it's long and I appreciate anyone who takes the time to dissect it! :)

So here's the current situation. The "main site" (www.gametabs.net) is a Drupal 6 app that hasn't really been updated since 2008. All information related to the site -- users, tabs, private messages, etc. -- are all stored in the MySQL database associated with it. The current forum is just a feature of Drupal 6. So when a user is logged in anywhere on the main site they're also logged in on the forum because it's all the same application.

Now I want to start using a Discourse forum (http://www.discourse.org/), which will be a completely separate app (call it the "new forum"), likely hosted on a different domain (some-subdomain.gametabs.net), which uses its own authentication system.

What I want to accomplish:
- current users of the main site will be able to use their existing account credentials to log in
- if a user logs in/out on either the main site or the new forum, they will be logged in/out on both

How it works:

Discourse has a feature called Single-Sign-On (https://meta.discourse.org/t/official-single-sign-on-for-discourse/13045). The main idea is that discourse will defer to an external application to authenticate the user, instead of using its own built-in authentication system. The process is outlined in the link, but I will reiterate it here:

1. both Discourse and the external application know about a predefined secret
2. the external application sends a GET request to /session/sso to initiate the single-sign-on process
3. Discourse responds by redirecting the client to a predefined url on the external application and puts two query parameters in the redirect URL: sig and sso. sig is the HMAC-SHA256 of sso and the predefined secret
4. When the external application receives the request, it validates it by taking the HMAC-SHA256 of the given sso with the predefined secret and ensures that the result is equal to the given sig. If they match, then it is confirmation that the request came from a trusted source (or at least one that knows about the predefined secret)
5. sso is a base-64 string that, when decoded, will yield a nonce.
6. The external application performs whatever authentication it wants to.
7. The external application creates a payload representing the user, which includes the nonce from step 5, to send back to Discourse. In our case the payload is a username and email, basically.
8. The external application encodes the payload with HMAC-SHA256 using the predefined secret.
9. The encoded payload is sent back to Discourse, where it is HMAC-SHA256 decoded using the predefined secret.
10. Discourse checks that the nonce sent with the payload is valid
11. If the nonce is valid, Discourse trusts the payload sent by the external application and creates a session for the given user

It’s not important to understand every step of the process in detail. The important takeaways is that ALL user information is stored on the external application. It is the single source of truth as far as Discourse is concerned. As long as the external application gives Discourse a valid nonce, it will blindly trust it.

Now, let’s talk about step 6, performing the authentication itself. As I said in the beginning, all user login information is stored on the main site right now. So, in this step some authentication on the Drupal 6 app must occur. I've chosen to create a separate application to handle all login, logout, register, and reset password operations (call it the "auth" app). The reasoning for this is that I want to move away from Drupal all together, and to that end it doesn't make sense to add anything new to it. It will be too hard to do a total replatforming in one go, which Is why I am just focusing on just forums and authentication for now.

With that decision in mind, I need a way to interact with the Drupal app through the auth app. My only choice for this (since the main site is so old) is through an XML-RPC API (same as a REST API, basically). Through this API I can perform login, logout, register, and reset password operations on the main site.

So, on the auth app, I have an endpont /receive-nonce. I set Discourse to redirect to this endpoint during step 2. This endpoint will receive the sig and sso parameters, do the necessary operations to get the nonce, and then store the nonce in memory on the server.

Then, during step 6, a user's login credentials are collected by the frontend app, a POST request containing the credentials is sent to the auth app server, and the login operation is performed on the main site through the XML-RPC API. If the login is successful, the XML-RPC API returns info about the user (username, email, etc) back to the auth app, where the payload is generated, and a nonce is retrieved from where it was stored in memory during step 2, and sent back to Discourse along with the payload. When that information is received by Discourse, it will log the user in on the new forum. In the meantime, the XML-RPC API also returns a session cookie representing the session for the authenticated user on the main site. Any client with this cookie set will be considered "logged in" by Drupal. The auth app server then responds back to the client telling it to set the cookie. This effectively sets the session for the user on the main site and logs them in.

I will leave it there since that is a buttload of information. I'd really love to field any questions you all have!

auriplane

Joined: Sep 06 2008

archard said

With that decision in mind, I need a way to interact with the Drupal app through the auth app. My only choice for this (since the main site is so old) is through an XML-RPC API (same as a REST API, basically).

Are you planning on upgrading or phasing out Drupal eventually?

thedstring

Nate Brooks

Location: Utah

Joined: Jan 05 2011

Holy shit that's one of the nerdiest things I've ever said on this site =D

archard

Joined: Jan 11 2007

thedstring said

"XML-RPC API (same as a REST API, basically)."

In one of my classes we are studing RESTful APIs specifically (and I just finished building a RESTful API using PHP and I'm about to start another one for a mock guitar tabs site as my final), and I can tell you that RPC and REST are not the same thing.

Simply put, the architecture of REST and RPC are fundamentally different. RPC allows for something like

www.something.com/goodies/v1/updateGoody?id=25

or

www.something.com/goodies/v1/getGoody?id=25

but REST would force you to use an HTTP request to define the action (like GET or DELETE) and use:

www.something.com/goodies/v1/goody

for all actions associated with a "goody". Instead of getGoodie or updateGoodie, you use the PUT/PATCH (to edit) or GET or POST (to make a new one) or any other HTTP request and build in the authentication and other info in the body of the request.

It's a seriously interesting (and crazy powerful and maintainable) way of making an API, I'm way glad I'm taking this class =)

I just wanted to clarify that for anyone interested in keeping up with this thread and possibly helping out!

I'm excited to see where this goes =)

You're right, there are differences between RPC and REST. Namely that RPC only sends POST requests and the payload of the request indicates a method to be run on the server. Actually there is an important detail about my RPC implementation for registrations that I will describe later when I have some more time. Thanks for the input! :)

thedstring

Nate Brooks

Location: Utah

Joined: Jan 05 2011

It's a lot of extra work to make a RESTful API, but holy crap is it worth it. Once it's up and running it's so amazing to work with! And it's comparably easier to maintain too

Zaeche

Word-puddle

Joined: Jun 02 2015

Don't have much to say except most of the auth stuff is over my head, haha (for the time being!). I guess I'll keep a weather eye for anything that makes sense, but I think I'll give it some time and see how it goes. In the meanwhile, I reckon I'll set up a Discourse box via Vagrant and play with it a bit. I've been meaning to for a while and it might be fun?

archard

Joined: Jan 11 2007

thedstring said

It's hard to make a judgement call without seeing the actual code (which I bet is pretty massive with all these steps).

What programming language are you using to make all these calls? I'm really not a huge fan of trusting a huge CMS like Drupal, the system is easy enough to write and when you use your own code it's not that complicated. But then again you have to manually write in all of the security yourself (not as bad as it sounds).

But because I don't have any experience within the Drupal world I have a hard time giving advice.

It seems a little weird that the user.login method is called in step 2 when the user.register method is called in step 3. Why is the user logged in before they're registered?

If I could see the code I could give my advice. I'm extremely used to these kind of systems sans CMS because the people I've dealt with so far don't want to use a huge CMS. But I can see why some companies would want to use a CMS like Drupal.

Drupal is just what we have now and there's no getting off it for the time being. Just consider it a constraint at the moment. Don't think about it as a CMS, think about it is an XML-RPC server that external applications can interface with. In this case the external application will be an Express (Node.js) server which will create XML-RPC clients that connect to the XML-RPC server.

The reason user.login is called before user.register is because the XML-RPC client must be authenticated as a user who has permission to run the method on the server which creates new users. I don't want to expose that method to the public.

archard

Joined: Jan 11 2007

Backend code is almost done!

If you want to be added to the GitHub repo to review the code, and get involved in development, post your GitHub username here (or email it to me if you don't want it public - [email protected]).

WooooooohoooOO!

archard

Joined: Jan 11 2007

thedstring said

I wanna see!!! If you're cool with that =)

my username is nateonguitar

You've been invited! Looking forward to discussing things with you. For comments and questions related to the project, feel free to create an issue on GitHub :)

archard

Joined: Jan 11 2007

Just added you Clanver

emrata

Joined: Jun 07 2022

thanks for the info

Sures1953

Location: Alaska

Joined: Feb 05 2022

In the midst of your own developer role call, you need to provide an environment that will help the team members to collaborate more effectively and efficiently. You need to check this https://rubygarage.org/blog/technology-stack-for-web-development and get more new ways for web development. You also want them to know how you want to work together as a team and what their individual responsibilities are.

billyroberts

Joined: Oct 27 2022

Gamification
Gamification is a type of eLearning platform development that incorporates game-based concepts and behavior patterns. It's designed to motivate and improve learner performance.

In a gamified environment, social aspects draw on learners' sense of recognition of their value. They also appeal to feelings of acceptance. This results in improved learning effectiveness, according to experts.

Whether you're developing an online course or an application, you can use gaming elements to add more dimension to your online training. These link include leaderboards, rewards, and challenges.

Gamification can boost employee engagement and retention. However, the strategy should align with your company's culture and needs. The key is to establish clear goals and understand the mechanics of a gaming system.