DEV Community: Snigdho Dip Howlader

Docker Compose for a Full-Stack Application with React, Node.js, and PostgreSQL

Snigdho Dip Howlader — Fri, 14 Jun 2024 18:11:17 +0000

The Premise

So you've built a Full Stack application that you got working as you wanted, and want to show it off. However, dependencies and environments make it so that it only runs on your device. Well, as you already may know that Docker Compose can take care of that. Let's start going through how this can be done without further ado. This tutorial is for those who have some idea on creating applications and servers, and some basic knowledge of Docker as well.

TL;DR

The source code can be found here on Github. To get this project up and running, follow these steps

Make sure you have Docker installed in your system. For installation steps, follow the following steps:
1. For Mac
2. For Ubuntu
3. For Windows
Clone the repository into your device
Open a terminal from the cloned project's directory (Where the docker-compose.yml file is present)
Run the command: docker compose up

That's all! That should get the project up and running. To see the output, you can access http://127.0.0.1:4172 from the browser and you should find a web page with a list of users. This entire system with the client, server & database are running inside of docker and being accessible from your machine.

Here is a detailed explanation on what is going on.

1. Introduction

Docker at its core is a platform as a service that uses OS-level virtualization to deploy/deliver software in packages called containers. It is done for various advantages, such as cross platform consistency and flexibility and scalability.

Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience.

2. Using Docker and Docker Compose

When it comes to working with Full Stack Applications, i.e. ones that will involve more than one set of technology to integrate it into one fully fledged system, Docker can be fairly overwhelming to configure from scratch. It is not made any easier by the fact that there are various types of environment dependencies for each particular technology, and it only leads to the risk of errors at a deployment level.

Note: The .env file adjacent in the directory with docker-compose.yml will contain certain variables that will be used in the docker compose file. They will be accessed whenever the ${<VARIABLE_NAME>} notation is used.

This example will work with PostgreSQL as the database, a very minimal Node/Express JS server and React JS as the client side application.

3. Individual Containers

The following section goes into a breakdown of how the docker-compose.yml file works with the individual Dockerfile. Let's take a look at the docker-compose file first. We have a key called services at the very top, which defines the different applications/services we want to get running. As this is a .yml file, it is important to remember that indentations are crucial. Lets dive into the first service defined in this docker compose file, the database.

1. Database

First of all, the database needs to be set up and running in order for the server to be able to connect to it. The database does not need any Dockerfile in this particular instance, however, it can be done with a Dockerfile too. Lets go through the configurations.

docker-compose.yml

postgres:
    container_name: database
    ports:
        - "5431:5432"
    image: postgres
        environment:
            POSTGRES_USER: "${POSTGRES_USER}"
            POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
            POSTGRES_DB: ${POSTGRES_DB}
        volumes:
            - ./docker_test_db:/var/lib/postgresql/data
        healthcheck:
            test: ["CMD-SHELL", "sh -c 'pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}'"]
            interval: 5s
            timeout: 60s
            retries: 5
            start_period: 80s

Explanation

postgres: used to identify the service that the section of the compose file is for
container_name: the name of the service/container that we have chosen
ports: maps the host port (making it accessible from outside) to the port being used by the application in Docker.
image: defines the Docker image that will be required to make this container functional and running
environment: defined variables for the environment of this particular service. For example, for this PostgreSQL service, we will be defining a POSTGRES_USER,POSTGRES_PASSWORD and POSTGRES_DB. They're all being assigned with the values in the .env.
volumes: This particular key is for we want to create a container that can persist data. This means that ordinarily, when a Docker container goes down, so does any updated data on it. Using volumes, we are mapping a particular directory of our local machine with a directory of the container. In this case, that's the directory where postgres is reading the data from for this database.
heathcheck: when required, certain services will need to check if their state is functional or not. For example, PostgreSQL, has a behavior of turning itself on and off a few instances at launch, before finally being functional. For this reason, healthcheck allows Docker Compose to allow other services to know when it is fully functional. The few properties below healthcheck are doing the following:
- test: runs particular commands for the service to run checks
- interval: amount of time docker compose will wait before running a check again
- timeout: amount of time that the a single check will go on for, before it times out without any response or fails
- retries: total number of tries that docker compose will try to get the healthcheck for a positive response, otherwise fail and declare it as a failed check
- start_period: specifies the amount of time to wait before starting health checks

