DEV Community: Dev-Academy.com

Build a To-Do Application with React and Firebase

deji adesoga — Mon, 23 Jan 2023 13:16:36 +0000

To-do applications are one of the ways you can use to manage a set of tasks. As developers, learning how to build a to-do application will also help to understand certain concepts one of which includes an understanding of how to build an application with a database.

In this article, you will learn how to build a to-do web app by making use of React.js and Firebase Database.

Prerequisites
How to Create the Firebase Project
Creating the Firestore Database
How to Create the React Project
Setting up the Project Structure
How to Integrate Firebase in React
Integrate Bootstrap 5 into React
Designing the User Interface
Adding Data to the Firestore in React
Fetching Data from the Firestore in React
Deleting Data from the Firestore in React
Updating Data in the Firestore in React
How to Integrate the Checkbox Functionality
How to order Data by Timestamp in Firebase
Conclusion

Watch the video version of this article below, or on my YouTube channel

Prerequisites

To install the npm packages needed for this React application such as Firebase, you need to have Node.js downloaded.

Visual Studio code serves as the code editor we will use to build this project.

The Firebase Console serves as the backend as a service database that helps us to store and manage our data, through the use of the Cloud Firestore.

How to Setup the Firebase Project

To set up firebase, you head to the firebase console website and create a new project by using your Google account. Once you are logged into firebase you will see an existing project, you can click on the add project button, as seen below.

Firebase console dashboard

After clicking on the add project button, we get navigated to a new page which requires 3 steps before the firebase project is created:

The first step requires us to name the firebase project, which we will call todo.
The second step asks if we want to enable Google Analytics, you should disable it by using the toggle button.
Finally, we can now click on the create project button.

Once the project is created, we click on the continue button which navigates us to the next screen, which is now our default firebase project dashboard.

Firebase dashboard

We have now completed the creation of a new Firebase project.

Creating the Firestore Database

Inside the firebase dashboard, on the left-hand panel we take the following steps:

• Click on the Build dropdown.

• Within the Build dropdown, select Firestore Database, this displays a page where we can click on the Create database button.

• Next, a modal pops up asking if we want Production mode or Test mode. You can choose Test mode since the app is currently in the development stage.

• The next step asks for where we want our Cloud Firestore to be located, you can choose the location closest to your area due to the possibility of latency.

Once we click on enable, we get redirected to the Cloud Firestore page which will currently have an empty Collection.

How to Create the React Project

We are going to create a new React project by making use of CRA (Create-React-App). Since we have node.js installed, we can run the following commands:

npm i create-react-app

Once the installation of CRA is complete, we can now create a new React project with the following command below:

npm init react-app todo
cd todo
code .

We have now created a new React project called todo, navigated into the project directory, and opened the project in Visual Studio Code.

We can now begin the set up of the React application.

Setting up the Project Structure

To set up the architecture of our React project, you can implement the steps below:

In the src directory, create two folders named components and services.
The components folder will contain two new document files. The first js file is called Todo.js, while the second file is called EditTodo.js.
In the services folder, create a js file called firebase.config.js. This file will contain the configuration of the firebase which we can export to different components.
Finally, still within the src directory, we head to the App.js file. Here, we clear the boilerplate inside of the div with the className of App and then import the Todo.js component as seen in the following lines of code:

import './App.css';
import Todo from './components/Todo';

function App() {
return (
<div className="App">
 <Todo />
</div>
 );
}
export default App;

With the above, we now have the basic structure of our React project set up.

How to Integrate Firebase in React

To add the firebase web SDK to our new app, the first thing we need to do is run the following command inside our terminal:

npm install firebase

Next, you open up the firebase.config.js file inside of the services folder and then use the following imports to configure firebase into the React app:

import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

Furthermore, you need to grab the project configuration settings from the firebase dashboard. On the left-hand panel of the dashboard, click on project overview and select project settings.

Scroll to the bottom of the page and select the web icon as shown below:

Web icon for firebase project settings

Once the web icon gets selected, a new page shows up asking you to give the app a nickname. You can proceed to call it todo or any other word you prefer, then click on register app. Firebase will now generate the firebase configuration settings, which contains the apikey, storage bucket, auth domain, project id, app id, e.t.c as seen below:

Firebase config settings

We can now grab this and paste it inside our firebase.config.js file:

import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

// Your web app's Firebase configuration
const firebaseConfig = {
    apiKey: "AIzaSyC5u80wO6iaPl8E9auM0IRXliYGKyDQHfU",
    authDomain: "todo-b74fc.firebaseapp.com",
    projectId: "todo-b74fc",
    storageBucket: "todo-b74fc.appspot.com",
    messagingSenderId: "872116099545",
    appId: "1:872116099545:web:9bb66d12ca15f2f39521c8"
};

The final step needed to complete the firebase configuration is to initialize firebase by making use of the config variable and then export it so it becomes available in all our components, as seen in the following lines of code:

import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

// Your web app's Firebase configuration
const config = {
    apiKey: "AIzaSyC5u80wO6iaPl8E9auM0IRXliYGKyDQHfU",
    authDomain: "todo-b74fc.firebaseapp.com",
    projectId: "todo-b74fc",
    storageBucket: "todo-b74fc.appspot.com",
    messagingSenderId: "872116099545",
    appId: "1:872116099545:web:9bb66d12ca15f2f39521c8"
};
const app = initializeApp(config);

export const db = getFirestore(app);

With this, our firebase configuration is successfully created and we do not need to make use of any other firebase services.

Integrate Bootstrap 5 into React

To integrate Bootstrap 5 you will need to head over to the Bootstrap 5 website and grab the CDN link for both the CSS and JavaScript. You can then head back to the React project in VS Code, open the public directory, and proceed to select the index.html file.

In the index.html file, we can paste the CDN links for both the CSS and JavaScript within the head section. With that we should have the result below:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn/tWtIaxVXM" crossorigin="anonymous">
</script>

Now we have access to all Bootstrap 5 classes across our components.

Designing the User Interface

To implement the design for the React project you will start by clearing the boilerplate code inside of the App.css file. You can now proceed to open the index.css file and then paste the following styles:

body{
  margin-top:20px;
  background: #f8f8f8;
}

.todo-list {
  margin: 10px 0
}

.todo-list .todo-item {
  padding: 15px;
  margin: 5px 0;
  border-radius: 0;
}

div.checker {
  width: 18px;
  height: 18px
}

div.checker input{
  width: 18px;
  height: 18px
}

div.checker {
  display: inline-block;
  vertical-align: middle;
}

.done {
  text-decoration: line-through;
}

Above, what we did was ensure all the elements that will be displayed on the browser are properly arranged.

Next, proceed to the Todo.js file and paste the code below within the return statement of the jsx:

import React from 'react'

const Todo = () => {
  return (
  <>
    <div className="container">
      <div className="row">
        <div className="col-md-12">
          <div className="card card-white">
            <div className="card-body">
              <button
                data-bs-toggle="modal"
                data-bs-target="#addModal"
                type="button"
                className="btn btn-info">Add Todo
              </button>

             <div className="todo-list">
              <div className="todo-item">
               <hr />
                <span>
                 <div className="checker" >
                 <span className="" >
                  <input
                    type="checkbox"
                   />
                 </span>
                  </div>
                  &nbsp; Go hard or Go Home<br />
                      <i>10/11/2022</i>
                 </span>
                  <span className=" float-end mx-3">
                     <EditTodo /></span>
                    <button
                      type="button"
                      className="btn btn-danger float-end"
                    >Delete</button>
                   </div>
                  </div>
                 </div>
                </div>
              </div>
            </div>
          </div>

          {/* Modal */}
       <div
         className="modal fade"
         id="addModal"
         tabIndex="-1"
         aria-labelledby="addModalLabel"
         aria-hidden="true">
         <div className="modal-dialog">
          <form className="d-flex">
             <div className="modal-content">
             <div className="modal-header">
               <h5
                 className="modal-title"
                 id="addModalLabel">
                 Add Todo
               </h5>
             <button
                type="button"
                className="btn-close"
                data-bs-dismiss="modal"
                aria-label="Close">
             </button>
             </div>
             <div className="modal-body">
                <input
                  type="text"
                  className="form-control"
                  placeholder="Add a Todo"
                />
             </div>
              <div className="modal-footer">
                 <button
                   className="btn btn-secondary"
                   data-bs-dismiss="modal">Close
                 </button>
                 <button className="btn btn-primary">Create 
                        Todo</button>
              </div>
            </div>
          </form>
        </div>
      </div>
    </>
  )
}

export default Todo

In the above code:

The div with the className of .container displays the card that contains all items in our Todo list, while the div with the id of addModal contains the modal where all the todo can be created using the save button called Add todo.

The final part of our design is in the EditTodo.js file. The EditTodo.js file will only contain the modal that allows us to edit each todo list item. The code can be seen below:

import React from 'react'

const EditTodo = () => {

 return (
     <>
      <button
         type="button"
         className="btn btn-primary"
         data-bs-toggle="modal"
         data-bs-target="#exampleModal"
       >
          Edit Todo
       </button>

       <div
         className="modal fade"
         id="exampleModal"
         tabIndex="-1"
         aria-labelledby="editLabel"
         aria-hidden="true">
       <div className="modal-dialog">
          <div className="modal-content">
            <div className="modal-header">
              <h5
                className="modal-title"
                id="editLabel">
                Update Todo Details
              </h5>
              <button
                  type="button"
                  className="btn-close"
                  data-bs-dismiss="modal"
                  aria-label="Close">
              </button>
             </div>
             <div className="modal-body">

              <form className="d-flex">
                 <input
                   type="text"
                   className="form-control"
                 />
              </form>

              </div>
              <div className="modal-footer">
               <button
                 type="button"
                 className="btn btn-secondary"
                 data-bs-dismiss="modal">Close
               </button>
               <button
                 type="button"
                 className="btn btn-primary"
               >Update Todo</button>
              </div>
            </div>
          </div>
        </div>
      </>
    )
  }
export default EditTodo

The design for the application is now complete. If you run the command npm start in the terminal and the code compiles, you should see the result below in the browser:

Complete page design

Adding Data to the Firestore in React

To implement the Add data functionality in our todo application, we start by importing some modules from firebase/firestore which can be seen below:

import { collection, addDoc, serverTimestamp } from 'firebase/firestore'

• A Collection is a folder that contains Documents and Data. All the data saved on our Todo application will be saved in a Collection called Todos, which we will create soon.

• addDoc is a high-level method used to add data to a Collection.

• The serverTimestamp contains the values of both time and date values for each Document in a Collection.

We then need to import the firebase.config.js file in our Todo.js file to allow us to have access to the firebase methods:

import { db } from '../services/firebase.config'

Using the import from our firebase.config.js file, we can now instantiate a reference to our Collection:

const collectionRef = collection(db, 'todo');

As seen in the code above, we created a variable called collectionRef. The collectionRef variable takes in the collection method. This method has two arguments. The first argument called db references the firebase service, while the second argument will create a new Collection called todo, which will contain all necessary Documents created.

Next, we create two variables using the useState hook:

const [createTodo, setCreateTodo] = useState("")

The first thing we did here is to import the useState hook in React:
import React, { useState } from 'react'
Then we created a getter and a setter called createTodo and setCreateTodo respectively.

To proceed, we move to the modal created within the JSX and implement the next couple of things:

Within the form tag, we create an onSubmit event handler called submitTodo.
<form className="d-flex" onSubmit={submitTodo}>
In the input tag within the form tag, we create an onChange event handler that allows us to get the value typed inside of the form:

