Previous part: Putting your web application online – Part 4 – HTTPS

Steps to take:

1. Install database server
2. Create users database
3. Node++ database setup
4. Node++ USERS setup
5. CSRF protection

Step 1 – Install database server

Looking at modern database servers landscape, we have basically two types: SQL (structured) and NoSQL (sometimes nicknamed as document). NoSQL databases are primarily optimized for large unstructured data volumes, like for example social network user content. However in majority of everyday use cases, traditional SQL model is still preferred. Modern engines of both types are anyway capable of serving variety of needs.

Node++ USERS module uses SQL model and its most popular engine: MySQL.

Among Linux packages we can encounter two database servers with the same API: MySQL and MariaDB. While the latter is newer and – is some circumstances – faster, from a moderate-sized startup standpoint, it's practically the same.

On AWS EC2 Linux 2 AMI, default MySQL-compatible package is MariaDB:

For other distributions see Cheat Sheets.

We should start with securing our database server. Make sure the root password is secure. You can use our secure password generator for this:

As default timeout is quite short, we need to increase it. Also default packet size is typically very modest. If we want for example, save pictures to the database, we need to increase it as well. Let's edit the configuration:

Our changes should go into the [mysqld] section:

Lets' start the server and add it to system startup:

To improve our data security we can create a separate user for our application. Let's start mysql client:

First, lets' create a database:

Then create user nodepp:

Now grant the privileges only to the database:

Refresh:

Quit the mysql client:

Step 2 – Create users database

It only requires execution of Node++ SQL script:

Step 3 – Node++ database setup

Node++ compilation script can link MySQL libraries and application can open a database connection at startup. It requires adding NPP_MYSQL to npp_app.h:

We would obviously have to recompile the application but let's wait with this until the next step.

Additionally, we need to tell the compiler where the MySQL headers and libraries are installed. We use src/m script for this. On AWS EC2 Linux 2 AMI they are there:

For other distributions see Cheat Sheets.

We also need to tell our application where the database is and how to get there. Let's edit the configuration, that is bin/npp.conf:

Step 4 – Node++ USERS setup

To enable USERS module we need to add NPP_USERS to npp_app.h:

Before we continue with coding, we need to make two choices:

1. How do we want to identify our users?

   We can choose between login and email. As login is default, for email we'd need to define NPP_USERS_BY_EMAIL in npp_app.h. In such a case login won't be required in HTML forms. Note that with default option email can also be used to log in.

2. Do we want users to confirm registration via email?

   This can actually be decided at the configuration stage. By default, confirmation is not required. If we want this, usersRequireActivation parameter in npp.conf needs to be > 0.

Now is the largest part of our task: we need to write HTML forms. Let's call each of the functions render_action, where action can be one of the following:

• register (create account)
• login (log in)
• logout (log out)
• myaccount (edit account details)
• forgot (forgot password)
• preset (password reset)
• contact (send a message)

We don't have to implement all of them at once. The minimum set to get started would require render_register() and render_login().

render_register() example:

render_login() example:

Note check_error_msg() at the beginning. If there's an msg parameter in the query string, it will show the message above the form:

Form fields have to have specific names, listed in USERS functions' documentation.

We also need to update routing in npp_app_main(). Some of this routing details will depend on the application model. From the backend routing point of view, it can be traditional, SPA or mixed combination of those two. The example below is for the traditional model, in which AJAX is not used and every change on the page requires its reloading.

Functions render_* render HTML forms with attribute action pointing to the relevant do_* endpoint:

Brute-force protection

Node++ USERS module has a brute-force attack protection. It records unsuccessful login attempts (ula_*) in users table, along with their time. After several ula-s, it forces the client to wait before the next attempt. The details and setup is described here.

Step 5 – CSRF protection

CSRF stands for Cross-Site Request Forgery, also known as session riding, one of the attack types, involving performing unwanted action during legitimate user session. If you are interested in the details and real attack examples, this Wikipedia article explains it quite well.

One of the common ways of web application protection against such an attack is CSRF token, in short: CSRFT. If we add freshly generated random token to every HTML form (usually as a hidden input), we can then verify it upon the form submission. This way an attacker has no way of preparing a valid request in advance.

Node++ generates fresh CSRF token every time the session is started. There are three macros, of which two are needed for a basic protection:

• OUT_CSRFT – add hidden input with session's CSRFT
• CSRFT_OK – verify CSRFT
• CSFRT_REFRESH – refresh CSRFT (if higher security is required)

Our modified code would then have additional CSRFT input:

On the form submission (when browser goes to do_login) we would need to check token validity before proceeding:

CSRF protection would need to be added to every form, especially vulnerable is myaccount.

That's it for now! We can now create and manage user accounts in our application.

Next part: Putting your web application online – Part 6 – Advanced anti-bot protection

Is something wrong here? Please, let us know!