2. Server

Dockerfile

FROM node:18
WORKDIR /server
COPY src/ /server/src
COPY prisma/ /server/prisma
COPY package.json /server
RUN npm install
RUN npx prisma generate

Explanation
FROM - tells Docker what image is going to be required to build the container. For this example, its the Node JS (version 18)
WORKDIR - sets the current working directory for subsequent instructions in the Dockerfile. The server directory will be created for this container in Docker's environment
COPY - separated by a space, this command tells Docker to copy files/folders from local environment to the Docker environment. The code above is saying that all the contents in the src and prisma folders need to be copied to the /server/src & /srver/prisma folders in Docker, and package.json to be copied to the server directory's root.
RUN - executes commands in the terminal. The commands in the code above will install the necessary node modules, and also generate a prisma client for interacting with the database (it will be needed for seeding the database initially).

docker-compose.yml

server:
    container_name: server
    build:
        context: ./server
        dockerfile: Dockerfile
    ports:
        - "7999:8000"
    command: bash -c "npx prisma migrate reset --force && npm start"
    environment:
        DATABASE_URL: "${DATABASE_URL}"
        PORT: "${SERVER_PORT}"
    depends_on:
        postgres:
            condition: service_healthy

Explanation
build: defines the build context for the container. This can contain steps to build the container, or contain path to Dockerfiles that have the instructions written. The context key directs the path, and the dockerfile key contains the name of the Dockerfile.
command: executes commands according to the instructions that are given. This particular command is executed to first make migrations to the database and seed it, and then start the server.
environment: contains the key-value pairs for the environment, which are available in the .env file at the root directory. DATABASE_URL and PORT both contain corresponding values in the .env file.
depends_on: checks if the dependent container is up, running and functional or not. This has various properties, but in this example, it is checking if the service_healthy flag of our postgres container is up and functional or not. The server container will only start if this flag is returned being true from the healthcheck from the PostgreSQL

3. Client

Dockerfile

FROM node:18
ARG VITE_SERVER_URL=http://127.0.0.1:7999
ENV VITE_SERVER_URL=$VITE_SERVER_URL
WORKDIR /client
COPY public/ /client/public
COPY src/ /client/src
COPY index.html /client/
COPY package.json /client/
COPY vite.config.js /client/
RUN npm install
RUN npm run build

Explanation
Note: The commands for client are very similar to the already explained above for server
ARG: defines a variable that is later passed to the ENV instruction
ENV: Assigns a key value pair into the context of the Docker environment for the container to run. This essentially contains the domain of the API that will be fired from the client later.

docker-compose.yml

client:
    container_name: client
    build:
        context: ./client
        dockerfile: Dockerfile
    command: bash -c "npm run preview"
    ports:
        - "4172:4173"
    depends_on:
        - server

Explanation
Note: The commands for client are very similar to the already explained above for server and postgres

This tutorial provides a basic understanding of using Docker Compose to manage a full-stack application. Explore the code and docker-compose.yml file for further details. The source code can be found here on Github.

Setting up Redux Persist with Redux Toolkit in React JS

Snigdho Dip Howlader — Fri, 03 Nov 2023 23:27:10 +0000

State management is a fundamental aspect of building modern web applications. As an application grows, managing and maintaining the states can become rather daunting. Redux, a popular JavaScript library, has been the go-to solution for state management in React applications for a while now.

However, Redux, or pure Redux to be specific, can be quite verbose and boilerplate-heavy. It requires a significantly lengthy setup, which is where Redux Toolkit comes in handy, offering a simplified and more efficient way to set up and manage state in your React applications.