onChange={(e) => setCreateTodo(e.target.value)}`

The final implementation we need to make before adding data to the database becomes functional is to configure the onSubmit event handler previously created. The code for this can be seen below:

//Add Todo Handler
const submitTodo = async (e) => {
e.preventDefault();

try {
   await addDoc(collectionRef, {
   todo: createTodo,
   isChecked: false,
   timestamp: serverTimestamp()
  })
   window.location.reload();
  } catch (err) {
    console.log(err);
  }
}

Above, we made the submitTodo variable asynchronous by making use of the async/await keyword in JavaScript.
We then created a parameter in the arrow function called e, which serves as an event. This ensures we are able to make use of the e.preventDefault() method which prevents the form from reloading after submission.
Next within the try/catch block, we call the addDoc method which takes two arguments. The first argument is the collectionRef variable we created previously, while the second argument contains the object to be passed into the firestore database.

These objects include the todo values inside of the input field, the checkbox value which is currently set as false, and then the timestamp in which the todo was created in the database.

We then make use of the window.location.reload() function in JavaScript to refresh the form upon successful submission, while making use of catch to handle the error.

With this, we can now create a new todo and view it in our database.

Creating the Todo

Fetching Data from the Firestore in React

To fetch the data from the Firestore in Firebase, we need to make two importation in our Todo.js file. These include the useEffect hook in React and the getDocs from firebase/firestore:

import React, { useState, useEffect } from 'react'
import { collection, addDoc, serverTimestamp, getDocs } from 'firebase/firestore'

We then need to create the setter(setTodo) and getter(todos) variables to help us access the data from the Firestore:

const [todos, setTodo] = useState([])

The data can now be fetched inside of the useEffect hook:

useEffect(() => {
const getTodo = async () => {
   await getDocs(collectionRef).then((todo) => {
   let todoData = todo.docs.map((doc) => ({ ...doc.data(), id: 
   doc.id }))
   setTodo(todoData)
}).catch((err) => {
   console.log(err);
})
}
   getTodo()
}, [])

Inside the useEffect hook, we created a variable called getTodo that takes in an asynchronous arrow function.
Then we called the getDocs method from Firebase. The getDocs method requires an argument, so we pass in the collectionRef.The getDocs returns a promise which we need to chain to using .then.
The promise returns an array that we need to map through to access the required data from the database, which are the todo list items as well as the id.
The todoData variable holds the data coming from the database. To have access to the data in our JSX, we will then put the todoData as an argument in our setter which is called setTodo.
We then proceed to handle the error in case there is any using the catch keyword before we finally call the getTodo function to initialize it on page load.

Now that we have access to our data from the database, we need to make it visible on the page. The data we have comes in form of an array and we need to loop through it in the HTML file. This will be done within the div with the className of todo-list as seen below:

{todos.map(({ todo, id }) =>
 <div className="todo-list" key={id}>
   <div className="todo-item">
     <hr />
      <span>
       <div className="checker" >
         <span className="" >
          <input
            type="checkbox"
          />
          </span>
          </div>
           &nbsp;{todo}<br />
           <i>10/11/2022</i>
          </span>
          <span className=" float-end mx-3">
           <EditTodo />
          </span>
         <button
            type="button"
            className="btn btn-danger float-end"
         >Delete
         </button>
       </div>
  </div>
)}

• In the code above, we call the todos getter that contains our data which comes in an array format.

• Next, we make use of the map array method to loop through the data, restructured the data by making use of curly brackets {}, and then extract the todos as well as the id.

• Finally, we called the key attribute in React, pass in the id so as enable React to track the data loaded on the page. The static text beside the   also gets cleared before replacing it with the todo data.

We can now proceed to save our changes.

Deleting Data from the Firestore in React

To implement the delete functionality, we need to import two firestore functions which are doc, deleteDoc.

import { collection, addDoc, serverTimestamp, getDocs, doc, deleteDoc } from 'firebase/firestore'

Next, we create a function called deleteTodo:

//Delete Handler
const deleteTodo = async (id) => {
    try {
      if (window.confirm("Are you sure you want to delete this Task!"))
    {
    const documentRef = doc(db, "todo", id);
    await deleteDoc(documentRef)
    window.location.reload()
    }
    } catch (err) {
      console.log(err);
    }
}

Within the try block, we start by displaying a prompt to the user if they want to proceed to delete the Todo.
We then create a new variable called documentRef. We then call the doc method which requires 3 arguments which are the firebase service, the collection name as well as the todo id that we want to delete.
Next, we call the deleteDoc method from firestore and then pass in the documentRef as an argument. This will enable the specific todo to be deleted from the database. Once this is done, we refresh the page by calling the window.location.reload(); function.
We then use the catch block to handle any possible error by login into the console.

Now that our delete function is ready, all we have to do is to initialize it inside our delete button as seen below:

<button
   type="button"
   className="btn btn-danger float-end"
   onClick={() => deleteTodo(id)}
   >Delete
</button>

All we did was make use of the onClick event handler to call the deleteTodo() function anytime a specific todo is deleted. It should also be noted that the id parameter passed inside of the function was made accessible to us in the documentRef variable we created earlier.

Updating Data in the Firestore in React

To implement the functionality to update data, we need to pass the data coming from the database as props to our EditTodo.js component:

{todos.map(({ todo, id }) =>
 <div className="todo-list" key={id}>
   <div className="todo-item">
    <hr />
     <span>
     <div className="checker" >
     <span className="" >
     <input
       type="checkbox"
     />
      </span>
      </div>
        &nbsp;{todo}<br />
        <i>10/11/2022</i>
      </span>
      <span className=" float-end mx-3">
       <EditTodo todo={todo} id={id} />
        </span>
    <button
       type="button"
        className="btn btn-danger float-end"
        onClick={() => deleteTodo(id)}
     >Delete
    </button>
    </div>
   </div>
)}

We passed both the todo data as well as the id as props and it now becomes accessible in the EditTodo.js file.

Inside the EditTodo.js, we extract the data by making use of curly brackets {}:

const EditTodo = ({ todo, id }) => {

We then make the necessary imports required to update the data, which include the following React and firebase terms:

useState (React Hook)
db (The Firebase Service instance)
doc (The Firestore Document reference)
updateDoc (Used to update a Document inside of a Collection)

The extracted data can now be set in state using the useState hook:

const [todos, setTodos] = useState([todo])

As seen above, we created new variables called todos, setTodos, and then set the initial value in the useState to the todo data coming from the database.

Next, we create the function that implements the update todo:

const updateTodo = async (e) => {
 e.preventDefault()
 try {
    const todoDocument = doc(db, "todo", id);
    await updateDoc(todoDocument, {
    todo: todos
   });
     window.location.reload();
   } catch (err) {
     console.log(err);
   }
 }

Above, we created a variable called updateTodo, which holds the asynchronous arrow function.
Next, we called the e.preventDefault(), to prevent the form from reloading.
Then we create a try/catch block. Within the try block, we create a variable called todoDocument. This variable holds document reference which requires 3 arguments(db, todo, id). With this, we are able to update a specific todo from the firebase database using its id.
In the next line, we call the updateDoc method that updates data in the firestore. This method takes two arguments. The first argument is the todoDocument, while the second is the updated todos text value which was the getter that was created earlier in the useState hook.
Lastly, we refresh the page when the request is successful or display an error on the console if one occurs.

There are two implementations left to do. One is making the modal dynamic, while the other is calling our update data function in the JSX.

To make the modal dynamic, we need to change the values of the id in the JSX, so we add the following code:

<button
   type="button"
   className="btn btn-primary"
   data-bs-toggle="modal"
   data-bs-target={`#id${id}`}      >
       Edit Todo
 </button>

<div
   className="modal fade"
   id={`id${id}`}
   tabIndex="-1"
   aria-labelledby="editLabel"
   aria-hidden="true">
   <div className="modal-dialog">
   <div className="modal-content">
   <div className="modal-header">
     <h5 className="modal-title" id="editLabel">Update Todo Details</h5>
   <button
     type="button"
     className="btn-close"
     data-bs-dismiss="modal"
     aria-label="Close">
   </button>
</div>

We begin by replacing the static text in the data-bs-target attribute called #exampleModal, with the dynamic id coming from the firestore.
Within our modal, we replace the static id called id="exampleModal", with the id from our firestore. The modal is now dynamic.

Next, to update the data, we need to call the setTodos setter inside the input field using the onChange event handler in React:

<input
   type="text"
   className="form-control"
   defaultValue={todo}
   onChange={e => setTodos(e.target.value)}
/>

The defaultValue helps to refill the form with the existing todo in the database.
The onChange event handler helps to get the values of the input field and save it into the setTodos setter.

Finally, we can call the updateTodo function inside our submit button:

<div className="modal-footer">
 <button
    type="button"
    className="btn btn-secondary"
    data-bs-dismiss="modal">
        Close
 </button>
 <button
    type="button"
    className="btn btn-primary"
    onClick={e => updateTodo(e)}
 >Update Todo
 </button>
</div>

As seen above, we can now successfully update a specific todo using the onClick event handler in React.

How to Integrate the Checkbox Functionality

To begin the checkbox implementation, we will create a variable using the useState hook:

const [checked, setChecked] = useState([]);

Next, we pass the data from the firestore into the setter called setChecked inside of the useEffect:

useEffect(() => {
 const getTodo = async () => {
    await getDocs(collectionRef).then((todo) => {
    let todoData = todo.docs.map((doc) => ({ ...doc.data(), id: 
     doc.id }))
    setTodo(todoData)
    setChecked(todoData)
   }).catch((err) => {
      console.log(err);
   })
  }
      getTodo()
}, [])

In the JSX, we will extract the isChecked value in the database and use it to conditionally set the CSS class used to line-through a specific todo which signifies the todo is done as seen below:

