Forem: Youssef El Idrissi

Design Patterns: Facade

Youssef El Idrissi — Wed, 25 Feb 2026 01:45:00 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What is the Facade Pattern

This Structural Pattern provides a simplified interface to a complex subsystem, making it easier to use by encapsulating the intricacies of the system behind a single, unified interface.

What's its purpose ?

The Facade Pattern helps in reducing the complexity of interactions with a complex system by providing a higher-level interface that abstracts away the underlying details.
It’s useful when you want to simplify communication with a subsystem, allowing clients to interact with the system in a more straightforward way without needing to understand its complexity.

Key Concepts

Facade Class: The main class that provides a simplified interface to the client. It delegates client requests to the appropriate components within the subsystem.
Subsystem Classes: The classes that represent the complex functionality of the system. These classes contain the actual implementation details and logic but are hidden from the client.

Example: Home Automation System

these are Subsystem Classes

public class LightSystem
{
    public void TurnOnLights() => Console.WriteLine("Lights are on.");
    public void TurnOffLights() => Console.WriteLine("Lights are off.");
}

public class MusicSystem
{
    public void PlayMusic() => Console.WriteLine("Playing music.");
    public void StopMusic() => Console.WriteLine("Music stopped.");
}

public class SecuritySystem
{
    public void ArmSystem() => Console.WriteLine("Security system armed.");
    public void DisarmSystem() => Console.WriteLine("Security system disarmed.");
}

This is the Facade Class

public class HomeAutomationFacade
{
    private LightSystem _lights;
    private MusicSystem _music;
    private SecuritySystem _security;

    public HomeAutomationFacade()
    {
        _lights = new LightSystem();
        _music = new MusicSystem();
        _security = new SecuritySystem();
    }

    public void LeaveHome()
    {
        _lights.TurnOffLights();
        _music.StopMusic();
        _security.ArmSystem();
        Console.WriteLine("Home is in 'leave' mode.");
    }

    public void EnterHome()
    {
        _security.DisarmSystem();
        _lights.TurnOnLights();
        _music.PlayMusic();
        Console.WriteLine("Home is in 'enter' mode.");
    }
}

And this is the Test (aka Consumer class)

public static void TestFacade()
{
    HomeAutomationFacade homeSystem = new HomeAutomationFacade();

    homeSystem.EnterHome();

    homeSystem.LeaveHome();
}

The Good, The Bad and the Ugly

Advantages

Simplifies the interface for interacting with complex subsystems, making it easier for clients to use.
Reduces dependencies between clients and subsystems, promoting loose coupling.
Encapsulates subsystem complexity, allowing for easier maintenance and understanding.

Disadvantages

The facade can become a "God Object" if it tries to handle too many responsibilities.
May hide system complexities that might be needed for advanced usage.
Over-simplifying can lead to limitations in functionality for clients needing deeper access.

When to not use

When a subsystem is simple enough that no facade is needed.
If clients require direct access to the components of a subsystem for customization or extension.
In cases where the added layer of abstraction complicates the system rather than simplifying it.

Design Patterns: Introduction

Youssef El Idrissi — Wed, 25 Feb 2026 01:34:22 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

Design patterns are proven, reusable solutions to common problems that occur during software design and development. They are like templates that can be adapted to address specific challenges within various contexts. Design patterns are not code themselves but rather descriptions of how to solve problems in a way that maximizes efficiency, scalability, and maintainability.

There is in general 3 types of design patterns:

Creational Design Patterns (such as: Singleton Pattern, Simple Factory Pattern)
Structural Design Patterns (such as: Decorator Pattern, Facade Pattern, Adapter Pattern, Proxy Pattern)
Behavioral Design Patterns (such as: Strategy Pattern, Observer Pattern)

Push Notifications: How Your App Speaks When It’s Sleeping

Youssef El Idrissi — Sun, 18 May 2025 06:48:11 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What are Push Notifications ?

Push notifications are messages sent from an app or website to a user's device, even when the app or site isn’t actively open. They appear as pop-up alerts, banners, or notification icons on devices like smartphones, tablets, and computers.

The mechanism with which these "Push Notifications" work is usually the use of some sort of background processes, these processes maintain a persistent connection with the designated "Push Server" depending on their device (in the case of Native Push) or their navigator (in the case of Web Push).

There's two types of Push Notifications:

Native Push: This one usually is linked directly to the Operating System of the Device where Push notifications were activated, for example, Windows, MacOS, Android or IOS.
Web Push: This one is linked to specific navigators instead of the OS directly, Firefox, Chrome (or any Chromium based navigator like Opera...), Firefox etc...

There is a difference between both the execution and implementation of these two types.

Web Push

Web Push is a Protocol/technology that allows websites to send push notifications to users’ devices (desktop, mobile) even when the browser is closed. It’s part of the Push API and Notifications API standards, because it's not tightly coupled with the OS, sometimes it could not work as proficiently.
On some mobile OSes, browsers may be restricted from running background processes aggressively to save battery, causing delays or missed notifications.

Native Push

The Native one works the greatest because Push Notifications are considered Top Priority by the OS, meaning that as long as the user has actual internet connection, they will 100% receive that Push notification, unless they go out of their way to tamper with the settings concerning those notifications or maybe they simply deactivate them.

Wrappers

They’re libraries or services that abstract the differences between native push services (like Apple Push Notification Service for iOS, Firebase Cloud Messaging for Android, Windows Notification Service, and Web Push for browsers) so you can send notifications without writing separate code for each platform. The issue with these "wrappers" is summarized in two things:

Due to the abstractions offered by third-party wrappers, a new problem could arise, instead of fully operating your system/mechanism, you rely on a third party service.
These "wrapper" services usually either cost money or are "fremiums" (meaning they are free for a certain amount of traffic/messages, after that it becomes paid once it passes a certain threshold)

Push Server

One of the most important components when it comes to push notifications is the "Push Server". The way it works is that we subscribe a device for a specific app/notification etc., which generates a very Unique URL, the vendor-specific server registers that this specific device "subscribed" to listen for push notifications coming on that navigator/device, the Unique URL generated gets stored in the backend so that we send a request to it, which in turns gets the actual vendor-specific server to push those notifications to those devices, So in very simple words, it's just a middleman, we don't get the right to directly push notifications from the backend to the device.

Push Notifications usually operate with a Pub/Sub Architecture

Subscribers: are the devices that want to receive notifications.
Broker: being the Push Server that mediates between the Broadcaster (Backend) and the actual subscribed clients.
Publisher(s): the backend that wants to broadcast events/messages (new discounts etc.)

There are Push Servers that handle notifications for each OS/Browser:

The Diagram above demonstrates the common Native Push Servers for each platform/browser (on the left), and it also shows how wrappers could be used to hide all that technical implementation behind abstractions that end up offering the developers very simplified API endpoints/library methods to use (on the far right)

Advantages of Push Notifications:

One of the main advantages is the ability to distribute specific messages/notifications to devices/browsers that aren’t currently open or in use.
If there are multiple Websites/apps that use the same vendor-specific server to push their notifications to devices, then a singular connection gets persisted with multiple "Publishers" but with the same "Broker" which minimizes back-and-forth Network communication, for this reason Multiplexing is used to minimize battery drain, especially on phones.

Example(s) of Use Cases:

1) An admin needs to be notified immediately when a new order is placed, even if the browser or device is idle or closed. Push notifications ensure that the admin receives timely updates regardless of the app’s active state.
2) A user needs to know when a new message is received. While real-time communication methods like WebSockets, Polling, or Server-Sent Events (SSE) work when the app is open, they fail when the window is minimized or fully closed. In such cases, push notifications become the most reliable strategy.

Setting up: WebPush

To setup WebPush on your web server, we're going to use a minimal wrapper library called "web-push" (it exists in NodeJS, Python and PHP and there are other implementations aswell).

There are 2 major sections:

1 - Backend

Now each website/API is identified with a pair of VAPID keys (Voluntary Application Server Identification), In order for our Web server to send push notifications, VAPID keys are used to authenticate the web server to the push server.

To generate the VAPID keys, we run the following instruction:

const webPush = require("web-push");

console.log(webPush.generateVAPIDKeys());


// response:
/* {
  publicKey: 'BENBPj_33ywKcH109jfokUTiS91pLbD2SmVNbUja9KBN4Ppn8HTuZNC_TKEGGsJLRzx4X02kiNA7I-7uKYnLwRM',
  privateKey: '0LLLufPFBBXYFWOymFzrrLkLFeh0GTJzZ-XKf-Ehe_w'      
} */