What is Redux Toolkit?

Redux Toolkit is a much simpler way to set up and use Redux without the need to create large amounts of boilerplate.

Redux Persist

Redux helps applications hold onto data when navigating from page to page, which is known as the global state. However, as most people who are familiar with Redux will know, the global state will be reset the moment the application is reset.

Using Redux Toolkit with Redux Persist

The following tutorial will implement a simple login system, to fetch data to store it in Redux and into the localStorage (default) with Redux Persist. This way, routes can be restricted depending on the existence of data being present in the browser storage.

Custom hooks can do all of this, but the behavior may not always be consistent on all browsers, and the implementation can lead to UI inconsistencies. Redux Persist ensures that the app does not get loaded before the available data is fetched from the browser memory, and then lets the logic flow as it is implemented.

To follow along and understand this tutorial properly, here are some topics that you should have some idea about beforehand:

React JS
Redux
Redux Toolkit

Setting up the React JS Project

First of all, the React project must be set up, and I'll use Vite to do this as it is easy to use. Run the command below:

> npm create vite@latest

You will be given a couple of prompts, such as the name of the project, which can be whatever you want. I named mine 'auth-redux'. Next, the prompt will be given to select the framework, I went with React and then when prompted for a variant, I selected JavaScript.

✔ Project name: auth-redux
✔ Select a framework: React
✔ Select a variant: JavaScript

After the setup is created, run the command:

> npm install

This will install the necessary node_modules to get you started. Finally, to see the server go live, run the command:

> npm run dev

Installing Redux, Redux Toolkit and Redux Persist

With your server set up, it's time to install react-redux, redux-toolkit, and redux-persist, along with react-router-dom, which will be needed for navigating pages in React. We will also install Sass, to use .scss files

> npm i react-router-dom react-redux @reduxjs/toolkit redux-persist sass

Once the setup is complete, we can proceed to create the project itself.

Creating the Login Module

For those who want to check every file and module used in the project, the code is available here for you to follow along with. There is also a TypeScript version in a separate branch for those who require it.

--src/
  --assets/
  --components/
    --common/
      --Navbar
        --index.jsx
        --index.scss
    --pages/
      --Home
        --index.jsx
        --index.scss
      --Login
        --index.jsx
        --index.scss
  --App.css
  --App.jsx
  --main.jsx

The project - two pages, a home page, and a login page.
The goal - to ensure that after logging in, the user is redirected to the home page. If the home page is attempted to be loaded manually in the browser by hitting the URL without logging in, it will redirect back to login. We will try to check and keep track of the login status using Redux and localStorage.

Creating a login form and a home page is fairly simple if you know React JS and CSS/SCSS. Here are the two pages I have implemented.

Home:

The Redux and Redux Persist Setup

Once the pages and necessary components are set up, we can move to explaining the Redux logic. I will be implementing everything related to Redux inside a folder called store.

First, we'll create a "slice" for the initial state of Redux. You can read more on creating Redux Slices here. Essentially, it will be an object, that will contain some properties as null.

const initialState = {
    id: null,
    username: null,
    firstName: null,
    lastName: null,
    gender: null,
    image: null,
    token: null,
};

We can then use this to create our slice. We will create a couple of reducer functions to implement our logic for saving data when a user logs in, and removing data when a user logs out. This can be done with the syntax:

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
    id: null,
    username: null,
    firstName: null,
    lastName: null,
    gender: null,
    image: null,
    token: null,
};

export const authSlice = createSlice({
    name: "auth",
    initialState,
    reducers: {
        saveLogin: (state, action) => {
            state.id = action.payload.id;
            state.username = action.payload.username;
            state.firstName = action.payload.firstName;
            state.lastName = action.payload.lastName;
            state.gender = action.payload.gender;
            state.image = action.payload.image;
            state.token = action.payload.token;
        },
        removeLogin: (state) => {
            state.id = null;
            state.username = null;
            state.firstName = null;
            state.lastName = null;
            state.gender = null;
            state.image = null;
            state.token = null;
        },
    },
});