{todos.map(({ todo, id, isChecked }) =>
<div className="todo-list" key={id}>
<div className="todo-item">
<hr />
<span className={`${isChecked === true ? 'done' : ''}`}>

We proceed to configure the input field used for our checkbox by using the following code:

<input
  type="checkbox"
  defaultChecked={isChecked}
  name={id}
  onChange={(event) => checkHandler(event, todo)}
/>

Above we use the defaultChecked attribute to set the default value of the checkbox coming from the firestore which is a Boolean.
Next, we pass in the id into the name attribute.
Using the onChange event handler, we set the event and the todo data into a function called checkHandler, which we will create and configure below:

//Checkbox Handler
const checkHandler = async (event, todo) => {
 setChecked(state => {
 const indexToUpdate = state.findIndex(checkBox => checkBox.id.toString() === event.target.name);
 let newState = state.slice()
 newState.splice(indexToUpdate, 1, {
 ...state[indexToUpdate],
  isChecked: !state[indexToUpdate].isChecked,
 })
 setTodo(newState)
 return newState
});

The summary of the above function helps to track the state of a specific checkbox when checked and unchecked by using the findIndex method in JavaScript.
We then create a variable called newState. This variable makes use of the slice() and splice() methods in JavaScript. The slice() method helps us to return the selected checkbox(s) in the array, as a new array, while the splice() method helps us to save only elements that were checked into the array.
Next, we then save the newly modified array into the setTodo setter before we return data using the return keyword.

The final step we need to take is to save the selected checkbox values in the database. We will do this by, making use of the runTransaction method in JavaScript. The runTransaction method will be called within the checkHandler function:

// Persisting the checked value
try {
const docRef = doc(db, "todo", event.target.name);
await runTransaction(db, async (transaction) => {
      const todoDoc = await transaction.get(docRef);
        if (!todoDoc.exists()) {
           throw "Document does not exist!";
        }
      const newValue = !todoDoc.data().isChecked;
      transaction.update(docRef, { isChecked: newValue });
     });
      console.log("Transaction successfully committed!");
     } catch (error) {
       console.log("Transaction failed: ", error);
}

The first thing we need to do is import runTransaction from firebase/firestore.
We then checked the database if the particular document being queried exists or not. If it doesn't exist we throw a message that says "Document does not exist!".
If the document exists, we call the transaction.update method and then pass in the value of the isChecked variable which then updates it in the firestore database.

Gif showing runTransaction in action

How to order Data by Timestamp in Firebase

To order the data in our firestore database, the first thing to do is to clear all the current data we currently have by deleting the entire collection on the Firebase Database. This will allow the newly created documents to get ordered correctly.

We then need to import two methods from firebase/firestore called orderBy and query by using the following imports:

import { collection, addDoc, serverTimestamp, getDocs, doc, deleteDoc, runTransaction, orderBy, query } from 'firebase/firestore'

The orderBy method helps to sort the data coming from the database in either ascending, descending, or timestamp in which the data was created. In our case, we will be making use of the latter, while the query method as the name implies allows us to query data from the database.

Next, within the useEffect, we will remove the collectionRef we passed as a parameter into the getDocs method and replace it with a newly created query variable as seen below:

const q = query(collectionRef, orderBy('timestamp'))
          await getDocs(q).then((todo) =>{

Above, we create a variable called q, which uses the orderBy method to sort the data by the in which they were created. We then pass this variable to the getDocs method that gets the data from the Database.

To conclude this project, we will display the date and time on which the todo was created on the browser:

{todos.map(({ todo, id, isChecked, timestamp }) =>

We begin by extracting the timestamp value from the database.

We then need to clear the static date value inside of the italics(<li></li>) tag:

<i>{new Date(timestamp.seconds * 1000).toLocaleString()}</i>

We created a Date object and then get the seconds from the timestamp while multiplying it by 1000. This is because JavaScript works with time in milliseconds. We then proceed to use the toLocaleString() method to return the date object as a string.

With this, we have the result below:

Results showing the todo by timestamp as well as the dates created

Conclusion

You have now completed the tutorial! You now know the basics of how to create a todo application using React and Firebase Database. Now you can proceed to build your own web app from scratch and then integrate additional functionalities like firebase login and sign-in, Firebase tools, firebase deploy, and other firebase services into your React application.

Also, the link to the complete source code of this article can be found on this Github repository.

Angular Interceptors to Manage HTTP Requests ⚡

Hugo Noro — Sat, 29 Jan 2022 14:18:30 +0000

Angular as a framework provides us with a significant number of tools and capabilities out of the box. Today I will be writing about one of these beneficial features called HTTP Interceptors.

I will briefly describe what Angular HTTP Interceptors are and how they work. I will then provide some common usages with implementation examples and discuss some advantages of using interceptors on your app. This article assumes that the reader already has some Angular experience and is comfortable around the most common and basic notions. These will not be explained in detail since they are not in the scope of this document.

What is an Angular interceptor, after all?

Although the name might sound like something extraordinarily fancy and complicated, Angular interceptors are merely a special kind of HTTP client service that has the sole purpose of intercepting every HTTP request performed. This is true for both incoming and outgoing HTTP requests. OK, I've seen this quick definition in several places, but what does that exactly mean? How does it work?

We all know a picture is worth a thousand words so let's try and create a simple diagram that will explain what intercepting a request means:

A typical workflow of an Angular app, at any point in time, will perform a series of HTTP requests to a server to perform everyday tasks. These are authentication, data loading, etc. We will come back to this in a moment.

The diagram above shows that the HTTP interceptors will always be in the middle of any single HTTP request. These services will intercept all requests performed by the app, allowing us to perform many operations on them before they are sent to the server. Functions include adding a custom HTTP header to the final outgoing request (e.g. adding an authorization header and passing an authorization token on all endpoints requiring a set of permissions, etc.), caching, logging to collect metrics, error handling, etc.

A similar process happens when the server replies. We now have the response being intercepted by the HTTP interceptor, allowing us to perform a series of operations before the app consumes the final answer. An everyday use case scenario could be transforming the response object into a format more meaningful to the product. For example, cleaning up the response object and extracting only the required parts instead of dealing with that on every component that would use the data.

OK, I guess by now, it's clear what an HTTP interceptor is, where it sits on an everyday Angular app workflow, and its purpose. But how does this work? Don't we risk having multiple requests modified all over the place and causing a chaotic set of events going back and forth?

How does interceptor work?

Setting up a piece of logic that can transform HTTP requests in a centralized place sounds like a great feature. This way, we don't have to create several layers of duplication whenever we want to perform a request or consume a response. Without interceptors, we would need to implement the same logic repeatedly for each HTTP request being performed by hand!

Although for all this to be possible, there's a critical piece of knowledge that needs to be present at all times. From the Angular documentation:

Although interceptors can modify requests and responses, the HttpRequest and HttpResponse instance properties are readonly, rendering them largely immutable. They are immutable for a good reason: an app might retry a request several times before it succeeds, which means that the interceptor chain can re-process the same request multiple times. If an interceptor could modify the original request object, the re-tried operation would start from the modified request rather than the original. Immutability ensures that interceptors see the same request for each try.

This information is vital to understand that we will always need to create a new request copy with the intended changes to ensure a deterministic workflow. This will be helpful to understand why the implementation always needs to call the clone method and then transform the request before passing it through.

Can we have multiple interceptors?

Yes! An app can have multiple interceptors, each dealing with its scope of action. For example, we can have an interceptor dedicated to coping with auth, one dealing with error handling, a third dealing with logging, etc. This is only possible because Angular has an intelligent way of processing the requests. According to the Angular documentation:

Angular applies interceptors in the order that you provide them. For example, consider a situation in which you want to handle the authentication of your HTTP requests and log them before sending them to a server. To accomplish this task, you could provide an AuthInterceptor service and then a LoggingInterceptor service. Outgoing requests would flow from the AuthInterceptor to the LoggingInterceptor. Responses from these requests would flow in the other direction, from LoggingInterceptor back to AuthInterceptor.

The following diagram could represent the use case described:

Although only the user configured the auth and logging interceptors, Angular has another interceptor for default handling all back-end server calls. This interceptor is called HTTP backend and is always the last on the execution chain, independently of how many other interceptors are created and configured by the user.

It's crucial to understand that once the order of execution of this chain is established, it cannot be changed. You also cannot remove or disable an interceptor on the fly. From the Angular documentation:

You cannot change the order or remove interceptors later. If you need to enable and disable an interceptor dynamically, you'll have to build that capability into the interceptor itself.

Why is it so essential to understand this? Because they will consistently execute the request in the same order, they were configured. This could make a big difference when thinking about what order should be used to avoid surprises when expecting a detailed response and receiving a different one because the interceptor that executed it before in the chain already transformed it.

How to implement it?

Now that we have a basic idea of an interceptor and its primary purpose, it's time to talk about implementation. How to implement an Angular HTTP interceptor? I will be showing a few examples of the most common use cases, such as adding custom HTTP headers, caching, logging, and error handling.

Initial Setup

Since the scope of this document is around HTTP interceptors, I am assuming the reader would have a previously created Angular project.

Now create a new interceptor using Angular CLI and briefly discuss it on your existing project. As mentioned before, an interceptor is nothing more than an Angular service that implements a specific interface. Let's run the following command: ng generate interceptor example.

This CLI command will create an interceptor called ExampleInterceptor with the following code:

import { Injectable } from '@angular/core';
import {
  HttpRequest,
  HttpHandler,
  HttpEvent,
  HttpInterceptor
} from '@angular/common/http';
import { Observable } from 'rxjs';

@Injectable()
export class ExampleInterceptor implements HttpInterceptor {

  constructor() {}

  intercept(request: HttpRequest<unknown>, next: HttpHandler): Observable<HttpEvent<unknown>> {
    return next.handle(request);
  }
}

As we can see, an interceptor service implements the HttpInterceptor interface, imported from the Angular common module. We need to implement the intercept method with our customized code for each use case. This method receives an HTTP request performed by the app and the handler executing the chain of calls. If no custom transformations are in place, it will simply pass it through to the handle method (next.handle(request)) and repeat the same process on all the subsequent configured interceptors (as explained in the workflow diagram above).

Custom Header Interceptor

One of the most common use cases for interceptors is handling auth requests. This can be achieved easily by adding the required headers to the outgoing request inside the intercept method.

The examples provided are, of course, using mocked examples of security tokens. The main goal is to show the reader how to implement auth interceptors by adding custom headers to the requests. In this scenario, we will be adding an authorization token. The examples discussed below should be easily adaptable to a real-world application with a proper authentication system.

Basic Authentication

Consider a Basic Authentication scenario where we must authorize every request accessing the API. We could have an interceptor like the following:

import { Injectable } from '@angular/core';
import {
  HttpRequest,
  HttpHandler,
  HttpEvent,
  HttpInterceptor
} from '@angular/common/http';
import { Store } from '@ngxs/store';
import { Observable } from 'rxjs';
import { AuthState } from '../../store/auth.state';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private authService: AuthService) {}

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    return next.handle(this.addAuthToken(request));
  }

  addAuthToken(request: HttpRequest<any>) {
    const token = this.authService.getAuthToken();

    return request.clone({
        setHeaders: {
          Authorization: `Basic ${token}`
        }
    })
  }
}

Basic Authentication Breakdown

Let's now break down in steps what's happening here:

For the sake of this example, we are assuming there is one authorization service responsible for maintaining and providing basic authentication tokens. We inject the service on the constructor to be available whenever needed in the service. The implementation of this service is not part of our goal, being out of the scope of this article.

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  return next.handle(this.addAuthToken(request));
}

Our intercept method is relatively lean, having just one call to the function responsible for transforming the request by adding a new header.

addAuthToken(request: HttpRequest<any>) {
    const token = this.appService.getAuthToken();

    return request.clone({
        setHeaders: {
          Authorization: `Basic ${token}`
        }
    })
  }

Finally, the addAuthToken method will ask for a new token and set the header 'Authorization' by defining it as 'Basic'. One critical aspect for retaining in this small piece of logic is the call to the method request.clone(). As mentioned before, all requests are immutable, so this is the correct way of transforming an existing request by creating a new version with the intended modifications.

A fully working example can be checked here. When clicking on the button 'Basic Authentication', we can verify in the dev tools, in the network panel, that the authorization header was added with the 'superSecretToken' provided by the authorization service:

JWT Authentication

The previous example was simple enough to explain how to create a trivial request transformation inside the intercept function and create a new request with the new auth header.

Although apart from a small number of use cases, in the current days, 'Basic Authentication' is not a common scenario for most apps.

One common usage of the auth interceptor would be handling requests dealing with a JWT token. I will start by showing a typical implementation and then break it down into steps for more clarity.

Let's consider a use case where we have an app with JWT authentication with refresh token support:

import {
  HttpErrorResponse,
  HttpEvent,
  HttpHandler,
  HttpInterceptor,
  HttpRequest,
} from '@angular/common/http';
import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable, throwError } from 'rxjs';
import { catchError, filter, finalize, switchMap, take } from 'rxjs/operators';
import { AuthService } from './auth.service';

@Injectable()
export class JwtAuthService implements HttpInterceptor {
  private refreshTokenInProgress = false;
  private refreshTokenSubject = new BehaviorSubject(null);

  constructor(private authService: AuthService) {}

  intercept(
    request: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    return next.handle(this.addAuthToken(request)).pipe(
      catchError((requestError: HttpErrorResponse) => {
        if (requestError && requestError.status === 401) {
          if (this.refreshTokenInProgress) {
            return this.refreshTokenSubject.pipe(
              filter((result) => result),
              take(1),
              switchMap(() => next.handle(this.addAuthToken(request)))
            );
          } else {
            this.refreshTokenInProgress = true;
            this.refreshTokenSubject.next(null);

            return this.authService.refreshAuthToken().pipe(
              switchMap((token) => {
                this.refreshTokenSubject.next(token);
                return next.handle(this.addAuthToken(request));
              }),
              finalize(() => (this.refreshTokenInProgress = false))
            );
          }
        } else {
          return throwError(() => new Error(requestError.message));
        }
      })
    );
  }

  addAuthToken(request: HttpRequest<any>) {
    const token = this.authService.getAuthToken();

    if (!token) {
      return request;
    }

    return request.clone({
      setHeaders: {
        Authorization: `Bearer ${token}`,
      },
    });
  }
}

JWT Authentication Breakdown

This example is considerably more complex than the basic authentication one, but let's break it into small parts, and it will seem a lot less overwhelming.

  private refreshTokenInProgress = false;
  private refreshTokenSubject = new BehaviorSubject(null);

When working with JWT, it is standard to make usage of a refresh token. It's one of the practices used. In our interceptor, we will be using a Boolean variable to store a temporary state. At the same time, a refresh token is being loaded and a Behaviour Subject to keep the state of the last change. We are, of course, initializing it to null since when loading the application, until the user authentication is completed successfully, a token will not be created.

return next.handle(this.addAuthToken(request)).pipe(
      catchError((requestError: HttpErrorResponse) => {

This call of the intercept method is a bit different than the one on the minor example. When a user tries to perform a request to an API or a view of an app to which it has not yet been authorized on a properly designed product, will receive an exception with the HTTP error code 401. Knowing this, the correct way to handle the workflow on the interceptor is to capture the exceptions and process the request according to the type of exception triggered.

if (requestError && requestError.status === 401) {
  if (this.refreshTokenInProgress) {
    return this.refreshTokenSubject.pipe(
      filter((result) => result),
      take(1),
      switchMap(() => next.handle(this.addAuthToken(request)))
    );
  }

If the user tries to access an API without the expected authorization will get an exception with status code 401 (unauthorized). At this point, some additional checks need to be done to decide how to proceed with the request. If we already have a new refresh token being processed, the workflow will wait until the token is available and provided to the behavior subject. Once it is finally available, we add the token to the header and pass the transformed request through.

else {
  this.refreshTokenInProgress = true;
  this.refreshTokenSubject.next(null);

  return this.authService.refreshAuthToken().pipe(
    switchMap((token) => {
      this.refreshTokenSubject.next(token);
      return next.handle(this.addAuthToken(request));
    }),
    finalize(() => (this.refreshTokenInProgress = false))
  );
}

When no refresh token has been requested yet, a new process starts. We start by flagging the application that a new refresh token request is now in place, and we ensure that no unexpected value is pending on the behavior subject by setting it to null. This will ensure the request will wait until a token is provided (as shown in the former example).

The only thing left to do is now request a new refresh token, emit it to the refresh token subject as soon as it's available and then add the token to the request header.

Finally, we need to ensure we leave the process clean, so we reset the refresh token flag to false.

else {
  return throwError(() => new Error(requestError.message));
}

For the scope of this example, if the error status code is not 401, we throw the error up to potentially be caught by a dedicated error interceptor.

Caching Interceptor

Caching is itself a considerably broad and complex subject. Some configurations and nuances can significantly improve application performance or be the root of a significant number of problems when poorly implemented.

Angular documentation provides a comprehensive example of how to implement a caching interceptor. However, it can be overwhelming for the reader who is going through the first steps of implementing an interceptor. This section will provide a simplified version to explain how it works.

Angular interceptors can handle HTTP requests themselves without passing them through to the next request handler. We can take advantage of this feature by setting some requests in the cache to improve performance and user experience by reducing the number of times needed to travel to the server.

A simplified caching interceptor could be implemented as follows:

import {
  HttpEvent,
  HttpHandler,
  HttpInterceptor,
  HttpRequest,
  HttpResponse,
} from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable, of, tap } from 'rxjs';

@Injectable()
export class CachingInterceptor implements HttpInterceptor {
  private cache = new Map<string, any>();

  intercept(
    request: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    if (request.method !== 'GET') {
      return next.handle(request);
    }
    const cachedResponse = this.cache.get(request.url);
    if (cachedResponse) {
      return of(cachedResponse);
    }

    return next.handle(request).pipe(
      tap((response) => {
        if (response instanceof HttpResponse) {
          this.cache.set(request.url, response);
        }
      })
    );
  }
}

Our cache is defined by a Map structure that will store a key-value pair. In our simplistic example, the cache will store a URL as the key and result of the response call to the sample API. We are only caching 'GET' requests since these are idempotent. This means that for the exact same input, no matter how many times a request is made, it should produce the same output.

const cachedResponse = this.cache.get(request.url);
if (cachedResponse) {
  return of(cachedResponse);
}

We start by getting an existing cached response for the requested URL. When we have a cache hit, we return the response previously stored.

return next.handle(request).pipe(
  tap((response) => {
    if (response instanceof HttpResponse) {
      this.cache.set(request.url, response);
    }
  })
);

We pass the request through to the server on a cache miss and store the response in the cache. This is possible because, as explained initially, interceptors can handle both HTTP requests and HTTP responses together.

A fully working example can be found here. The first time the button 'Cached Request' is clicked, it will perform a request to the API. This can be verified on the developer tools network panel. Any subsequent clicks on the button will not trigger any additional requests. This can be tested by clicking the 'Clear Data' button and then clicking the 'Cached Request' button again. Although the displayed data gets cleared and shows again, no new requests are made to the server API. After the first request, all the others will return from the cache.

Logging Interceptor

Modern-day applications usually provide a significant number of features to the end-users. The more complex these applications are, the more error-prone they can become. Collecting meaningful data from an entire HTTP operation or specific properties from user data will allow insightful and dynamic thinking on producing some valuable statistics. These can measure the average request elapsed time for detecting potential bottlenecks or logging requests input data for detecting malformed requests that are triggering unexpected responses. There are hundreds of other valuable scenarios where logging could be helpful.

For this example, we will use the implementation provided on Angular documentation and break it down:

import {
  HttpHandler,
  HttpInterceptor,
  HttpRequest,
  HttpResponse,
} from '@angular/common/http';
import { Injectable } from '@angular/core';
import { finalize, tap } from 'rxjs';
import { MessageService } from './message.service';

@Injectable()
export class LoggingInterceptor implements HttpInterceptor {
  constructor(private messageService: MessageService) {}

  intercept(req: HttpRequest<any>, next: HttpHandler) {
    const started = Date.now();
    let ok: string;

    return next.handle(req).pipe(
      tap({
        next: (event) =>
          (ok = event instanceof HttpResponse ? 'succeeded' : ''),
        error: (error) => (ok = 'failed'),
      }),

      finalize(() => {
        const elapsed = Date.now() - started;
        const msg = `${req.method} "${req.urlWithParams}"
             ${ok} in ${elapsed} ms.`;
        this.messageService.add(msg);
      })
    );
  }
}

const started = Date.now();
let ok: string;

We start by defining the moment the request was intercepted and a variable to store the outcome of the backend server response.

tap({
  next: (event) =>
    (ok = event instanceof HttpResponse ? 'succeeded' : ''),
  error: (error) => (ok = 'failed'),
}),

Since interceptors can handle both an outgoing request and an incoming response, let's store the outcome in our previously defined variable. Depending on the backend server returning a success or an error, the variable will print either 'succeeded' or 'failed'.

finalize(() => {
  const elapsed = Date.now() - started;
  const msg = `${req.method} "${req.urlWithParams}"
    ${ok} in ${elapsed} ms.`;
  this.messageService.add(msg);
})

The finalize method always executes, independently of the observable returning a success or an error response. This will then be the perfect place to calculate how long the request took in total and, for this example, to create a message with the elapsed time and the response status.

A fully working example can be found here. By clicking the 'Cached Request' button, it will log in to the console the time elapsed for the request and the status.

The curious reader will attempt to click the button several times, but no more logs will be displayed on the console. Why is this happening? As a hint, try to look at the 'app.module' file and see how the interceptors are declared and in which order. Does the order make any difference? Try placing the logging interceptor before the caching interceptor and observe the results.

Error Handling Interceptor

Errors from an API response to an HTTP call are never desirable for any application. Nevertheless, the best way of dealing with them is to assume they can (and will happen) and provide an elegant way to handle them. Failed requests can happen for many reasons, and the last thing an end-user would want to receive is a broken view or a considerable number of errors being displayed.

An elegant solution can be implemented by creating an error handler to intercept all HTTP errors.

import {
  HttpEvent,
  HttpHandler,
  HttpInterceptor,
  HttpRequest,
} from '@angular/common/http';
import { Injectable } from '@angular/core';
import { MessageService } from 'primeng/api';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

@Injectable()
export class ErrorInterceptor implements HttpInterceptor {
  constructor(private messageService: MessageService) {}

  intercept(
    request: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    return next.handle(request).pipe(
      catchError((requestError) => {
        if (requestError.status !== 401) {
          const { error } = requestError;
          this.messageService.add({
            severity: 'error',
            summary: `HTTP Error - ${requestError.status}`,
            detail: error && error.message,
          });
        }
        return throwError(() => new Error(requestError));
      })
    );
  }
}

There's not much explanation needed since the code should be self-explanatory. The only detail that is important to discuss is filtering the errors. We are only dealing with errors in which the HTTP response is different from 401.

Why is this? At the beginning of this article, I mentioned that it is possible to have multiple interceptors, executing them in a chained process. Since we already have the auth interceptor coping with all the 401 errors and processing those requests, there's no point in managing them on this interceptor also.

When an error is received, this example merely displays a toast with the error message to the user, but this would be the perfect place to format or create customized notifications based on specific errors.

Conclusion

Angular 4.3 simplified everyone's lives by adding the HTTP interceptors to the HTTP client library. The ability to handle outgoing requests and incoming responses in the same place together opened many possibilities such as the ones discussed and demonstrated above.

The examples provided are only the tip of the iceberg of all possibilities. The main goal was to show the reader how to implement and cope with the most standard use cases around any modern-day application.

The critical concepts are that interceptors can handle incoming and outgoing requests, can transform them by creating a new mutated request, and can themselves return without passing the request to the next interceptor. The latter should probably be used sparingly, but it's essential to know it can be done.

If you are interested in learning more about building secure Web applications consider joining our flagship program WebSecurity Academy. It will teach you everything you need to know in that area.

The Ultimate Guide to Angular User Login and Registration (Cookies, JWT)

Bartosz Pietrucha — Mon, 01 Mar 2021 18:04:32 +0000

In this guide, we will design and implement a complete solution for user authentication including user login, registration, and account confirmation with the Angular framework. We will learn how to structure the application with a separate module responsible for the visual and logical parts of user authentication. The proposed approach will be robust and flexible to address the most demanding requirements in modern Web applications.

Apart from the frontend implementation of our use cases, we will compare different approaches for performing user authentication used in today's Web. We will discuss distinct scenarios for application deployment and find an appropriate and most secure approach for our needs. By the end of this tutorial, you will have a simple yet adaptable Angular login example, that you could tweak to your specific needs. The code will be written for Angular 2+ and relevant to all newer versions (including Angular 11), but the discussed concepts also apply for AngularJS authentication.

Application structure and solution design

To find a proper place in the application for implementing authentication features, we need to take a step back and think about Angular application architecture and modular design. Our application is going to be divided into feature modules, each composed of presentational and logical parts. Most of the code we will have for this tutorial will belong to AuthModule. This module will contain:

routable container components for login, signup, and confirmation page,
two router guards,
a couple of fine-grained services
routing configuration
http interceptor

The next application-wide consideration is top-level routing. We want to divide the application into authentication and application parts. This will simplify the routes tree and later on allow us to create two distinct router guards to apply proper route activation policies.

const routes: Routes = [
  { path: '', redirectTo: '/login', pathMatch: 'full' },
  {
    path: 'app',
    canActivate: [AppGuard],
    component: LayoutComponent,
    children: [
      { path: 'dashboard', component: DashboardComponent },
      { path: 'expenses', component: ExpensesComponent },
      { path: 'settings', component: SettingsComponent) }
    ]
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Before jumping into implementation we need to answer the last very important question. Since HTTP protocol is a stateless request-response protocol, we need to have a way of maintaining the user's context after successful login. In this article, I will describe the two most used approaches: cookie-based sessions and self-contained tokens.

A cookie-based session is based on the user's context maintained on the server-side. Each context can be identified by a session identifier, which is randomly generated for each browser and placed in a cookie. When we use the HttpOnly flag on that cookie, we are preventing our system from cross-site scripting attacks but still, we need to think about cross-site request forgery attacks. The cookie-based approach is very handy when our frontend application and backend API are hosted on the same origin (the same domain and port). This is because of the fundamental rule of the Web Security model, Same-origin policy, that would not allow us to share the same cookies across multiple backends. In other words, cookies are scoped per single domain.

The second approach may be useful when our system is deployed on separate origins: the frontend application is hosted on a different domain than backend API. In this case, the requests from the frontend to the backend would be considered cross-origin requests, and the cookies set on the backend origin called third-party cookies. A third-party cookie is the same mechanism that is used by analytical and tracking systems and can be easily turned off in modern browsers. A lot of users opt-out of third-party cookies as they are concerned about their privacy on the Internet. Also, some browser vendors are putting major efforts into eradicating third-party cookies completely.

So what should we do in such a case? We can use another way of providing the user's context between requests - HTTP Authorization Header. This requires programmatic reading, storing, and attaching an authorization token transported via header (as opposed to cookies). Just to put us on the same page, remember that session-id used in cookies is also a token, but an opaque one - it does not convey any information and is just a key to retrieve the session on the server. Another type of token is called a self-contained token, which we can put the user's context inside of. In 2015 Internet Engineering Task Force standardized JSON Web Token (JWT) that can securely transport information between the parties. Thanks to a cryptographic signature we can assume that the content of the JWT is authentic and integral. A self-contained nature of JWT allows us to retrieve user context, like permissions and credentials, without a need to maintain the session on the server (think of serverless and Function-as-a-Service). We can also integrate with third-party services without the restrictions of the same-origin policy (for example Firebase or AWS Amplify). I covered a more detailed explanation of JSON Web Tokens here.

I believe that it is very important to understand the fundamental differences between these two mechanisms, before implementing user authentication in the application. You can also check out my YouTube videos exploring the differences between these two approaches and the ways JWT can be hacked. We will build our frontend able to utilize both session cookies and token authentication with JSON Web Tokens. I told you it would be flexible! 🤓

WARNING: Whenever you are using any kind of authorization token that you store in LocalStorage or IndexedDB (so it's accessible by JavaScript code) you are exposing the token to be hijacked via cross-site scripting attack. However, there are valid mitigation techniques, like Content Security Policy, Subresource integrity, and built-in frameworks' sanitization mechanisms, that (when applied properly!) reduce that risk to a negligible degree. That being said that risk is real, so you should pay enough attention to those security issues.

Detailed implementation

Login feature

Let's start with the UI part - login component template. Our approach for user authentication is based on the pair of email and password, so we need two input items in the template. Note that the second input has an attribute type="password", which instructs the browser to render a masked input element. We also make use of Angular Material to provide a nice look-and-feel to the user interface. Below you can find our login form example.

<form [formGroup]="loginForm">

  <div class="header">Login to your account</div>

  <mat-form-field>
    <input matInput type="email" id="email" placeholder="Email" autocomplete="off" formControlName="email" required>
  </mat-form-field>

  <mat-form-field>
    <input matInput type="password" id="password" placeholder="Password" autocomplete="off" formControlName="password" required>
  </mat-form-field>

  <div class="actions">
    <button mat-flat-button color="primary" type="submit" (click)="login()" [disabled]="!loginForm.valid">Login</button>
    <div class="separator">
      <span>OR</span>
    </div>
    <button mat-stroked-button type="button" routerLink="/signup">Sign up</button>
  </div>

</form>

Now the question is: how to take input values from the user to execute the login? To link the HTML form and input elements in the view with the component code we can utilize some directives from the Reactive Forms module. By using FormGroupDirective in this way [formGroup]="loginForm", we are telling Angular that there is a property loginForm in the component that should hold an instance of that form. We are using FormBuilder to create email and password instances of FormControl. Email control is also equipped with a built-in email validator.

@Component({
  selector: 'app-login',
  templateUrl: './login.component.html'
})
export class LoginComponent implements OnInit {

  loginForm: FormGroup;

  constructor(private authService: AuthService,
    private formBuilder: FormBuilder,
    private router: Router) { }

  ngOnInit() {
    this.loginForm = this.formBuilder.group({
      email: ['', Validators.email],
      password: ['']
    });
  }

  get f() { return this.loginForm.controls; }

  login() {
    const loginRequest: LoginRequest = {
      email: this.f.email.value,
      password: this.f.password.value
    };

    this.authService.login(loginRequest)
      .subscribe((user) => this.router.navigate([this.authService.INITIAL_PATH]));
  }

}

The next step is to execute the underlying requests to perform the actual login once the button is clicked. Since we want to handle both cookie-based sessions and JWT tokens, we are decoupling HTTP requests from handling logic with the AuthStrategy interface. Depending on the chosen mechanism the actual implementation of AuthStrategy is injected in AuthService. This is possible thanks to the config setting that dictates which implementation of AuthStrategy is used. Below you can find that interface with actual implementations for cookies and JWT. Note that the authStrategyProvider factory method is used to register the provider in AuthModule.

auth.strategy.ts

export interface AuthStrategy<T> {

  doLoginUser(data: T): void;

  doLogoutUser(): void;

  getCurrentUser(): Observable<User>;

}

export const AUTH_STRATEGY = new InjectionToken<AuthStrategy<any>>('AuthStrategy');

export const authStrategyProvider = {
  provide: AUTH_STRATEGY,
  deps: [HttpClient],
  useFactory: (http: HttpClient) => {
    switch (config.auth) {
        case 'session':
          return new SessionAuthStrategy(http);
        case 'token':
          return new JwtAuthStrategy();
      }
  }
};

session-auth.strategy.ts

export class SessionAuthStrategy implements AuthStrategy<User> {

  private loggedUser: User;

  constructor(private http: HttpClient) {}

  doLoginUser(user: User): void {
    this.loggedUser = user;
  }

  doLogoutUser(): void {
    this.loggedUser = undefined;
  }

  getCurrentUser(): Observable<User> {
    if (this.loggedUser) {
      return of(this.loggedUser);
    } else {
      return this.http.get<User>(`${config.authUrl}/user`)
        .pipe(tap(user => this.loggedUser = user));
    }
  }
}

jwt-auth.strategy.ts

export class JwtAuthStrategy implements AuthStrategy<Token> {

  private readonly JWT_TOKEN = 'JWT_TOKEN';

  doLoginUser(token: Token): void {
    localStorage.setItem(this.JWT_TOKEN, token.jwt);
  }

  doLogoutUser(): void {
    localStorage.removeItem(this.JWT_TOKEN);
  }

  getCurrentUser(): Observable<User> {
    const token = this.getToken();
    if (token) {
      const encodedPayload = token.split('.')[1];
      const payload = window.atob(encodedPayload);
      return of(JSON.parse(payload));
    } else {
      return of(undefined);
    }
  }

  getToken() {
    return localStorage.getItem(this.JWT_TOKEN);
  }
}

As you can see above when using cookies, we don't need to handle the session-id as it is automatically put into the cookie by the browser. In the case of a JWT token authentication, we need to store it somewhere. Our implementation is putting it into LocalStorage.

Finally, to glue things together, AuthService is calling doLoginMethod on AuthStrategy after the HTTP request is executed. Note, that the final subscription to the observable stream is attached in LoginComponent and handles the last step to redirect to the initial page after login.

@Injectable({
  providedIn: 'root'
})
export class AuthService {

  public readonly LOGIN_PATH = '/login';
  public readonly CONFIRM_PATH = '/confirm';
  public readonly INITIAL_PATH = '/app/dashboard';

  constructor(
    private router: Router,
    private http: HttpClient,
    @Inject(AUTH_STRATEGY) private auth: AuthStrategy<any>
  ) { }

  signup(user: User): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/signup`, user);
  }

  confirm(email: string, code: string): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/confirm?`, {email, code});
  }

  login(loginRequest: LoginRequest): Observable<User> {
    return this.http.post<any>(`${config.authUrl}/login`, loginRequest)
      .pipe(tap(data => this.auth.doLoginUser(data)));
  }

  logout() {
    return this.http.get<any>(`${config.authUrl}/logout`)
      .pipe(tap(() => this.doLogoutUser()));
  }

  isLoggedIn$(): Observable<boolean> {
    return this.auth.getCurrentUser().pipe(
      map(user => !!user),
      catchError(() => of(false))
    );
  }

  getCurrentUser$(): Observable<User> {
    return this.auth.getCurrentUser();
  }

  private doLogoutUser() {
    this.auth.doLogoutUser();
  }

}

The approach with AuthStrategy is making the AuthService implementation very flexible, but if you don't need it, it's totally fine to go without it. The image below illustrates the composition of the presented elements.

Sign-up feature

The signup component is very alike to the login component. We have a similar template code with form and inputs. The main difference is in what happens after a successful HTTP request. Here we are just redirecting to the confirmation page from ConfirmComponent.

signup.component.html

<form [formGroup]="signupForm">

  <div class="header">Create your account</div>

  <mat-form-field>
    <input matInput type="email" id="signup_email" placeholder="Email" autocomplete="new-password" formControlName="email" required>
  </mat-form-field>

  <mat-form-field>
    <input matInput type="password" id="signup_password" placeholder="Password" autocomplete="new-password" formControlName="password" required>
  </mat-form-field>

  <div class="actions">
    <button mat-flat-button color="accent" type="submit" (click)="signup()" [disabled]="!signupForm.valid">Sign up</button>
    <div class="separator">
      <span>OR</span>
    </div>
    <button mat-stroked-button routerLink="/login">Login</button>
  </div>

</form>

signup.component.ts

@Component({
  selector: 'signup',
  templateUrl: './signup.component.html',
  styleUrls: ['./../auth.scss']
})
export class SignupComponent implements OnInit {

  signupForm: FormGroup;

  constructor(private authService: AuthService,
    private formBuilder: FormBuilder,
    private router: Router) { }

  ngOnInit() {
    this.signupForm = this.formBuilder.group({
      email: ['', Validators.email],
      password: ['']
    });
  }

  get f() { return this.signupForm.controls; }

  signup() {
    this.authService.signup(
      {
        email: this.f.email.value,
        password: this.f.password.value
      }
    ).subscribe(() => this.router.navigate([this.authService.CONFIRM_PATH]));
  }

}

Also, notice that we are not using AuthStrategy here. Signup is just sending a new pair of login and password to the backend and informing about the need for account confirmation.

Account confirmation feature

After successful signup, the user is informed about an email sent to the email address. The email contains a special link with a confirmation code. This link points to the confirmation component page in the frontend application. The ConfirmComponent is designed to work in 2 modes: before confirmation and after successful confirmation. Look at the template below and notice the isConfirmed flag in the conditional statement.

confirm.component.html

<ng-container *ngIf="!isConfirmed; else confirmed">
  <div class="header">We've sent you a confirmation link via email!</div>
  <div>Please confirm your profile.</div>
</ng-container>

<ng-template #confirmed>
  <div class="header">Your profile is confirmed!</div>
  <button mat-flat-button color="primary" routerLink="/login">Login</button>
</ng-template>

What dictates the displayed content of the component is the boolean value set in ngOnInit.

confirm.component.ts

@Component({
  selector: 'confirm',
  templateUrl: './confirm.component.html',
  styleUrls: ['./confirm.component.scss']
})
export class ConfirmComponent implements OnInit {

  isConfirmed = false;

  constructor(private activeRoute: ActivatedRoute, private authService: AuthService) { }

  ngOnInit(): void {
    const email = this.activeRoute.snapshot.queryParams.email;
    const code = this.activeRoute.snapshot.queryParams.code;

    if (email && code) {
      this.authService.confirm(email, code)
        .subscribe(() => this.isConfirmed = true);
    }
  }

}

The last missing piece is just an HTTP request to send a pair of email and corresponding confirmation code to the backend in AuthService.

Auth.service.ts - confirm()

  confirm(email: string, code: string): Observable<void> {
    return this.http.post<any>(`${config.authUrl}/confirm?`, {email, code});
  }

After successful confirmation, the page displays an incentive to log in.

WARNING: Whenever you are using some parameters passed via a link (like confirmation code or password recovery code), you need to remember about Referer headers. Only in 2020 Chrome changed the default settings of Referrer-Policy to strict-origin-when-cross-origin. Without that setting (which you can adjust to your needs) all the requests for additional resources (like analytics, widgets, images, etc.) sent from that page were containing the full URL in the Referer header. For example, when you open the confirmation link and the page contains some third-party resources, the requests to fetch them are sent with the header with the full URL including the email and code. So as a means of prevention it's always important to set a proper Referrer-Policy in your application.

User object

We came to the point where our login and registration with confirmation features are ready. Now we need to add some missing pieces to our system. The question is: how does the frontend client know who is logged in or what role does that user have? Depending on the authentication mechanism (cookie-based or token-based) the way to retrieve that information is different. Since we already have a proper abstraction over these mechanisms we can make use of the AuthStrategy interface. The method getCurrentUser will provide us with an Observable of a User object.

user.ts

import { Account } from './account';
import { Role } from './types';

export class User {
  id?: string;
  accountId?: string;
  account?: Account;
  email?: string;
  password?: string;
  role?: Role;
  confirmed?: boolean;
  tfa?: boolean;
}

Look at the implementations in both approaches. In the case of server-side sessions, if there is no local copy of a logged user, we need to ask the backend and store it locally. In the case of a JWT token-based authentication, we just need to unwrap the information from inside the token. Since we just want the payload we need to split the string with token.split('.')[1] and window.atob function decodes the base64 format of the token.

session-auth.strategy.ts - getCurrentUser()

  getCurrentUser(): Observable<User> {
    if (this.loggedUser) {
      return of(this.loggedUser);
    } else {
      return this.http.get<User>(`${config.authUrl}/user`)
        .pipe(tap(user => this.loggedUser = user));
    }
  }

jwt-auth.strategy.ts - getCurrentUser()

  getCurrentUser(): Observable<User> {
    const token = this.getToken();
    if (token) {
      const encodedPayload = token.split('.')[1];
      const payload = window.atob(encodedPayload);
      return of(JSON.parse(payload));
    } else {
      return of(undefined);
    }
  }

  getToken() {
    return localStorage.getItem(this.JWT_TOKEN);
  }

Adapting UI

Since the logged user may have some specific role assigned we need to adapt the UI accordingly. Not only the specific routes are available or unavailable, but some elements should be displayed or not. We might manually ask for the user role every time we need to know if the element should be rendered with ngIf, but there is a smarter way. What I propose is to create a custom structural directive that needs a list of roles, for which a given element should be displayed. This would provide us with an elegant way of template composition. Look at the example below. The button will be displayed only in the currently logged user has a role 'owner'.

  <div class="add">
    <button mat-fab color="primary" (click)="openExpenseDialog()" *forRoles="['owner']">+</button>
  </div>

This is possible thanks to the forRoles structural directive implementation presented below.

import { Directive, Input, ViewContainerRef, TemplateRef } from '@angular/core';
import { AuthService } from '../services/auth.service';

@Directive({
  selector: '[forRoles]'
})
export class ForRolesDirective {

  roles: string[];

  @Input()
  set forRoles(roles: string[]|string) {
    if (roles != null) {
      this.roles = Array.isArray(roles) ? roles : [roles];
      this.roles = this.roles.map(r => r.toUpperCase());
    } else {
      this.roles = [];
    }

    this.authService.getUserRole$().subscribe(
      role => {
        if (role && !this.roles.includes(role.toUpperCase())) {
          this.viewContainer.clear();
        } else {
          this.viewContainer.createEmbeddedView(this.templateRef);
        }
      }
    );
  }

  constructor(
    private viewContainer: ViewContainerRef,
    private templateRef: TemplateRef<any>,
    private authService: AuthService) { }

}

Remember that the directive needs to be declared in an Angular module. In our case, we are declaring it in AuthModule and exporting it to be available to the outside world.

Protecting routes

Users' authorization and roles dictate not only UI elements' visibility. On the higher level, we need to restrict access to the application's routes. Thanks to our top-level routing and separation into authentication and application this task is very easy. We need Router Guards that govern the access to these 2 parts.

@Injectable({
  providedIn: 'root'
})
export class AppGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) { }

  canActivate(): Observable<boolean> {
    return this.authService.isLoggedIn$().pipe(
      tap(isLoggedIn => {
        if (!isLoggedIn) { this.router.navigate(['/login']); }
      })
    );
  }
}

The logic in the AppGuard says: IF the user is not logged THEN redirect to the login page and do not allow access to the application part.

@Injectable({
  providedIn: 'root'
})
export class AuthGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) { }

  canActivate(): Observable<boolean> {
    return this.authService.isLoggedIn$().pipe(
      tap(isLoggedIn => {
        if (isLoggedIn) {
          this.router.navigate([this.authService.INITIAL_PATH]);
        }
      }),
      map(isLoggedIn => !isLoggedIn)
    );
  }
}

On the other hand, the instruction in AuthGuard is just oposite: IF the user is logged in THEN do not allow to show the login page and redirect to the default page. We have seen how to register AppGuard already in main routing. Now, the next step is to register AuthGuard in AuthRoutingModule.

const routes: Routes = [
  {
    path: 'login', component: LoginComponent,
    canActivate: [AuthGuard]
  },
  {
    path: 'signup', component: SignupComponent,
    canActivate: [AuthGuard]
  },
  {
    path: 'confirm', component: ConfirmComponent,
    canActivate: [AuthGuard]
  }
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class AuthRoutingModule { }

API requests authentication

The last element in our system is outgoing requests' authentication. When using cookies we don't need to do anything - session-id is attached in every HTTP query.

In the case of JSON Web Token, we need to have a dedicated code to add an Authentication header with a token to the requests. The handiest way is to use HttpInterceptor. Pay attention to the conditional check of the authentication mode - want to attach the token only if this is necessary.

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private authService: AuthService, @Inject(AUTH_STRATEGY) private jwt: JwtAuthStrategy) { }

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

    if (config.auth === 'token' && this.jwt && this.jwt.getToken()) {
      request = this.addToken(request, this.jwt.getToken());
    }

    return next.handle(request).pipe(catchError(error => {
      if (error.status === 401) {
        this.authService.doLogoutAndRedirectToLogin();
      }
      return throwError(error);
    }));

  }

  private addToken(request: HttpRequest<any>, token: string) {
    return request.clone({
      setHeaders: { 'Authorization': `Bearer ${token}` }
    });
  }

}