We set those details with this function:

webPush.setVapidDetails(
    `mailto:${process.env.PRIMARY_EMAIL_OF_MENTAINER}`,
    vapidKeys.publicKey,
    vapidKeys.privateKey
);

Now we need 2 methods.
One Method for adding the "Push Endpoints" for each app/device (aka the subscribers)
One other method is for sending the actual Push Notification.

let subscribers = [];

function setNewAdminSubscription(sub) {
    subscribers.push(sub);
    console.log("new subscription")
}

function sendAdminsNotification(message=null) {
    for (let adminSub of subscribers) {
        webPush.sendNotification(adminSub, "Test");
    }
}

2 - Frontend

Okay on the front end we have to setup 2 things.

A Service Worker, which is basically a type of process that runs in the background, it's seperated from the web page itself, so it can do background fetching, handle push notifications and other things..
A Function to Subscribe, This would accomplish two things, show an "allow notifications ?" popup to show up, and also subscribe to the designated "Push Server" (depending on which navigator is being used).
For the service worker we create a file named "sw.js" (or any other name, it doesn't matter)
This handles the push notification in a way that it shows a popup and specifies the vibration settings (if the navigator is on a phone) etc etc.. basically customizing the popup that will show up.

// sw.js
self.addEventListener('push', (e) => {
    var options = {
        body: 'This notification is a teest',
        icon: 'images/example.jpg',
        vibrate: [100, 50, 100],
        // data: {
        //     dateOfArrival: Date.now(),
        //     primaryKey: '2'
        // },
        // sticky: true,
        requireInteraction: true,
        actions: [
            {
                action: 'explore',
                title: 'Explore this new world',
                icon: 'images/checkmark.jpg'
            },
            { action: 'close', title: 'Close', icon: 'images/xmark.png' }
        ]
    };
    e.waitUntil(self.registration.showNotification('Hello World', options));
});

Now to actually register it within the website, you have to run this code in the index.js (if you're using an SPA like React), or maybe index.html (inside a |script| block)

// index.js
/* ... */

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <App/>
  </StrictMode>,
)

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(function (registration) {
      console.log('Service Worker Registered.');
    });
  navigator.serviceWorker.ready.then(function (registration) {
    console.log('Service Worker Ready');
  });
}

Now this would be the actual subscribe action:

async function subscribe() {
  let sw = await navigator.serviceWorker.ready;
  let push = await sw.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: '<VAPID-PUBLIC-KEY>'
  });
  await axios.post('/subscribe-push', push);
}

At this point you're basically done, all you have to do now is incorporate the "sendPushNotification" method in critical parts of your backend.

In an E-commerce website it could be a simple "new order has been created!" notification when an order has been created (on a Model/ORM/T-SQL Level) or it could be of other uses.

1) The Client makes a purchase (aka confirms an order)
2) The Web Server then logs the successful order in a Database (using an ORM or a Native DB-Adapter), then using the method we defined, the backend initializes a Push Notification to the Push Server
3) The Push Server then Pushes the notification to the Admin's Browser

The point is that you could broadcast any notification to anyone, conditional statements could be added to make sure specific notifications get sent to specific "User-Agents" and so on.

GitHub Webhook CI/CD: Step-by-step guide

Youssef El Idrissi — Tue, 04 Feb 2025 21:33:53 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What is CI/CD

CI/CD, or Continuous Integration and Continuous Delivery/Deployment, is a set of practices and tools that automates the process of software development, testing, and release. It helps developers deliver code changes more frequently, safely, and reliably.

Continuous Integration: This is a development practice where developers frequently integrate their code changes into a shared repository.
Continuous Delivery: This goes one step further by automating the entire release process. Once code passes all testing stages, it is automatically deployed to the production environment.

There are lot of tools that are used to perform CI and CD such as and not limited to:

Jenkins
GitHub Actions
GitLab CI/CD
Travis CI

However these tools are usually followed by resource use restrictions or require monetary contributions to be used efficiently and at the same time beginners struggle to use such tools at the start of their Software Development career.

There is however an easier-to-bootstrap and harder-to-efficiently-setup way to achieve CI/CD which is "GitHub Webhooks"

How to setup GitHub Webhook ?

Step 0: Create a repo

Ofcourse when we have a new project we have to create a new repository for it to store our code changes (aka commits), but in this case it will also be useful to achieve our CI/CD goal.