export const { saveLogin, removeLogin } = authSlice.actions;
export default authSlice.reducer;

With the slice created, we can now move on to create the store itself and the logic to persist the data. Now, we will create the universal reducer using combineReducers function from redux toolkit.

import { combineReducers } from "@reduxjs/toolkit";
import authSlice from "./auth";

const reducers = combineReducers({
    auth: authSlice,
});

Next, we have to set up the Redux Persist mechanism that will be able to retain the data using localStorage. We can do this by creating an object for the persist configuration, and it will require a key and a storage value.

const persistConfig = {
    key: "root",
    storage: localStorage,
    whitelist: ["auth"],
};

Almost done, now using the reducers and persistConfig:

const persistedReducer = persistReducer(persistConfig, reducers);

Creating the store and the persistor objects to export them:

const store = configureStore({
    reducer: persistedReducer,
    middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
        serializableCheck: {
            ignoredActions: [PERSIST],
        },
    }),
});

const persistor = persistStore(store);
export { store, persistor };

The persistor object is what will now be able to ensure that the initialState is created as soon as the app is loaded in the browser, and afterward, Redux Toolkit can handle the further functionalities.

In main.tsx, which is the parent of App.jsx, we will write the following:

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.jsx'
import { persistor, store } from './store/index.js'
import { Provider } from 'react-redux'
import { PersistGate } from 'redux-persist/integration/react'

ReactDOM.createRoot(document.getElementById('root')).render(
  <React.StrictMode>
    <Provider store={store}>
      <PersistGate loading={null} persistor={persistor}>
        <App />
      </PersistGate>
    </Provider>
  </React.StrictMode>,
)

We are wrapping the App component in the PersistGate to ensure that the App does not load until the data fetch/reception is completed between the application and the browser storage by passing the persistor object it that we created earlier. I have set the loading value to null, but you can use this to implement loading screens/components before data is properly loaded into Redux from storage.

And over that, we are wrapping the PersistGate component in the Provider component from Redux, passing the store as a prop so Redux Toolkit can handle the basic functionalities.

How the Private Route Logic Works

App.jsx

import "./App.css";
import { BrowserRouter, Routes, Route, Navigate } from "react-router-dom";
import Login from "./components/pages/Login";
import Home from "./components/pages/Home";
import PrivateRoute from "./components/common/PrivateRoute";
import { useSelector } from "react-redux";

function App() {
  const auth = useSelector((state) => state.auth);

  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Navigate to={"/login"} />} />
        <Route path="/login" element={!(auth.username && auth.id && auth.token) ? <Login /> : <Navigate to={"/page"} />} />
        <Route element={<PrivateRoute />} >
          <Route path="/page" element={<Home />} />
        </Route>
      </Routes>
    </BrowserRouter>
  )
}

export default App

PrivateRoute

import { Navigate, Outlet } from "react-router-dom";
import { useSelector } from "react-redux";

const PrivateRoute = () => {
    const auth = useSelector((state) => state.auth);
    return auth.username && auth.id && auth.token ? <Outlet /> : <Navigate to={"/login"} />
};

export default PrivateRoute;

Here, the PrivateRoute component is going to check if the username, id, and token exist or not. Even if the app is reloaded, the PersistGate along with the persistor object will make sure that the data is fetched from the localStorage in the browser. It will then allow navigation to the <Outlet /> (Whatever component is supposed to be accessible), otherwise it will navigate back to the login page.

Redux Toolkit and Redux Persist at Work

Using the Inspect tab to monitor the data in the local storage, on first load, you can find that the data of the initial state is saved here in the login page as all properties set to null in the auth object.

After logging in, the data is updated accordingly to the response that is being sent from the login API. Every time you try to navigate to the login page now, you will be redirected back to login.