Lastly, the interceptor needs to be registered in the providers list in AuthModule as presented below.

@NgModule({
  declarations: [ ... ],
  exports: [ ... ],
  imports: [ ... ],
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: AuthInterceptor,
      multi: true
    },
    ...
  ]
})
export class AuthModule { }

Summary and next steps

Even though we have a complete and robust solution, there are plenty of enhancements we could implement in your system to improve its security.

First of all two-factor authentication (2FA) is becoming more and more relevant these days. Attackers are using different strategies to get unauthorized access to accounts like brute-force attacks, dictionary attacks, credential stuffing, session hijacking, and many more. One of the easiest ways to implement 2FA is with Google Authenticator, but this is out of this article's scope. Another way to increase the security of the login system is to throttle failed login attempts. This can be very tricky to implement because if we blindly block some user's login, attackers could be easily executing Denial-of-Service (DoS) for particular users (for example constantly using the wrong password in an automated way). There are smart solutions to prevent this to happen, like Device cookies and trusted clients.

Finally, our implementation does not have the very important feature of account recovery (password reset). The feature may be covered in future tutorials.

Is that solution secure?

Yes and no. To make things realistic we need to remember that there are plenty of security risks in Web applications. There are vulnerabilities like cross-site request forgery when using cookies, cross-site scripting when storing tokens in local storage, not to mention that JSON Web Tokens implementation on the backend is crucial to the system's security.