Step 1: Create a route for the POST-webhook

Assuming that you already have a server with your desired runtime environment/Framework up and running on a specific port.
You're gonna have to also make a webhook in order to let Github have a way to reach your server in the case of new change to the main/production branch on your github repo like so:

require('dotenv').config();
const express = require('express');
const crypto = require('crypto');
const bodyParser = require('body-parser');
const { exec } = require('child_process');
const app = express();

const updatedAt = new Date();

function verifySignature(req, res, buf, encoding) {
    const signature = req.headers['x-hub-signature-256']; // GitHub sends the signature here

    if (!signature) {
        console.log('No signature found on request');
        return false;
    }

    const hmac = crypto.createHmac('sha256', process.env.REPO_WEBHOOK_SECRET);
    const digest = 'sha256=' + hmac.update(buf).digest('hex');

    if (signature !== digest) {
        console.log('Signature does not match');
        return false;
    }

    console.log('Signature is valid');
    return true;
}

app.use(bodyParser.json());

app.post('/cicd/github-cicd', (req, res) => {
    const buf = JSON.stringify(req.body); // The raw body of the request
    // const isValid = verifySignature(req, res, buf);

    /* if (!isValid) {
            return res.status(401).send('Invalid signature');
    }*/

    const { ref } = req.body;
    if (ref === 'refs/heads/main') {
        // PM2 is my instance manager
        exec('git pull origin main && pm2 restart cicd_app');
    }
    res.sendStatus(200);
});

app.get('/cicd/time', (req, res) => {
    res.send(`<h1>${updatedAt}</h1>`);
});

app.listen(80, () => {
    console.log("Listening on Port 80...");
});

(Full source code)

Step 2: Configure the repo's settings