Conclusion

Redux can be fairly complex to work with, but Redux Toolkit makes it a lot easier when setting it up and creating the reducers. Redux Persist lets saving and fetching data into browser storage much more easily and conveniently and allows React applications to depend on browser storage when creating private routes to stop users from accessing certain features - even after hard reloading the application.

All of the source code for this project are available here.

SQL Injections at Work

Snigdho Dip Howlader — Wed, 25 Oct 2023 17:35:52 +0000

SQL Injection

SQL Injection, or SQLI is a means to attack a website or server, with the intention of manipulating the back-end and database to run malicious queries as per desire of the attacker.

Although SQL Injection is an aged form of cyber attack, and most systems likely have taken measures against this - it often does not end up being the case. It can be caused by lack of priority or planning, but plenty of systems even today implement security measures but overlook the possibilities of SQL injections. As a developer, it is natural to have come across the term SQLI or SQL Injection fairly frequently. However, most of the time, the preventive measures are taken against this type of attack without actually understanding what the attacker is doing or trying to do.

In this article, I will provide a very simple example of a log in system that is vulnerable to SQL Injection, and how the SQL Injection can actually be done to allow the attacker into the system without having the correct user password.

A Simple Example

To understand the tutorial effectively, some basic understanding of the following topics is expected:

SQL
JavaScript (Basic Client Side Web Programming)

Let's take a look at the query we will be using throughout the tutorial:
SELECT * FROM users WHERE email = <email> $email AND password = <password>

This query will be executed in the example using PHP to check for a user with the email and user provided from the client.

Here is a simple log in form, and for demonstration purposes, the query that is expected to be executed is shown above it. This will help visualize exactly what is going on.

On the first attempt, the wrong credentials are entered, and the message is shown accordingly below the form. In a scenario where you do not know the password, this is where things would stop on your end. However, with SQL Injection, things can be made out to be more interesting.

The Injection Step

Remember that with most SQL queries, there will be single quotes that wrap the data that is being queried against, such as 'john.doe@gmail.com' and 'Admin@123' in this example. A system vulnerable to SQL injections will be unable to handle a scenario where SQL syntaxes are entered into the inputs themselves.

On first read, it may seem like much has not changed. However, if a closer look is taken at the network tab of the browser, it can be seen that the error message has changed drastically. The single quote after the email field has tossed the server into disarray, because it was not expecting the single quote (or any SQL syntax for that matter). Note exactly how the query in the browser above the form has also changed, and it ultimately has broken the query.

This tells us that we can manipulate the input field in a way that lets us inject SQL directly into code of the server. Now we can proceed to how this can get malicious.

If we try using SQL logic to beat the system, the process becomes a cakewalk. Suppose you want to add a logic to add to the existing query that is always going to be true no matter what - such as '0'=='0', because zero will always be equal to zero! By default, SQL will look at AND statements before looking at the OR. Using this to our advantage, we can add ' OR '0'=='0' in the email field.

Not surprisingly enough, the authentication has been bypassed and the user has been logged into the system without ever providing a correct password. So what did actually happen? Well, if we were to take a look at the query we created by injecting the SQL into the email field, this is what we get from the screenshot above: SELECT * FROM users WHERE email = 'john.doe@gmail.com' OR '0'='0' AND password = 'Admin@123'

This means that the AND operator will try to execute, and fail at first, but then when the OR operator executes, it essentially only checks if the email is matching OR if the statement '0' = '0' is occurring or not, which as mentioned earlier, will always be true. This way, this SQL statement will end up being true in every single scenario regardless of whether the password matches or not, as the OR statement will execute with a condition that will always be true, and ultimately result in a truthy result no matter what.

Another approach

Here's another way for this example:

Once again, this time in much simpler fashion, the authentication has been bypassed. Remember that -- is actually considered as a comment in most SQL systems, and therefore in this example, the final query is just the email field being checked, and the password field being completely ignored.