To build secure Web systems you need to understand the fundamentals of the Web Security model, common security vulnerabilities, and prevention methods. There is a lot to take care of on the frontend side of the application, but the most crucial work from the security perspective is done on the backend of the system. This will be covered in upcoming articles.

Final words

We learnt how to add a login system to an Angular application and create a fully-functional login and registration page. We analyzed the differences between cookie-based and stateless authentication with JSON Web Tokens and provided valid scenarios for both. You can find a full source code of the presented mechanisms in my Budget training application on GitHub.

If you like this content and want to learn more, I highly recommend you join the waiting list for WebSecurity Academy program or WebSecurity Tuesday to receive 2-minute bite-sized tips every week.

Let me know in the comments if you have any questions. Thanks for reading! 😎

OWASP Top 10 Security Vulnerabilities

Bartosz Pietrucha — Mon, 24 Feb 2020 08:20:54 +0000

We are all passionate Web developers, aren't we? 🤗
We build amazing, fast, user-friendly applications that help other people. We love to learn new things and use modern tools! But...

...are we paying enough attention to the security aspects of the applications we build? Are users safe to use our systems?

In this article, I want to give you a short and concise breakdown of OWASP Top 10, a standard awareness document for developers and web application security. The Open Web Application Security Project (OWASP) is a worldwide foundation that works to improve the security of software. OWASP Top 10 document presents the 10 most widely spread vulnerabilities in web applications today (yes, yes, we build web applications with Angular and we NEED to pay attention to it!). Many of us are also developing server-side backend (Full-stack devs for the win ⚡), so this email may contain very significant knowledge.