Go to [YourRepo -> Settings -> Webhooks]
Then
Then we get to the webhook creation panel
[warn] Depending on the SSL state of your website (if it's activated or not), choose the "SSL Verification" option accordingly.
[warn] Incase you want Github to include a "secret" token to authenticate itself to your server to ensure it's Github and not a threat actor, then put a secret word, otherwise leave empty.

Step 3: Ready !

After Setting up your webhook on your webserver and github webhook of your repo, then you're basically good to go.

Macro

First a developer will push their commit (code changes) to GitHub.
Secondly GitHub will send a POST Request to our server, and specifically to our webhook route with the body in JSON with information related to that github push that we've done just a moment ago.
Thirdly The server will then ofcourse treat said request as a way to know that there are changes on the production branch that must be applied as soon as possible, therefor a git pull will be attempted and then tests and new builds and whatnot are going to be executed.
Finally The server will consequently restart with the updated source code.

Vim: an epic terminal-based text editor

Youssef El Idrissi — Sat, 28 Sep 2024 06:01:59 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

Introduction about Vim

Vim (short for Vi IMproved) is a highly configurable and efficient text editor that extends the functionality of the classic Unix-based Vi editor. Created by Bram Moolenaar, Vim is designed to maximize productivity in text editing through a combination of keyboard-driven commands and modes.

What are Buffers in vim ?

In Vim, a buffer is essentially an in-memory representation of a file. When you open a file in Vim, it is loaded into a buffer, allowing you to make changes to it.

Basics of Vim

To Edit a file (or Create one)

vim <file_name>

Saving and Quitting

To save the modifications to a file: you simply press [:] then type w and press ENTER
To save the mods. and quit the file: you do the same thing except it's :wq
To quit a file and discard the mods.: press [:] and type [q!] then ENTER

There are 4 Modes in Vim

NORMAL MODE: It is the default mode. It is mostly useful for navigating through a file, however there are some shortcuts that make modifications to the file even with this mode. For example:

Pressing [0]: Places the cursor at the start of the current line.
Pressing [$]: Places the cursor at the end of the current line.
Pressing [u]: Undo's the last change that was done to the "buffer".
Pressing [x]: Deletes one character (where the cursor is).
Pressing [dd]: Deletes the current line (but it gets saved in the "paste buffer", which means the contents can be "pasted".
Pressing [p]: Pastes whatever is copied (in the "paste buffer")
Pressing [gg]: Places the cursor at the first line in the file.
Pressing [G]: Places the cursor at the last line in the file

INSERT MODE: This mode is activated by pressing [i]. It is used to insert new data to the document. Here are some examples of shortcuts:

Pressing [a + Shift]: Places the cursor at the end of the current line and activates INSERT MODE.
Pressing [i]: Activates INSERT MODE.

VISUAL MODE: This mode is useful to select specific subtext and apply modifications on it. It is activated by pressing [v]. Here are a few examples of shortcuts:

Pressing [y]: The selected section of text will be copied (not cut) and get placed in the "paste buffer" (to be pasted somewhere)
Pressing [:] then Typing [sort ui]: This will sort the selected lines alphabetically and ensure there are no duplicate lines.

COMMAND MODE: Accessed by pressing [:]. Used for entering commands such as saving files, quitting Vim, and searching.

examples:

[:! <LINUX_COMMAND>] - Execute a command while in vim

File Operations

[:q] - Close the current window/buffer.
[:w] - Write changes to the current file.
[:q!] - Close the current window/buffer and discard of the changes.
[:wq] - Write changes to the current file and close the window.
[:r <file_name>] - Copy the buffer of "file_name" and paste it in the current buffer.
[:w <file_name>] - Copy and Write the current buffer to "file_name"

String Search

[:%s/<regExpr>] - Search and highlight the first occurence of a string/pattern.
[:%s/<regExpr>/String2/g] - Search and replace ALL the occurences of a string/pattern.

Buffers

Buffers can be extremely useful when you want to edit multiple files at the same time. Using COMMAND MODE, here are some useful tricks:

[:ls] - Lists all the buffers currently accessible. (the one active has a %a sign)
[:e <file_name>] - Load a file into a new buffer.
[:b <buffer_number>] - To switch to a buffer
[:enew] - To create an empty buffer (whose content that you can later on save to a file or to another buffer)
[:bn] - Switches to the next buffer in the list.
[:bp] - Switches to the previous buffer in the list.
[:bw <buffer_number>] - Saves changes to the buffer X.
[:bd <buffer_name>] - Deletes the buffer X.
[:bd! <buffer_name>] - Deletes the buffer X discarding of any changes.

Splitting the screen

Horizentally

[:sp[lit] <file_name>] - Splits the current file with "file_name" horizentally, This step can be done multiple times with multiple files.

Vertically

[:vsp[lit] <file_name>] - Splits the current file with "file_name" horizentally, This step can be done multiple times with multiple files.
[Ctrl + ww] - To switch between "splits".

Advantages of a Terminal-based Text editor

Vim is very light resources-wise, which makes it ideal to run on low-end machines.
It is terminal-based which means it can be executed and used remotely without any trouble using something like SSH.
The learning curve to master Vim is a bit steep but everyone can master the basics quite easily after a bit of practice.

Diffie-Hellman Key Exchange (DHKE) Algorithm

Youssef El Idrissi — Sat, 31 Aug 2024 17:12:48 +0000

Introduction & History

The Diffie-Hellman Key Exchange algorithm is a fascinating method that allows two parties to securely share a secret key over an insecure communication channel (for example: over the internet). Introduced by Whitfield Diffie and Martin Hellman in 1976 and it marked a significant advancement in the field of cryptography because, prior to its development, securely exchanging keys was a major challenge, particularly in the realm of symmetric encryption.

What is the "DHKE" Algorithm?

The Diffie-Hellman Key Exchange algorithm is a type of public key cryptography that enables two parties, who may have never communicated before and are connected over an unsecured network, to establish a shared secret. This shared secret can then be used to encrypt subsequent communications using symmetric encryption algorithms (such as AES-256).

Phase I: Initialization

Two parties, typically called Alice and Bob, agree on a common set of public parameters:
- 𝑝: A large prime number, which will be used as the "modulus".
- g: a primitive root (also known as the generator) of 𝑝, which is a number that, when raised to various powers, generates all the numbers from 1 to 𝑝−1 under modulo 𝑝.

Phase II: Key Exchange

Private Key Selection:

Alice selects a private key X, which is a random integer that she keeps secret.
Bob selects a private key Y, which is also a random integer that he keeps secret.

Public Key Computation and Exchange:

Both Alice and Bob calculate their public keys respectively using the equations in the graph shown below.

Then Alice and Bob exchange their public keys (A and B over the insecure channel)

Phase III: Shared Secret Computation

Shared Secret Derivation:

The Last step is to derive the Shared Secret using the equations below

Both calculations result in the same shared secret K, which can now be used as a key for symmetric encryption to securely communicate.

Disadvantages...

Diffie-Hellman is a great algorithm but when used alone there are vulnerabilities such as, Man-in-The-Middle attack (MiTM).
It goes like the following:

In the exact moment that "Alice" and "Bob" have generated their Public Keys (A and B) and when one of them tries to share their public key with the other over an insecure network, an Attacker ("Aku" for example) intercepts that public key, only to replace it with his own calculated Public key.
The process then happens the same way for both parties (Bob and Alice).
Aku Sends his Public Key C to Bob and receives Bob's public key B.
Aku Sends his Public Key C to Alice and receives Alice's public key A.

Shared Secret Derivation gets calculated by Bob, Alice, and as for Aku, he does that calculation 2 times (one for Aku-Bob shared secret, and another for Aku-Alice shared secret)

In the end, Aku ends up seeing what both Alice and Bob send each other over the network.

Digital Certificates help against this type of Attack because it confirms that "Bob" is Bob and that "Alice" is Alice.

The SSH Protocol

Youssef El Idrissi — Mon, 05 Aug 2024 03:40:00 +0000

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What is SSH

Secure Shell (SSH) is a cryptographic network protocol used for secure data communication, remote shell services, and command execution between two networked computers. Developed as a replacement for older, less secure protocols like Telnet and rlogin, SSH provides a robust layer of security by encrypting the connection and ensuring data integrity.

SSH is widely used in various domains, including system administration, software development, and network engineering. It enables administrators to manage servers, configure devices, and transfer files securely over an insecure network. The protocol is also instrumental in automating scripts and processes, making it a critical tool in modern IT environments.

One of the most significant advantages of SSH is its ability to facilitate secure remote access. By using SSH, users can log into remote machines, execute commands, and manage systems as if they were physically present, all while maintaining a high level of security. This feature is particularly valuable in today's distributed work environments, where remote access to servers and devices is a necessity.

Setting up an OpenSSH server

An OpenSSH server is setup in a way that a machine can be accessed using the SSH protocol.
It can be setup on any Windows, Macintosh or Linux machine.
To set it up on a Linux machine of the Ubuntu distro, we must install the necessary packages.

1- Update Package List

sudo apt update

2- Install OpenSSH

sudo apt install openssh-server

3- Adjust firewall rules (Optional, but Highly encouraged due to security concerns)

# This allows incoming traffic on OpenSSH (by default it's port 22)
sudo ufw allow ssh
# If the port is changed (not 22), Do this instead:
sudo ufw allow <custom_port_for_openssh>

# This enables the Host-Firewall if it isn't enabled yet.
sudo ufw enable

4- Turning ON the Service

# For systemctl machines:
sudo systemctl start ssh
# otherwise
sudo service ssh start

Server-Side Configuration

On Debian-based machines, the configuration file can be found in: /etc/ssh/sshd_config

# by default
Port 22
MaxAuthTries 10
MaxSessions 5
PasswordAuthentication yes
PubkeyAuthentication no

Banner none
X11Forwarding no

Port: We can choose a port (as long as it isn't being used by another service) from 1 to 65535
MaxAuthTries: is an important parameter for controlling how many times a client can attempt to authenticate before being disconnected. Setting it to a reasonable value helps improve the security of your SSH server by reducing the risk of unauthorized access through brute-force attacks.
MaxSessions: this is a SSH server parameter that limits the number of simultaneous sessions a single SSH connection can establish.

PasswordAuthentication: choose if a user can or can not authenticate to the server with a password.
PubkeyAuthentication: choose if a user can or can not authenticate to the server with a Private key (which is from a previously generated Public/Private key value pair).
Banner: This parameter isn't really of any security meaning, but rather one could customize their server's welcoming Banner.
If set, it should point to the file that should be echo'ed, otherwise leave it as "none"
X11Forwarding: This allows users to have the GUI apps on the remote server virtually executed on the actual Host machine using something called the "X Window System".
AllowTcpForwarding: This setting allows TCP forwarding, which means that users can create SSH tunnels to forward arbitrary TCP connections over the SSH connection. This is used for port forwarding, which includes both local and remote forwarding.

-> Example: You have mysql-server installed on the remote server, but you didn't expose the port of that mysql server outside of that machine (one can't connect to it with a GUI tool remotely with a Client tool like "MySQL Workbench"), and instead of making the port of that DB service exposed, we just want to use the mysql-workbench gui app on the remote machine itself, and have that graphical interface "forwarded" to us to see and manipulate. X Window comes in handy here.

at the end, we need to restart the openssh server:
sudo service ssh restart

SSH Key Management (PubkeyAuthentication)

When it comes to Authentication in SSH, there's multiple ways, such as Password, Public Key and PAM.
When it comes to "PubkeyAuthentication" (which is the more secure option than Password), we are talking about Asymmetric Encryption, Public and Private key pairs.
In order to securely authenticate as a user to an SSH server, asymmetric encryption is used.
To utilize this method of Authentication, the user should add this modification to the SSH server's config file: PubkeyAuthentication yes

The user has to generate a key pair, and then they have to append the contents of the "public key" to the end of the server's "authorized_keys" file.

Client Setup

1- Generate Key Pair

ssh-keygen -t rsa/ecdsa/ed25519... -b 2048 -c "email@gmail.com"

-t: This parameter specifies which asymmetric encryption algorithm to use, there are multiple such as rsa, ecdsa ect...
-b: This parameter specifies the number of bits of the key (the correct values depend on which algorithm is choosen, ex: rsa accepts "2048" or "4096".
-c (optional): you can associate a custom description with your key, ex: Your email.

2- Once it is generated, by default the private and public keys are both gonna be in under the "USERNAME/.ssh" folder, That means:
- C:/Users/USERNAME/.ssh (on Windows)
- /home/USERNAME/.ssh (on Linux)

The Public key is the one with the extension ".pub" and the Private one is the one without any extension. ex: id_rsa and id_rsa.pub

3- Once generated, we need to declare it to the SSH server, in a way that we add Our Public key to the SSH Server's "whitelist" (aka the authorized_keys file).

The process is fairly simple, we have to copy the content of the Public key, and add it to the SSH Server's "authorized_keys" file.

Since we have Linux as our SSH Server, there's already a command that could faciltate this process:

ssh-copy-id -i ~/.ssh/mykey.pub user@remote_host

-i: specifies the path to the public key that has to be allowed by the SSH Server

4- We can then easily connect to our SSH Server with our private key like so:

ssh -i ~/.ssh/myprivatekey user@remote_host

-i: specifies the path to the private key

5 (optional)- We can create a file that remembers the key path with its correspondant username and remoteHost ect with config:

This "config"-named file has to be created in the ".ssh" folder that we previously discussed.
The contents are like so:

Host customHost1
  User ubuntu
  HostName test.host.com
  Port 22

Host customHost2
  User ubuntu
  HostName test2.host.com
  IdentityFile PATH/TO/id_rsa
  IdentitiesOnly yes

Host customHost3
  User root
  HostName server.mydomain.tech
  IdentityFile PATH/TO/id_rsa

Host: This defines the "profile" or "alias" to connect to a specific server with a specific Hostname ect..
User: Specify the username
HostName: Specify the hostname (or host ip)
Port: Specify the port (if not specified, PORT 22 is assumed)
IdentityFile: Set the Path of where the Private Key is. (If the server uses PubKeyAuthentication)

LocalForward: The LocalForward parameter sets up a local port on your machine to forward to a port on a remote machine. This is known as "port forwarding" or "tunneling" and is often used to access services running on a remote machine as if they were running locally.
(syntax: LocalForward <local_port> <remote_host>:<remote_port>)
RemoteForward: The RemoteForward parameter works similarly to LocalForward, but in the opposite direction. It forwards a port on the remote machine to a port on your local machine. This can be useful for making services on your local machine accessible to the remote machine.
(syntax: RemoteForward <remote_port> <local_host>:<local_port>)
DynamicForward: The DynamicForward parameter sets up a local port to act as a SOCKS proxy. When you connect to this port, SSH will dynamically forward the traffic to the appropriate remote host and port, based on the connections made by the SOCKS proxy. This is useful for creating a secure tunnel for a variety of protocols and services.
(syntax: DynamicForward <local_port>)

After Doing all of this, We can simply connect using the set "Host" alias we setup like so:
ssh acreaweb1

Front-End & Back-End (CSR)

Youssef El Idrissi — Fri, 02 Aug 2024 02:37:01 +0000

Introduction
Once when I started Programming, I started with simple PHP and then gradually switched to laravel, but I always had this misconception about websites, I thought the backend and frontend have to always be on one server that handles everything (like in the case of Server-Side Rendering frameworks), but after a while I discovered that there's something called "React" which is a re-usable library that is javascript-based and only then did I realize that yes, front end and back end could actually be on seperate servers or shall we say "nodes".
And it did make a lot of sense because it seems to me that it would be a little complicated to maintain a website/system that has tons of features on both the front end and back end respectively.

-We will be discussing Client-Side Rendering (CSR) for the most part in this blog.

-we will not focus that much on deployment so there would be no discussion of specific cloud service providers.

What can we consider as "front end"?
in the context of CSR, there's multiple frameworks in different programming languages,
the most popular in my experience are React, Angular and Vue.
there's multiple purposes these frameworks serve, but mainly those frameworks (when hosted on a "node") are responsible for human interaction with the website (referring to User Interface and User Experience UX/UI) to make it look as smooth as possible for the user.
behind the scenes each interaction from the user with the UI means a certain action should be done (usually by the backend) or some content should be shown (usually a fetch from the backend to get specific data)

What can we consider as "back end"?

what we can consider a backend is usually a codebase that processes requests coming from a front end node for further processing (fetching, execute a certain method etc...)
There are multiple frameworks and languages that actually work well with CSR-based apps since they act just as an API for the front-end to consume:

for PHP there's Laravel (although PHP has some limits when it comes to processing due to its blocking nature but if the scale of the app is small to medium it's mostly fine to work with)
ExpressJS is minimalistic so you'd have to add the libraries you want to work with by your own using NPM, it's good for beginners because one will have to be creative to organize their own folder structure, their
NestJS comes with some features out-of-the-box and also has great support for the Micro-services architecture, however it does use Typescript heavily so that should be considered when choosing the right framework to use.

The Big Picture
Now that we understand what we can consider as back-end and front-end, the most crucial and important part is actually making the front end able to communicate with the back-end and vice versa.
There are many communication styles to achieve that.

REST API is one of them, it relies on the HTTP Protocol to provide a Request/Response style and it is also the most common.
GraphQL is a another way to "query" data from the back-end in a more precise way, therefor getting rid of the extra data that might be fetched and immediately discarded in a typical REST API Request. (An example would be fetching an array of users, each user object having: "id", "full name", "age", "username", "password", "email". And then use for example only the "username" and "password" keys, and as in GraphQL we can specifically "query" that we only need the username's and password's)

Besides that, we need a way to keep track of our users, especially if they're "logged In" or not.

API Keys come to the rescue and act like an access card to a guarded building (the back-end), usually on each connection from the user on the Front End, an API Call gets to the Back End (the very first request is usually a login HTTP Request containing the username and password) then the back-end processes that request and if everything went well, the back-end issues a unique API Key for the Front End to store for any more additional requests.

In Most Frameworks that handles the UI, there's always a notion of a "local storage". in Android it's "Shared Preferences", in Desktop it could be an encrypted file storing sensitive data and so on.

in this context of ours it's the same thing, we store the API Key(s) in the available local data store (or any key/value local data store) implementation that is available to us, in React it's "local storage".

API Key Types

There many type of API keys with specific roles , advantages and inconvenient, in this article I Will focus much on JsonWebTokens (JWT) and Classic generate-on-demand keys.

Classic API Keys: usually a hash generated by the back-end taking into consideration identifiants of the specific user that is logging-in, after that it's stored in the database (a relational one most of the time), and on each request (other than login), the key will be searched for in our database, if it's found then the request is valid, if not (or somehow "expired") then we should return a specific HTTP Code to announce that.

JWT Token: the same thing, a hash generated by the back-end, however it's not necessarily stored in the database, why? because the back-end can verify if the token is legit and "not expired" without even interacting with the database, because it's more of an algorithm computation than a mere SQL statement, on the back-end when we generate a JWT Token, it wraps auth information (such as username, password) and an expiration date (it could be minutes, hours , days ect..). On receiving the Key on the back-end to do some specific task, the back-end runs a "verify_if_token_is_legit" method which as mentioned before, is just cryptography math and after that the back-end can even access the auth information that was wrapped in there before at the time of the creation of that key.