This was a simple example of how In-band Error-based SQL Injection can work, and there are other types such as Inferential (Blind) SQLi and Out-of-band SQLi. Although most of the cyber world always takes measures against these kinds of attacks, its always important to remember that what may be seen as a low priority in a security measure is always most likely going to be used by hackers and attackers. Prepared Statements on the server-end are among the easiest and simplest ways to avoid vulnerability to SQL injections.

Please remember that the purpose of this tutorial is strictly educational, and not at all to promote any sort of illegal activities. It is important for a developer to know how attacks actually happen, in order to take measurements against them.

This example is done with HTML, CSS, JavaScript and PHP on the server-side.
Github source code: https://github.com/snigdho611/sql-injection

React JS: Interceptors with Fetch API

Snigdho Dip Howlader — Thu, 15 Sep 2022 15:57:43 +0000

What are Interceptors?

Interceptors are a way to trigger specific functionalities before or after a request is made, or a response is received respectively. One of the most commonly used reasons for interception is authentication on the frontend, or re-routing an API URL to something other than the original.

Fetch API

The Fetch API is a very simple and effective way to handle requests and responses with JavaScript or any JavaScript frontend libraries. Namely, React JS has used it quite a lot before the rise of the extremely popular Axios library. Axios actually has some in-built ways to handle interception, both for requests and responses.

However, when working with or maintaining code that is a bit older, Axios may not have been as widely used then as it is used today - and the Fetch API was the only way to advance.

Intercepting with the Fetch API

To put it simply, Fetch API interception is quite easy to do because all that's needed to be done is re-write the fetch function itself. The fetch function takes in two parameters, the resource (the URL) and the config, after which the Promise can be handled.

The following is an easy way to understand the fetch API function. Destructuring the _originalFetch _ function from the window.fetch, you can use it to then get the resource and config mentioned earlier from the arguments of window.fetch.

  const { fetch: originalFetch } = window;
  window.fetch = async (...args) => {
    let [resource, config] = args;
    const response = await originalFetch(resource, config);
    return response;
  };

Any functionality you write here will be executed each time a fetch call is made once this code chunk has been loaded into React JS. For testing, you can simply put this inside a useEffect in App.js, and log something into the console inside this function. Every time onwards a fetch call is made, that particular console log will be executed.

How to intercept requests with React JS

For this demonstration, we are attempting to re-route a fetch call to a dummy JSON generator for posts, to one for quotes instead. Every call made to get posts will instead be re-directed to get quotes and shown in the frontend instead.

const { fetch: originalFetch } = window;
  window.fetch = async (...args) => {
    let [resource, config] = args;
    const URLcutOff = "https://dummyjson.com";
    const trailing = resource.slice(URLcutOff.length);
    if (trailing.startsWith("/posts")) {
      resource = `https://dummyjson.com/quotes?limit=5`;
    }
    const response = await originalFetch(resource, config);
    return response;
  };

This is the code that will be doing it. Essentially, it is going to remove the base part of the resource URL and check if it has a trailing section that contains the characters "/posts", it will instead be replaced by "/quotes". Since the resource is being changed mid-way, the originalFetch function will now use the changed resource and return the response that is sent back from it.

It is that simple! You can re-write this code to try out your own API calls instead of the two that are provided here. A React project is set up for you to try this out on your own from. It has a frontend with a pair of buttons. One button (Posts) to return the data for posts, and another button (Intercept) that will stop making calls to the posts resource every time you click the Posts button, and instead make calls to the quotes resource.

Demonstration:

When the Posts button is clicked:

When the Posts button is clicked after clicking the Intercept button:

You can even see in the inspect tab, that the quotes API is called even after the Posts button is being clicked.

That was it for a simple demonstration of monkey patching with request interception using the Fetch API. Here's a link to the repository that contains all the source code in React JS.

Source Code: https://github.com/snigdho611/fetch-interceptor
By: Snigdho Dip Howlader