Here is a summary of the most important parts of OWASP Top 10, that you need to know as a web developer. Just 10 minutes read to be smarter than hackers! 😎

1) Injection 🧨
The application may be vulnerable to malicious code injection via many different inputs like query params.

SELECT * FROM accounts WHERE custID=' + request.getParameter("id") + '

If id param in the above example is not validated or sanitized properly and used directly in SQL query on the server-side, it could display all accounts instead of a proper one. This is a concern more for the server-side, but you should be aware of this as a web developer.

2) Broken Authentication 🧨
Many application users reuse the same logins and passwords across different websites. This creates a huge risk that allows hackers to perform so-called credential stuffing. If the attacker somehow gets a database of a different system (or uses data from well-know publicly available data-breach) he can use automated ways to seek for valid login/password pair and get access to the system. Hackers also may use brute-force or dictionary attacks to login to your system! 😵

But don't worry too much! There are some ways we can protect our applications from this kind of vulnerabilities like:

Multi-factor authentication MFA (using SMS, email, fingerprint, etc),
Password checking during registration (comparing passwords with passwords knowns from data-breaches),
Imposing password complexity rules (minimum length, special characters occurrence),
Limiting failed login attempts (for example, after 3 failed logins, disallow login for 1 hour).

3) Sensitive data exposure 🧨
Sensitive data like logins and passwords, credit card numbers, healthcare records require special treatment. It is crucial to:

Never transmit data over the network (from the server to the browser) in a clear text (always use HTTPS!),
Enforce HTTPS with HTTP Strict Transport Security (HSTS),
Never use old or weak cryptographic algorithms,
Never store sensitive data in plain text (use strong hashing like bcrypt).

4) XML External Entities (XXE) 🧨
Not that important from Angular developer perspective, but good to know when dealing with enterprise systems. It's still the no. 4 vulnerability according to OWASP Top 10.

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

5) Broken Access Control 🧨
Imagine that, we allow a regular user to access the admin panel because we haven't properly secured our routes in the application on the client part (Angular) or most importantly on the server-side. Always make sure you have proper access control checks in your API to ensure authorization like:

preventing access to the parts of the system without a proper role (admin, user, auditor, super-user),
preventing access to the parts of the system without ownership of an entity (like allowing some user to view other user's account data).

6) Security Misconfiguration 🧨
Not that important from Angular developer perspective, but good to know when dealing with enterprise systems. It's still the no. 6 vulnerability according to OWASP Top 10.

When deploying a system to production there are some configuration efforts you need to remember about. Especially, what can be a security risk is:

default systems configuration (Apache, MySQL, etc),
default features enabled that you don't need (just turn them off),
default accounts with default passwords (user: admin, pass: admin 🤦‍♂️),
displaying default error pages with the exact version of server software used (attacker may look for some known vulnerabilities for a given version).

7) Cross-site scripting (XSS) ⚠️ IMPORTANT ⚠️

When the attacker manages to execute some malicious code in the context of the website in the user's browser, it's basically a GAME OVER. Then he can steal for example user's session data (like session-id and send to his own server).

