Validation, Authentication and Authorization

Content

• Validation
• Authentication
• Authorization
• Adding validation
• Adding Authentication and Authorization

In the previous excerpt, Basic CRUD API with express, we discussed creating a CRUD API with express. We installed extensions for our development environment. We also installed express, an npm package, to create our server. We discussed how to create POST, GET UPDATE and DELETE routes, and how to parse (access) data from the request body, query string and request parameter.

This excerpt will discuss validation, authentication and authorization. We will be building on top of the previous excerpt. Refer to the previous material for the code snippet. You can also reference this material from here.

We are using the snippet from the previous excerpt. You can follow that to have the starter code.
Since we always start on a fresh environment, I will have to follow the process of creating a node app and copy the content of the index.js file and package.json. Remember to run npm i or yarn to install the npm packages (if you cloned the project)
If you are having any issues, the project can be found here on GitHub, expense-tracker-api-articles/01-basic-crud-api-with-express/expense-tracker-simple-api or drop a comment. I or any capable individual may attempt to help you, as they see fit.

Validation

Before we jump into definitions of what is what and all that, let me draw your attention to why we have to validate data received from users by referencing some articles written on DEV. Check out these articles to have a different voice on why validations is importance. I think it will spare us the definition of validation.

• Why Form Validation Is Important > You need form validation as a security measure. Forms are an easy target for hackers because we all know they're connected to a database somehow. Letting people put whatever they want into your form opens you up to SQL injection attacks as a start and it can get way more advanced than that.
• Input Validation: Client-side or Server-side? > There is a rule of thumb to never trust the user's input
• Data Validation in Your Backend: A Practical Guide > Failing to validate data can lead to security vulnerabilities, bugs, and data integrity issues
• Data validation is a vital step in creating reliable and secure applications. > Data validation is a vital step in creating reliable and secure applications.
• In Defense of D > The function has inputs. And the function shouldn't be aware of where those inputs originated. Therefore, from the perspective of the function, the inputs are all potentially dangerous.

From these very short portions about validations from these articles, it should be clear why validation is important and why it should matter. They all point out that it will be a security disaster if proper validations aren't done and this obviously will/may lead to a loss, a financial loss, primarily. One's business may lose data, users, integrity, money, etc as a result of a security breach. As such I, and the community as a whole, encourage you to validate data before inserting or updating existing records.

There are several instances where some client (app) communicates with the backend and these moments are mostly submission of forms.

In the previous excerpt where we were creating and updating expenses, what should we "consider" as an appropriate or acceptable value for name, amount and date?

• In this case, the name should specify what object, element or event the expense was for. It could be a word or phrase that describes the expense.
• For the amount, usually, the question should be, do we consider a negative value or even zero in this case as an acceptable value for the amount? What is the limit of the value that the user can pass? This is in a sense that, can a user pass 1 million or 1 billion?
• For the date value, we should consider the format of the expected expense date. We can have it that the date should start with the year followed by the month and then the day. The year, the month and the day can be separated by some specified character. We used a hyphen, -. So here you can specify whether the date should be separated by a forward slash, /, or even a colon, :. You decide.

If you have been following this series, then you know that we have written some validations in the past. From, JavaScript Essentials: Part 6 (Mastermind in Javascript), this is an example of a validation:

function isValidRound(rounds) {
    return MIN_ROUNDS <= rounds && rounds <= MAX_ROUNDS && rounds % 2 == ZERO;
}

Let's define some validation rules:

• Name
  • Must be a string
  • Must not be empty or null (it is required)
  • Minimum characters of 10
  • Maximum characters of 255
• Amount
  • Must be a number or numeric string
  • Must not be empty (it is required)
  • Must be a positive number
• Date
  • Must be a string
  • Could be empty or null (it is an option, current date will be used)
  • Must be in ISO format

As an exercise, implement three functions that take in the specified data, validate it and return a boolean.

function isValidName(name) {
    // returns a bool
}

function isValidAmount(amount) {
    // returns a bool
}

function isValidDate(date) {
    // returns a bool
}

It will be cool to have them exported from another file called validation or some awesome name that hints at what these functions are doing.
It is also a good practice to separate concerns. If this sounds weird or strange then we can simply say that it is better to reduce the number of code in the index.js file.

At this point even if we don't define what validation is, with what we have discussed so far, one can have a solid idea of what validation is and its importance.

So, what is validation? Care to share with us what you believe it is, at this point?

Authentication

Earlier on with discussed that validation is a mechanism that ensures that the values or input taken from a user is an appropriate or an acceptable value that conforms to certain requirements or standards. The idea of authentication in some way is similar to validation.

In authentication, where we make sure that the claims of a user, passing their credentials to have access to some account, is legitimate. This means that we check or verify that a user is who they say they are, based on the credentials they pass. Mostly, these credentials are made up of a public identifier which could be an email, username or some string token (an alias which can be shared with others), and a secret which is dubbed as a password (