How to prevent this type of attacks (in general):

Sanitize all user input removing special characters (assuming it contains evil code).

You can watch one of my videos exampling Same-origin Policy, which is the fundamental security principle of the web, that mitigates (but not eliminates) the risk of XSS here Same-origin Policy.

8) Insecure Deserialization ⚠️ IMPORTANT ⚠️

Here is a catch! Imagine you store a userAuth object (with username, id, role, etc) in the cookie or local storage. Then the attacker changes manually the content of this object and gives himself/herself a role = admin. BOOM! If the backend side does not validate the content of the userAuth object before the deserialization (meaning creating an object from the string content in the request) we have a problem.

The way to prevent such a situation is to use a hashing function over the content in the local storage or cookie. This will ensure the integrity of the object (content was not changed by the untrusted party). The server generates the hash value of the content, attaches that hash to the content and later can use the hash to verify if the content was not changed. It is possible because ONLY the server knows the secret used in the hashing process.

9) Using Components with Known Vulnerabilities ⚠️ IMPORTANT ⚠️

Very, very easy to neglect risk. We build applications with tons of npm modules. As we build our application some of our npm dependencies may turn out to be vulnerable, unsupported, or out of date and introduce security holes!

How to fix? Before every production deployment run npm audit to make sure your dependencies are secure to be used! And before making a decision of even using some npm module as your core dependency, make a proper background check of a given library/component to mitigate risks in the future.

10) Insufficient Logging & Monitoring 🧨
Here are some examples of vulnerabilities falling into this category:

your system experiences a data breach and no-one notices it (or notices after a very long time)
auditable events (logins, failed logins, and high-value transactions) are not logged
access control failures, server-side input validation failures are not logged
errors generate no, inadequate, or unclear log messages
logs are not monitored for suspicious activity

What to do in such cases?

create logs with sufficient content, context, and good format,
store logs for sufficient time to allow a delayed analysis,
and most importantly MONITOR your logs 🤓

That's it! You have just learned the most important parts of OWASP Top 10!

Angular Architecture Patterns and Best Practices (that help to scale)

Bartosz Pietrucha — Tue, 09 Jul 2019 18:29:21 +0000

=== To receive more articles 👉 join the newsletter on the blog ===

Building scalable software is a challenging task. When we think about scalability in front-end applications, we can think of increasing complexity, more and more business rules, a growing amount of data loaded into the application and large teams often distributed around the world. In order to deal with mentioned factors to maintain a high quality of delivery and prevent technical debt, robust and well-grounded architecture is necessary. Angular itself is a quite opinionated framework, forcing developers to do things the proper way, yet there are a lot of places where things can go wrong. In this article, I will present high-level recommendations of well-designed Angular application architecture based on best practices and battle-proven patterns. Our ultimate goal in this article is to learn how to design Angular application in order to maintain sustainable development speed and ease of adding new features in the long run. To achieve these goals, we will apply:

proper abstractions between application layers,
unidirectional data flow,
reactive state management,
modular design,
smart and dumb components pattern.

Problems of scalability in front-end

Let's think about problems in terms of scalability we can face in the development of modern front-end applications. Today, front-end applications are not "just displaying" data and accepting user inputs. Single Page Applications (SPAs) are providing users with rich interactions and use backend mostly as a data persistence layer. This means, far more responsibility has been moved to the front-end part of software systems. This leads to a growing complexity of front-end logic, we need to deal with. Not only the number of requirements grows over time, but the amount of data we load into the application is increasing. On top of that, we need to maintain application performance, which can easily be hurt. Finally, our development teams are growing (or at least rotating - people come and go) and it is important for new-comers to get up to speed as fast as possible.

One of the solutions to the problems described above is solid system architecture. But, this comes with the cost, the cost of investing in that architecture from day one. It can be very tempting for us developers, to deliver new features very quickly, when the system is still very small. At this stage, everything is easy and understandable, so development goes really fast. But, unless we care about the architecture, after a few developers rotations, tricky features, refactorings, a couple of new modules, the speed of development slows down radically. Below diagram presents how it usually looked like in my development career. This is not any scientifical study, it's just how I see it.

Software architecture

To discuss architecture best practices and patterns, we need to answer a question, what the software architecture is, in the first place. Martin Fowler defines architecture as "highest-level breakdown of a system into its parts". On top of that, I would say that software architecture describes how the software is composed of its parts and what are the rules and constraints of the communication between those parts. Usually, the architectural decisions that we make in our system development, are hard to change as the system grows over time. That's why it is very important to pay attention to those decisions from the very beginning of our project, especially if the software we build is supposed to be running in production for many years. Robert C. Martin once said: the true cost of software is its maintenance. Having well-grounded architecture helps to reduce the costs of the system's maintenance.

Software architecture is the way the software is composed of its parts and the rules and constraints of the communication between those parts

High-level abstraction layers

The first way, we will be decomposing our system, is through the abstraction layers. Below diagram depicts the general concept of this decomposition. The idea is to place the proper responsibility into the proper layer of the system: core, abstraction or presentation layer. We will be looking at each layer independently and analyzing its responsibility. This division of the system also dictates communication rules. For example, the presentation layer can talk to the core layer only through the abstraction layer. Later, we will learn what are the benefits of this kind of constraint.

Presentation layer

Let's start analyzing our system break-down from the presentation layer. This is the place where all our Angular components live. The only responsibilities of this layer are to present and to delegate. In other words, it presents the UI and delegates user's actions to the core layer, through the abstraction layer. It knows what to display and what to do, but it does not know how the user's interactions should be handled.

Below code snippet contains CategoriesComponent using SettingsFacade instance from abstraction layer to delegate user's interaction (via addCategory() and updateCategory()) and present some state in its template (via isUpdating$).

@Component({
  selector: 'categories',
  templateUrl: './categories.component.html',
  styleUrls: ['./categories.component.scss']
})
export class CategoriesComponent implements OnInit {

  @Input() cashflowCategories$: CashflowCategory[];
  newCategory: CashflowCategory = new CashflowCategory();
  isUpdating$: Observable<boolean>;

  constructor(private settingsFacade: SettingsFacade) {
    this.isUpdating$ = settingsFacade.isUpdating$();
  }

  ngOnInit() {
    this.settingsFacade.loadCashflowCategories();
  }

  addCategory(category: CashflowCategory) {
    this.settingsFacade.addCashflowCategory(category);
  }

  updateCategory(category: CashflowCategory) {
    this.settingsFacade.updateCashflowCategory(category);
  }

}

Abstraction layer

The abstraction layer decouples the presentation layer from the core layer and also has it's very own defined responsibilities. This layer exposes the streams of state and interface for the components in the presentation layer, playing the role of the facade. This kind of facade sandboxes what components can see and do in the system. We can implement facades by simply using Angular class providers. The classes here may be named with Facade postfix, for example SettingsFacade. Below, you can find an example of such a facade.

@Injectable()
export class SettingsFacade {

  constructor(private cashflowCategoryApi: CashflowCategoryApi, private settingsState: SettingsState) { }

  isUpdating$(): Observable<boolean> {
    return this.settingsState.isUpdating$();
  }

  getCashflowCategories$(): Observable<CashflowCategory[]> {
    // here we just pass the state without any projections
    // it may happen that it is necessary to combine two or more streams and expose to the components
    return this.settingsState.getCashflowCategories$();
  }

  loadCashflowCategories() {
    return this.cashflowCategoryApi.getCashflowCategories()
      .pipe(tap(categories => this.settingsState.setCashflowCategories(categories)));
  }

  // optimistic update
  // 1. update UI state
  // 2. call API
  addCashflowCategory(category: CashflowCategory) {
    this.settingsState.addCashflowCategory(category);
    this.cashflowCategoryApi.createCashflowCategory(category)
      .subscribe(
        (addedCategoryWithId: CashflowCategory) => {
          // success callback - we have id generated by the server, let's update the state
          this.settingsState.updateCashflowCategoryId(category, addedCategoryWithId)
        },
        (error: any) => {
          // error callback - we need to rollback the state change
          this.settingsState.removeCashflowCategory(category);
          console.log(error);
        }
      );
  }

  // pessimistic update
  // 1. call API
  // 2. update UI state
  updateCashflowCategory(category: CashflowCategory) {
    this.settingsState.setUpdating(true);
    this.cashflowCategoryApi.updateCashflowCategory(category)
      .subscribe(
        () => this.settingsState.updateCashflowCategory(category),
        (error) => console.log(error),
        () => this.settingsState.setUpdating(false)
      );
  }
}

Abstraction interface

We already know the main responsibilities for this layer; to expose streams of state and interface for the components. Let's start with the interface. Public methods loadCashflowCategories(), addCashflowCategory() and updateCashflowCategory() abstract away the details of state management and the external API calls from the components. We are not using API providers (like CashflowCategoryApi) in components directly, as they live in the core layer. Also, how the state changes is not a concern of the components. The presentation layer should not care about how things are done and components should just call the methods from the abstraction layer when necessary (delegate). Looking at the public methods in our abstraction layer should give us a quick insight about high-level use cases in this part of the system.

But we should remember that the abstraction layer is not a place to implement business logic. Here we just want to connect the presentation layer to our business logic, abstracting the way it is connected.

State

When it comes to the state, the abstraction layer makes our components independent of the state management solution. Components are given Observables with data to display on the templates (usually with async pipe) and don't care how and where this data comes from. To manage our state we can pick any state management library that supports RxJS (like NgRx) or simple use BehaviorSubjects to model our state. In the example above we are using state object that internally uses BehaviorSubjects (state object is a part of our core layer). In the case of NgRx, we would dispatch actions for the store.

Having this kind abstraction gives us a lot of flexibility and allows to change the way we manage state not even touching the presentation layer. It's even possible to seamlessly migrate to a real-time backend like Firebase, making our application real-time. I personally like to start with BehaviorSubjects to manage the state. If later, at some point in the development of the system, there is a need to use something else, with this kind of architecture, it is very easy to refactor.

Synchronization strategy

Now, let's take a closer look at the other important aspect of the abstraction layer. Regardless of the state management solution we choose, we can implement UI updates in either optimistic or pessimistic fashion. Imagine we want to create a new record in the collection of some entities. This collection was fetched from the backend and displayed in the DOM. In a pessimistic approach, we first try to update the state on the backend side (for example with HTTP request) and in case of success we update the state in the frontend application. On the other hand, in an optimistic approach, we do it in a different order. First, we assume that the backend update will succeed and update frontend state immediately. Then we send request to update server state. In case of success, we don't need to do anything, but in case of failure, we need to rollback the change in our frontend application and inform the user about this situation.

Optimistic update changes the UI state first and attempts to update the backend state. This provides a user with a better experience, as he does not see any delays, because of network latency. If backend update fails, then UI change has to be rolled back.
Pessimistic update changes the backend state first and only in case of success updates the UI state. Usually, it is necessary to show some kind of spinner or loading bar during the execution of backend request, because of network latency.

Caching

Sometimes, we may decide that the data we fetch from the backend will not be a part of our application state. This may be useful for read-only data that we don't want to manipulate at all and just pass (via abstraction layer) to the components. In this case, we can apply data caching in our facade. The easiest way to achieve it is to use shareReplay() RxJS operator that will replay the last value in the stream for each new subscriber. Take a look at the code snippet below with RecordsFacade using RecordsApi to fetch, cache and filter the data for the components.

@Injectable()
export class RecordsFacade {

  private records$: Observable<Record[]>;

  constructor(private recordApi: RecordApi) {
    this.records$ = this.recordApi
        .getRecords()
        .pipe(shareReplay(1)); // cache the data
  }

  getRecords() {
    return this.records$;
  }

  // project the cached data for the component
  getRecordsFromPeriod(period?: Period): Observable<Record[]> {
    return this.records$
      .pipe(map(records => records.filter(record => record.inPeriod(period))));
  }

  searchRecords(search: string): Observable<Record[]> {
    return this.recordApi.searchRecords(search);
  }
}

To sum up, what we can do in the abstraction layer is to:

expose methods for the components in which we:
- delegate logic execution to the core layer,
- decide about data synchronization strategy (optimistic vs. pessimistic),
expose streams of state for the components:
- pick one or more streams of UI state (and combine them if necessary),
- cache data from external API.

As we see, the abstraction layer plays an important role in our layered architecture. It has clearly defined responsibilities what helps to better understand and reason about the system. Depending on your particular case, you can create one facade per Angular module or one per each entity. For example, the SettingsModule may have a single SettingsFacade, if it's not too bloated. But sometimes it may be better to create more-granular abstraction facades for each entity individually, like UserFacade for User entity.

Core layer

The last layer is the core layer. Here is where core application logic is implemented. All data manipulation and outside world communication happen here. If for state management, we were using a solution like NgRx, here is a place to put our state definition, actions and reducers. Since in our examples we are modeling state with BehaviorSubjects, we can encapsulate it in a convenient state class. Below, you can find SettingsState example from the core layer.

@Injectable()
export class SettingsState {

  private updating$ = new BehaviorSubject<boolean>(false);
  private cashflowCategories$ = new BehaviorSubject<CashflowCategory[]>(null);

  isUpdating$() {
    return this.updating$.asObservable();
  }

  setUpdating(isUpdating: boolean) {
    this.updating$.next(isUpdating);
  }

  getCashflowCategories$() {
    return this.cashflowCategories$.asObservable();
  }

  setCashflowCategories(categories: CashflowCategory[]) {
    this.cashflowCategories$.next(categories);
  }

  addCashflowCategory(category: CashflowCategory) {
    const currentValue = this.cashflowCategories$.getValue();
    this.cashflowCategories$.next([...currentValue, category]);
  }

  updateCashflowCategory(updatedCategory: CashflowCategory) {
    const categories = this.cashflowCategories$.getValue();
    const indexOfUpdated = categories.findIndex(category => category.id === updatedCategory.id);
    categories[indexOfUpdated] = updatedCategory;
    this.cashflowCategories$.next([...categories]);
  }

  updateCashflowCategoryId(categoryToReplace: CashflowCategory, addedCategoryWithId: CashflowCategory) {
    const categories = this.cashflowCategories$.getValue();
    const updatedCategoryIndex = categories.findIndex(category => category === categoryToReplace);
    categories[updatedCategoryIndex] = addedCategoryWithId;
    this.cashflowCategories$.next([...categories]);
  }

  removeCashflowCategory(categoryRemove: CashflowCategory) {
    const currentValue = this.cashflowCategories$.getValue();
    this.cashflowCategories$.next(currentValue.filter(category => category !== categoryRemove));
  }
}

In the core layer, we also implement HTTP queries in the form of class providers. This kind of class could have Api or Service name postfix. API services have only one responsibility - it is just to communicate with API endpoints and nothing else. We should avoid any caching, logic or data manipulation here. A simple example of API service can be found below.

@Injectable()
export class CashflowCategoryApi {

  readonly API = '/api/cashflowCategories';

  constructor(private http: HttpClient) {}

  getCashflowCategories(): Observable<CashflowCategory[]> {
    return this.http.get<CashflowCategory[]>(this.API);
  }

  createCashflowCategory(category: CashflowCategory): Observable<any> {
    return this.http.post(this.API, category);
  }

  updateCashflowCategory(category: CashflowCategory): Observable<any> {
    return this.http.put(`${this.API}/${category.id}`, category);
  }

}

In this layer, we could also place any validators, mappers or more advanced use-cases that require manipulating many slices of our UI state.

We have covered the topic of the abstraction layers in our frontend application. Every layer has it's well-defined boundaries and responsibilities. We also defined the strict rules of communication between layers. This all helps to better understand and reason about the system over time as it becomes more and more complex.

🚀 To receive more articles 👉 join the newsletter on the blog 🚀

Unidirectional data flow and reactive state management

The next principle we want to introduce in our system is about the data flow and propagation of change. Angular itself uses unidirectional data flow on presentation level (via input bindings), but we will impose a similar restriction on the application level. Together with reactive state management (based on streams), it will give us the very important property of the system - data consistency. Below diagram presents the general idea of unidirectional data flow.

Whenever any model value change in our application, Angular change detection system takes care of the propagation of that change. It does it via input property bindings from the top to bottom of the whole component tree. It means that a child component can only depend on its parent and never vice versa. This is why we call it unidirectional data flow. This allows Angular to traverse the components tree only once (as there are no cycles in the tree structure) to achieve a stable state, which means that every value in the bindings is propagated.

As we know from previous chapters, there is the core layer above the presentation layer, where our application logic is implemented. There are the services and providers that operate on our data. What if we apply the same principle of data manipulation on that level? We can place the application data (the state) in one place "above" the components and propagate the values down to the components via Observable streams (Redux and NgRx call this place a store). The state can be propagated to multiple components and displayed in multiple places, but never modified locally. The change may come only "from above" and the components below only "reflect" the current state of the system. This gives us the important system's property mentioned before - data consistency - and the state object becomes the single source of truth. Practically speaking, we can display the same data in multiple places and not be afraid that the values would differ.

Our state object exposes the methods for the services in our core layer to manipulate the state. Whenever there is a need to change the state, it can happen only by calling a method on the state object (or dispatching an action in case of using NgRx). Then, the change is propagated "down", via streams, the to presentation layer (or any other service). This way, our state management is reactive. Moreover, with this approach, we also increase the level of predictability in our system, because of strict rules of manipulating and sharing the application state. Below you can find a code snippet modeling the state with BehaviorSubjects.

@Injectable()
export class SettingsState {

  private updating$ = new BehaviorSubject<boolean>(false);
  private cashflowCategories$ = new BehaviorSubject<CashflowCategory[]>(null);

  isUpdating$() {
    return this.updating$.asObservable();
  }

  setUpdating(isUpdating: boolean) {
    this.updating$.next(isUpdating);
  }

  getCashflowCategories$() {
    return this.cashflowCategories$.asObservable();
  }

  setCashflowCategories(categories: CashflowCategory[]) {
    this.cashflowCategories$.next(categories);
  }

  addCashflowCategory(category: CashflowCategory) {
    const currentValue = this.cashflowCategories$.getValue();
    this.cashflowCategories$.next([...currentValue, category]);
  }

  updateCashflowCategory(updatedCategory: CashflowCategory) {
    const categories = this.cashflowCategories$.getValue();
    const indexOfUpdated = categories.findIndex(category => category.id === updatedCategory.id);
    categories[indexOfUpdated] = updatedCategory;
    this.cashflowCategories$.next([...categories]);
  }

  updateCashflowCategoryId(categoryToReplace: CashflowCategory, addedCategoryWithId: CashflowCategory) {
    const categories = this.cashflowCategories$.getValue();
    const updatedCategoryIndex = categories.findIndex(category => category === categoryToReplace);
    categories[updatedCategoryIndex] = addedCategoryWithId;
    this.cashflowCategories$.next([...categories]);
  }

  removeCashflowCategory(categoryRemove: CashflowCategory) {
    const currentValue = this.cashflowCategories$.getValue();
    this.cashflowCategories$.next(currentValue.filter(category => category !== categoryRemove));
  }
}

Let's recap the steps of handling the user interaction, having in mind all the principles we have already introduced. First, let's imagine that there is some event in the presentation layer (for example button click). The component delegates the execution to the abstraction layer, calling the method on the facade settingsFacade.addCategory(). Then, the facade calls the methods on the services in the core layer - categoryApi.create() and settingsState.addCategory(). The order of invocation of those two methods depends on synchronization strategy we choose (pessimistic or optimistic). Finally, the application state is propagated down to the presentation layer via the observable streams. This process is well-defined.

Modular design

We have covered the horizontal division in our system and the communication patterns across it. Now we are going to introduce a vertical separation into feature modules. The idea is to slice the application into feature modules representing different business functionalities. This is yet another step to deconstruct the system into smaller pieces for better maintainability. Each of the features modules share the same horizontal separation of the core, abstraction, and presentation layer. It is important to note, that these modules could be lazily loaded (and preloaded) into the browser increasing the initial load time of the application. Below you can find a diagram illustrating features modules separation.

Our application has also two additional modules for more technical reasons. We have a CoreModule that defines our singleton services, single-instance components, configuration, and export any third-party modules needed in AppModule. This module is imported only once in AppModule. The second module is SharedModule that contains common components/pipes/directives and also export commonly used Angular modules (like CommonModule). SharedModule can be imported by any feature module. The diagram below presents the imports structure.

Module directory structure

Below diagram presents how we can place all the pieces of our SettingsModule inside the directories. We can put the files inside of the folders with a name representing their function.

Smart and dumb components

The final architectural pattern we introduce in this article is about components themselves. We want to divide components into two categories, depending on their responsibilities. First, are the smart components (aka containers). These components usually:

have facade/s and other services injected,
communicate with the core layer,
pass data to the dumb components,
react to the events from dumb components,
are top-level routable components (but not always!).

Previously presented CategoriesComponent is smart. It has SettingsFacade injected and uses it to communicate with the core layer of our application.

In the second category, there are dumb components (aka presentational). Their only responsibilities are to present UI element and to delegate user interaction "up" to the smart components via events. Think of a native HTML element like <button>Click me</button>. That element does not have any particular logic implemented. We can think of the text 'Click me' as an input for this component. It also has some events that can be subscribed to, like click event. Below you can find a code snippet of a simple presentational component with one input and no output events.

@Component({
  selector: 'budget-progress',
  templateUrl: './budget-progress.component.html',
  styleUrls: ['./budget-progress.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class BudgetProgressComponent {

  @Input()
  budget: Budget;
  today: string;

}

Summary

We have covered a couple of ideas on how to design the architecture of an Angular application. These principles, if applied wisely, can help to maintain sustainable development speed over time, and allow new features to be delivered easily. Please don't treat them as some strict rules, but rather recommendations that could be employed when they make sense.

We have taken a close look at the abstractions layers, unidirectional data flow, and reactive state management, modular design, and smart/dumb components pattern. I hope that these concepts will be helpful in your projects and, as always, if you have any questions, I am more than happy to chat with you.

At this point, I would like to give a huge kudos to Brecht Billiet who wrote this blog post, that introduced me to the idea of Abstraction Layer and Facade. Thanks, Brecht! Big thank you also goes to Tomek Sułkowski that reviewed my perspective on a layered architecture.

DEV Community: Dev-Academy.com

Build a To-Do Application with React and Firebase

Table of Contents

Prerequisites

How to Setup the Firebase Project

Creating the Firestore Database

How to Create the React Project

Setting up the Project Structure

How to Integrate Firebase in React

Integrate Bootstrap 5 into React

Designing the User Interface

Adding Data to the Firestore in React

Fetching Data from the Firestore in React

Deleting Data from the Firestore in React

Updating Data in the Firestore in React

How to Integrate the Checkbox Functionality

How to order Data by Timestamp in Firebase

Conclusion

Angular Interceptors to Manage HTTP Requests ⚡

What is an Angular interceptor, after all?

How does interceptor work?

Can we have multiple interceptors?

How to implement it?

Initial Setup

Custom Header Interceptor

Basic Authentication

Basic Authentication Breakdown

JWT Authentication

JWT Authentication Breakdown

Caching Interceptor

Logging Interceptor

Error Handling Interceptor

Conclusion

The Ultimate Guide to Angular User Login and Registration (Cookies, JWT)

Application structure and solution design

Detailed implementation

Login feature

Sign-up feature

Account confirmation feature

User object

Adapting UI

Protecting routes

API requests authentication

Summary and next steps

Is that solution secure?

Final words

OWASP Top 10 Security Vulnerabilities

Angular Architecture Patterns and Best Practices (that help to scale)

Problems of scalability in front-end

Software architecture

High-level abstraction layers

Presentation layer

Abstraction layer

Abstraction interface

State

Synchronization strategy

Caching

Core layer

Unidirectional data flow and reactive state management

Modular design

Module directory structure

Smart and dumb components

Summary