Forem: Grégory CHEVALLIER

💾 Automatiser le « backup » d'une base de donnée MySQL avec NestJS et TypeORM

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:06:32 +0000

Parmi les différentes causes à l'origine d'une journée cauchemardesque 😫 dans la vie d'un(e) développeu.r.se, on retrouve le célèbre « drop » inopiné (à l'effet tant redouté) d'une base de données en environnement de production qui permet à celles et ceux qui la subissent de voir passer le temps plus lentement qu'il ne l'a jamais été auparavant.

🗑️ En bref, la base de données s'est vidée de son contenu spontanément en raison d'un incident technique.

Les applications/serveurs sollicitant l'utilisation de votre base de données sont dès lors impacté(e)s de manière critique ‼️. Celles-ci sont momentanément interrompues et votre environnement de production devient « down » (inaccessible).

De nombreux incidents peuvent être à l'origine d'un « drop » de la base de données :

Une maladresse causée durant la réalisation d'une tâche « DevOps » sur serveur
Le datacenter hébergeant votre serveur est victime d'un incident (dernier évènement majeur en date : incendit 🔥 d'un datacenter OVHcloud à Strasbourg le 10 mars 2021)
Le déploiement d'une mise à jour impliquant la modification structurelle des entitées internes à la base de données
La résiliation à date échéante de votre formule d'hébergement et donc la réinitialisation du serveur intégrant la base de données

[...] Et tant d'autres.

🤷‍♂️ Comment l'appréhender ?

L'implémentation d'un système de backup 💾 est l'une des solutions parmi les plus recommandées lorsqu'il s'agit de protéger l'intégrité des données liées à votre application

Cette solution génère, selon un intervalle temporel défini, un export (partiel ou intégral) de la base de données. Un « snapshot » de la base de données est alors daté et exporté localement ou sur un serveur tiers.

Le cumul de ces snapshots va permettre de restaurer, en cas d'incident, la majeure partie, voir l'intégralité des données perdues depuis une date spécifique.

⚠️ Pré-requis

La réalisation de cette technique nécessite l'utilisation d'une API NestJS (framework « server-side » basé sur Node.js) ainsi que l'utilisation de TypeORM (ORM JavaScript et TypeScript majoritairement utilisé sur Node.js).

Elle a comme objectif la création d'une archive (.zip) incluant les différentes tables de votre base de données (.sql), dans un répertoire spécifique sur serveur, à date de son exécution.

Une base de données MySQL doit être disponible sur le même environnement que celui où est exécutée l'API NestJS. (Celle-ci peut parfaitement être intégrée dans un « Docker Container »)

ℹ️ Si la base de données est démarrée depuis Docker, les fonctionnalités Docker doivent être exploitables via bash sans avoir à justifier de permissions « super utilisateur ».

📦 Création du service dédié aux tâches

La première étape de notre implémentation requiert la création d'un nouveau service dédié aux tâches.

Les dossiers tasks et services ainsi que les fichiers tasks.module.ts et tasks.service.ts doivent être créés selon l'arborescence suivante (à ajuster selon l'architecture de votre API) :

Arborescence des fichiers 👇

   - 🗂️ src
        - 🗂️ tasks
            - 🗂️ services
                - 🔵 tasks.service.ts
            - 🟢 tasks.module.ts
        - 🟢 app.module.ts

Procédons à l'export du nouveau service fraîchement créé :

    import { Injectable } from '@nestjs/common';

    @Injectable()
    export class TasksService {

    }

Puis ajoutons la configuration minimale requise à notre nouveau module tasks.module.ts en important le fichier tasks.service.ts :

    import { Module } from '@nestjs/common';
    import { ConfigModule } from '@nestjs/config';

    import { TasksService } from './services/tasks.service';

    @Module({
        imports: [ ConfigModule ],
        providers: [ TasksService ],
        controllers: [ ],
    })
    export class TasksModule {}

Dans notre fichier app.module.ts, le module récemment créé doit être importé de la manière suivante :

    import { TasksModule } from './tasks/tasks.module';
    /* ... */

    @Module({
      imports: [ 
        TasksModule,
        /* ... */
      ],
      controllers: [],
      providers: [],
    })

    export class AppModule {}

Il ne nous reste plus qu'à implémenter de nouvelles fonctionnalités dans le nouveau service créé 🔥

⏰ Implémentation de la tâche CRON dédiée au « backup »

Pour planifier l'export de notre base de données, NestJS rend disponible le package @nestjs/schedule.

Ce dernier permet de programmer l'exécution d'une fonction à une date/heure fixe, à des intervalles récurrents ou une fois après un intervalle donné.

Les packages suivants doivent alors être installés :

    $ npm install --save @nestjs/schedule
    $ npm install --save-dev @types/cron

@nestjs/schedule doit, une fois installé, être importé dans le fichier app.module.ts :

L'import import { ScheduleModule } from '@nestjs/schedule'; doit être ajouté.
Notre AppModule doit également importer : ScheduleModule.forRoot().

    import { ScheduleModule } from '@nestjs/schedule'; // import from package here
    /* ... */

    @Module({
      imports: [ 
        ScheduleModule.forRoot(), // module import here
        /* ... */
      ],
      controllers: [],
      providers: [],
    })

    export class AppModule {}

Nous pouvons dès lors implémenter une ⏰ tâche programmée depuis le service dédié aux tâches TasksService :

    import { Injectable } from '@nestjs/common';
    import { Cron, CronExpression } from '@nestjs/schedule';

    @Injectable()
    export class TasksService {

        @Cron(CronExpression.EVERY_10_SECONDS)
        async exportDB() {
            // do something
        }

    }

L'enum CronExpression fourni une correspondance explicite des différentes expressions qui permettent de définir l'intervalle d'exécution. Il est conseillé de l'importer pour améliorer la clarté du code.

Nous utiliserons EVERY_10_SECONDS pour les phases de test.

ℹ️ Selon le comportement attendu, l'exécution du backup pourrait très bien être exécuté une fois chaque semaine de sorte à créer un point de sauvegarde sans accumuler excessivement de données de stockage.

La fonction exportDB() est à présent sollicitée depuis un intervalle donné, voyons comment exporter la base de données.

📤 Export des tables depuis le serveur MySQL

A la racine de notre projet, le dossier backups doit être créé, il va permettre de répertorier les archives (.zip) qui seront générées par notre système de sauvegarde.

⚙️ Déclarations principales

Commençons par déclarer les constantes essentielles à notre tâche :

    /* Settings */
    const DEBUG_MODE = false; // Pass to 'true' to print the script exec output and display errors
    const BACKUPS_DIRECTORY = 'backups'; // Directory where will be exported the snapshot
    const DOCKER_CONTAINER_NAME = false; // Add a Docker container name if your mysql server depends of Docker

ℹ️ La constante DOCKER_CONTAINER_NAME permet d'accéder au serveur MySQL d'un éventuel processus Docker.

Puis prélever les informations relatives à notre base de données courante.

    ...

    /* Database */
    const databaseCredentials: ConnectionCredentials<ConnectionOptions> = await getConnectionOptions('default');
    const tablesList = await getManager().query(`SHOW tables;`);

La commande MySQL SHOW tables; permet d'obtenir les différentes tables de notre base de données.

ℹ️ Libre à vous de paramètrer l'export d'une ou plusieurs base(s) de données selon l'architecture de votre API.

Les informations de connexion au serveur MySQL databaseCredentials nous permettront de nous authentifier à la base de données pour y ordonner l'export des tables cibles.

Les dernières constantes à déclarer sont des informations utiles au référencement de notre snapshot :

    ...

    /* Main declarations */
    const dateOfSnapshot = DateTime.now().toFormat('yyyy-LL-dd'); // Today as "2023-04-29" format
    const exportedFiles = []; // Temporarily created (.sql) files are pushed in this const
    const archiveToCreate = `${BACKUPS_DIRECTORY}/${dateOfSnapshot}_snapshot.zip`; // Relative path for snapshot from root of project

ℹ️ La librairie Luxon est utilisée dans le code ci-dessus et fournit DateTime, elle n'est cependant pas indispensable.

La déclaration de dateOfSnapshot va permettre d'ajouter la date à laquelle a été effectué notre snapshot.

Les déclarations essentielles à notre fonction sont faites, il ne reste plus qu'à importer les fonctionnalités utilisées en tête de notre fichier tasks.service.ts :


    import { DateTime } from 'luxon';
    import { getManager, getConnectionOptions, ConnectionOptions } from 'typeorm';

    ...

📤 Export des tables SQL

Un script programmé par l'intermédiaire de l'API et exécuté sur le même serveur que l'API, va permettre la connexion au serveur MySQL et ainsi permettre l'export des différentes tables inclues dans votre base de données.

Pour poursuivre, le package shelljs (basé sur l'utilisation du module Node child_process) permettant l'exécution de processus externes va devoir être installé.

Utilisez npm install shelljs, puis, en dessous des imports de votre service tasks.service.ts, ajoutez :

    ...
    const shell = require('shelljs');
    const fs = require('fs');

    ...

Actuellement, si l'on part du principe que le nom de notre base de données correspond à : test_database, la constante tablesList préalablement définit contiendra un tableau dont le format sera le suivant :

[
    { Tables_in_test_database: 'first_table' },
    { Tables_in_test_database: 'second_table' },
    { Tables_in_test_database: 'third_table' },
]

Nous savons dès lors quelles tables exporter, nous avons également des identifiants d'authentification pour accéder à notre serveur MySQL, l'export peut commencer.

    ...

    try {
        console.log(`💾 Trying to export the database for the ${DateTime.now().toFormat('dd LLL yyyy')}..`);
        tablesList.map(table => { // Export of differents tables to .sql format
            const nameOfTable = Object.values(table)[0];
            const fileOfSnapshot = `${dateOfSnapshot}_${nameOfTable}.sql`;
            const resultOfExport = shell.exec(`${DOCKER_CONTAINER_NAME ? `docker exec ${DOCKER_CONTAINER_NAME} ` : ''}mysqldump -u ${databaseCredentials.username} --password=${databaseCredentials.password} ${databaseCredentials.database} ${nameOfTable} > ${fileOfSnapshot}`, { silent: !DEBUG_MODE });
            if (!String(fs.readFileSync(fileOfSnapshot, 'utf8')).includes('INSERT INTO')) // Check of SQL export
                throw `Unable to export '${nameOfTable}' table from the database!\n> ${resultOfExport.stderr}`;
            else console.log(`📥 SQL Table '${fileOfSnapshot}' is successfully retrieved.`);
        });
        console.log('✅ Database saved!');
    } catch (err) {
        console.log('❌ Snapshot of the database has failed!', DEBUG_MODE ? '\n' + err : '');
    }

On ajoute ici les instructions : try et catch.

ℹ️ Si la constante DOCKER_CONTAINER_NAME a été configurée, le premier ordre d'exécution concerne Docker et permet la connexion au serveur MySQL à travers le conteneur qui l'exécute.

La requête mysqldump est exécutée pour chaque table, alimentée par les informations d'authentification fournis par databaseCredentials (connexion courante retournée par TypeORM).

Chaque table est prétendument exportée (à la racine du projet pour le moment) au format .sql et selon fileOfSnapshot.

Pour le vérifier, nous utilisons la fonction readFileSync du module File System (fs), nous vérifions ainsi que le fichier cible existe et inclut bien la chaine alphanumérique INSERT INTO.

Si c'est le cas, la table suivante est exportée jusqu'à ce que toutes le soient. Le cas échéant, une occurrence de l'instruction catch survient et l'export échoue.

    💾 Trying to export the database for the 29 Apr 2023..
    📥 SQL Table '2023-04-29_first_table.sql' is successfully retrieved.
    📥 SQL Table '2023-04-29_second_table.sql' is successfully retrieved.
    📥 SQL Table '2023-04-29_third_table.sql' is successfully retrieved.
    ✅ Database saved!

Trois fichiers .sql ont été créés à la racine du projet.

Voyons à présent comment créer un snapshot en générant une archive (.zip) dans notre dossier backups.

🗂️ Génération d'une nouvelle archive (.zip) en guise de snapshot

Générer une archive est idéal pour garantir la sauvegarde de notre base de données, nos données sont dès lors compressées puis enregistrées et datées depuis un fichier .zip individuel, dans le répertoire préalablement créé : backups.

ℹ️ Des fichiers/répertoires autres que notre base de données peuvent parfois intégrer notre archive : pour certaines applications, il peut être nécessaire d'enregistrer le(s) répertoire(s) dans le(s)quel(s) sont hébergées les différentes ressources exploitées (= images de profil, uploads, etc..) pour garantir la disponibilité des ressources internes référencées en base de données.

A l'heure actuelle, seul l'export des tables SQL de notre base de données est effectué, à la racine de notre projet.

Voyons comment transformer ces exports en fichiers temporaires pour procéder à la création d'une archive :

Lorsque chaque table est exportée, le nom du fichier temporaire créé (.sql) doit être référencé dans le tableau exportedFiles (préalablement défini) :

    tablesList.map(table => { // Export of differents tables to .sql format
        const nameOfTable = Object.values(table)[0];
        const fileOfSnapshot = `${dateOfSnapshot}_${nameOfTable}.sql`;
        exportedFiles.push(fileOfSnapshot); // Push the temporarily file name here
        const resultOfExport = shell.exec(`${DOCKER_CONTAINER_NAME ? `docker exec ${DOCKER_CONTAINER_NAME} ` : ''}mysqldump -u ${databaseCredentials.username} --password=${databaseCredentials.password} ${databaseCredentials.database} ${nameOfTable} > ${fileOfSnapshot}`, { silent: !DEBUG_MODE });
        if (!String(fs.readFileSync(fileOfSnapshot, 'utf8')).includes('INSERT INTO')) // Check of SQL export
            throw `Unable to export '${nameOfTable}' table from the database!\n> ${resultOfExport.stderr}`;
        else console.log(`📥 SQL Table '${fileOfSnapshot}' is successfully retrieved.`);
    });

Nos deux instructions try et catch doivent ensuite être complétées par l'instruction finally. Elle permettra d'exécuter une opération à terme des opérations initiales, quelque soit l'issue des opérations.

Grâce à l'instruction finally, les fichiers temporairement créés seront supprimés à terme des opérations, que l'archive soit créée ou non :

    try {
        ...

    } catch (err) {
        console.log('❌ Snapshot of the database has failed!', DEBUG_MODE ? '\n' + err : '');
    } finally { // Finally, delete the temporarily .sql files
        exportedFiles?.map(exportedFile => 
            (fs.existsSync(exportedFile)) && shell.exec(`rm -rf ${exportedFile}`, { silent: !DEBUG_MODE }));
    }

Il ne nous reste plus qu'à implémenter la génération d'une archive (.zip) après que soient générés les exports temporaires (.sql) dans notre instruction try puis de s'assurer que l'archive soit correctement générée :

    console.log(`📦 Trying to generate an archive (.zip) from retrieved data..`);
    const resultOfArchive = shell.exec(`zip -r ${archiveToCreate} ${exportedFiles.join(' ')}`, { silent: !DEBUG_MODE }); // Create .zip archive from .sql exports
    if (fs.existsSync(archiveToCreate)) {
        console.log(`📎 (+) ${exportedFiles.length} table(s) added to archive.`);
        console.log(`✅ Snapshot '${archiveToCreate}' is successfully created.`);
    } else throw `Unable to generate a zip snapshot of the database!\n> ${resultOfArchive.stderr}`;

Les différentes tables exportées sont ici enregistrées dans un fichier .zip daté, dans notre répertoire backups. Si l'archive n'existe pas après l'opération : une erreur survient et un rapport d'erreurs est envoyé.

Quoi qu'il advienne de la création du snapshot au format .zip, les exports temporaires sont inévitablement supprimés en fin d'opération.

🤲 Aperçu global de notre fonction

    @Cron(CronExpression.EVERY_WEEK)
    async exportDB() {
        /* Settings */
        const DEBUG_MODE = false; // Pass to 'true' to print the script exec output and display errors
        const BACKUPS_DIRECTORY = 'backups'; // Directory where will be exported the snapshot
        const DOCKER_CONTAINER_NAME = false; // Add a Docker container name if your mysql server depends of Docker
        /* Database */
        const databaseCredentials: ConnectionCredentials<ConnectionOptions> = await getConnectionOptions('default');
        const tablesList = await getManager().query(`SHOW tables;`);
        /* Main declarations */
        const dateOfSnapshot = DateTime.now().toFormat('yyyy-LL-dd');
        const exportedFiles = [];
        const archiveToCreate = `${BACKUPS_DIRECTORY}/${dateOfSnapshot}_snapshot.zip`;
        try {
            console.log(`💾 Trying to export the database for the ${DateTime.now().toFormat('dd LLL yyyy')}..`);
            tablesList.map(table => { // Export of differents tables to .sql format
                const nameOfTable = Object.values(table)[0];
                const fileOfSnapshot = `${dateOfSnapshot}_${nameOfTable}.sql`;
                exportedFiles.push(fileOfSnapshot);
                const resultOfExport = shell.exec(`${DOCKER_CONTAINER_NAME ? `docker exec ${DOCKER_CONTAINER_NAME} ` : ''}mysqldump -u ${databaseCredentials.username} --password=${databaseCredentials.password} ${databaseCredentials.database} ${nameOfTable} > ${fileOfSnapshot}`, { silent: !DEBUG_MODE });
                if (!String(fs.readFileSync(fileOfSnapshot, 'utf8')).includes('INSERT INTO')) // Check of SQL export
                    throw `Unable to export '${nameOfTable}' table from the database!\n> ${resultOfExport.stderr}`;
                else console.log(`📥 SQL Table '${fileOfSnapshot}' is successfully retrieved.`);
            });
            console.log(`📦 Trying to generate an archive (.zip) from retrieved data..`);
            const resultOfArchive = shell.exec(`zip -r ${archiveToCreate} ${exportedFiles.join(' ')}`, { silent: !DEBUG_MODE }); // Create .zip archive from .sql exports
            if (fs.existsSync(archiveToCreate)) {
                console.log(`📎 (+) ${exportedFiles.length} table(s) added to archive.`);
                console.log(`✅ Snapshot '${archiveToCreate}' is successfully created.`);
            } else throw `Unable to generate a zip snapshot of the database!\n> ${resultOfArchive.stderr}`;
        } catch (err) {
            console.log('❌ Snapshot of the database has failed!', DEBUG_MODE ? '\n' + err : '');
        } finally { // Finally, delete the temporarily .sql files
            exportedFiles?.map(exportedFile => 
                (fs.existsSync(exportedFile)) && shell.exec(`rm -rf ${exportedFile}`, { silent: !DEBUG_MODE }));
        }
    }

L'export de notre base de données est dans cet exemple programmé chaque semaine.

A dates échéantes, le backup sera automatiquement effectué :

    💾 Trying to export the database for the 29 Apr 2023..
    📥 SQL Table '2023-04-29_first_table.sql' is successfully retrieved.
    📥 SQL Table '2023-04-29_second_table.sql' is successfully retrieved.
    📥 SQL Table '2023-04-29_third_table.sql' is successfully retrieved.
    📦 Trying to generate an archive (.zip) from retrieved data..
    📎 (+) 3 table(s) added to archive.
    📎 (+) 'uploads' directory added to archive. // can be added in the zip script execution
    ✅ Snapshot 'backups/2023-04-29_snapshot.zip' is successfully created.

Dans l'exemple ci-dessus, l'archive 2023-04-29_snapshot.zip a été créée dans le répertoire backups.

Elle inclut les trois différentes tables incluses dans notre base de données ainsi que le répertoire uploads du projet.

ℹ️ Ce sytème de backup ne permet pas la création de plusieurs snapshots dans la même journée, si l'intervale de la tâche CRON était par exemple définit à 6 heures : une archive serait créée la première fois puis mise à jour pour chaque prochaine occurence du même jour. Inclure le timestamp du snapshot deviendrait alors nécessaire.

🆘 Erreurs éventuelles

ℹ️ La constante DEBUG_MODE passée à true permet l'affichage des logs liées aux différentes opérations exécutées au cours de la sauvegarde de la base de données.

Une erreur liée à une insuffisance de permissions est fréquemment rencontrée sur les systèmes Linux lors de l'utilisation de Docker :

    > docker container ps -a

    > `Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: 
    Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1": dial 
    unix /var/run/docker.sock: connect: permission denied`

Pour changer rapidement les permissions de l'utilisateur en cours d'utilisation, utilisez : sudo chown $USER /var/run/docker.sock. L'exécution de Docker devient désormais possible sans recourir à une élévation de privilèges _(fix temporaire) _

Pour que les permissions de l'utilisateur persistent après le redémarrage de votre machine, il sera nécessaire d'ajouter l'utilisateur en cours d'utilisation au groupe docker en procédant de la sorte :

Créez le groupe "docker" s'il n'existe pas : sudo groupadd docker.

Ensuite, ajoutez l'utilisateur en cours d'utilisation au groupe fraîchement créé : sudo usermod -aG docker $USER. Finalement, intégrez-le au groupe en utilisant: newgrp docker (fix permanent)

⛓ Automatiser rapidement le deploy ou « pipeline CI/CD » avec Github Actions via protocole SSH

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:06:23 +0000

L'implémentation d'un « pipeline CI/CD » (= Continous Integration / Continuous distribution) est une pratique DevOps moderne. Elle permet d'automatiser le déploiement du code, créé par les équipes de développement, dans l'environnement de production, selon une série d'étapes.

Elle comble généralement une série d'opérations qui échappe à la mission des développeu.rs.ses, investi(e)s notament dans le développement d'un logiciel applicatif.

Tout au long du cycle de vie d'une application, le CI/CD :

1️⃣ Déploie intégralement et automatiquement l'application depuis un répertoire (partagé ou privé) à destination d'un environnement de production

2️⃣ Garantit l'intégrité du ou des services internes au(x) serveur(s) de production en procédant à une série de tests automatisés

3️⃣ Assure l'envoi de logs/rapports réguliers aux équipes de développement en ce qui concerne l'analyse du code, les tests ou les éventuels processus en cours d'exécution

4️⃣ Permet l'augmentation de la fréquence des mises à jour

5️⃣ Facilite, pour les équipes de développement : la mise à niveau de certains fichiers de configuration en production (variables d'environnement, etc..)

6️⃣ Prémunit l'environnement de production contre les éventuelles erreurs humaines

[...] Comment implémenter un « pipeline CI/CD » via protocole SSH depuis un répertoire avec Github Actions ?

⚠️ Pré-requis

Notre implémentation nécessite la disposition d'un serveur distant (environnement de production) incluant une application active (liée à un répertoire Github accessible).

L'authentification de notre serveur auprès de Github doit être configurée de sorte à ce qu'elle ne requiert aucun mot de passe. Une authentification par paire de clés SSH sans phrase de sécurité est nécessaire.

ℹ️ Le protocole SSH (Port 22) de votre serveur distant doit être activé.

🔐 Création d'une paire de clés SSH côté serveur

Le plugin dépendant de l'action que nous souhaitons utiliser pour la réalisation de notre CI/CD requiert un accès SSH. Dès lorsque le plugin est authentifié par notre serveur via le protocole SSH, il peut alors intéragir avec notre serveur et exécuter notre futur workflow (permettant le déploiement de notre application).

Commencons par créer une paire de clés SSH, côté serveur, pour permettre à l'action que nous utilisons de se connecter à notre serveur distant via le protocole SSH.

Une fois la connexion SSH avec notre serveur établie, localisons-nous dans le répertoire .ssh en utilisant cd ~/.ssh puis générons notre nouvelle paire de clés ed25519 grâce à la commande :

ssh-keygen -t ed25519 -a 200 -C "Key Comment"

ℹ️ Le schéma de signature ssh-rsa utilisant l'algorithme de hachage SHA-1 a été dépréciée depuis OpenSSH 8.8 (2021). Nous utilisons alors une paire de clés ed25519.

    > ssh-keygen -t ed25519 -a 200 -C "Key Comment"

`   (...)

    Generating public/private ed25519 key pair.
    Enter file in which to save the key (/home/yourusername/.ssh/id_ed25519):
    Created directory '/home/yourusername/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/yourusername/.ssh/id_ed25519.
    Your public key has been saved in /home/yourusername/.ssh/id_ed25519.pub.
    The key fingerprint is:
    SHA256:2m0FfefEAFeJ31mFw87DAfef3FA113ge Key Comment
    The key's randomart image is:
    +---[ED25519 256]----+
    |      .             |
    |                    |
    | .                  |
    |. . . .             |
    |. .=.o .S.          |
    | =o.o. ..   .       |
    |o +   .  .    o ..  |
    |.. .      oE   oo . |
    |o.        .o+o   o  |
    +------[SHA256]------+

Notre paire de clés est à présent générée.

Deux fichiers intègrent dorénavant notre répertoire .ssh : id_ed25519 et id_ed25519.pub. Une clé privée et une clé publique.

Imprimons dès lors le contenu de notre clé publique id_ed25519.pub en utilisant cat id_ed25519.pub puis complétons notre fichier authorized_keys par cette nouvelle clé en l'ajoutant à la fin du fichier. (= Utilisez sudo nano authorized_keys)

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCb4oUsXZ51L9DmH3UqSnwOAUr9w6AOZa8bYH8qsJAhypAjH9YvQteVXXQEY0ybaVE1cmpIKEyC2jmC/jOJ4b7bivlo2hgnLOrj3FPkDWO2yNNio9RnPXREBx7 Your Comment

Notre clé privée ~/.ssh/id_ed25519 peut dorénavant permettre à notre action de s'authentifier via le protocole SSH. Copiez-là en utilisant cat id_ed25519.

🌐 Mise à niveau du répertoire Github

Accédons à la page Github de notre project > Paramètres > Secrets et variables > Actions.

Quatre (ou cinq*) nouvelles variables doivent être ajoutées :

HOST (adresse distante de votre serveur)
USERNAME (nom d'utilisateur principal)
KEY (clé privée id_ed25519)
PORT (22)

() Si vous avez configuré **une phrase de sécurité* lors de la génération de votre paire de clés SSH, une cinquième variable PASSPHRASE doit alors être créée et assignée.

Le contenu de notre fichier ~/.ssh/id_ed25519 doit être intégralement copié/collé dans le champ de valeur de notre variable KEY.

Une fois ces variables enregistrées, le projet Github détient dès lors secrètement l'accès à notre serveur distant.

⚙️ Configuration du workflow Github Actions

Github inclut une rubrique "Actions" (Github Actions) spécifique à chaque projet, elle est dédiée à l'implémentation d'un « pipeline CI/CD ».

Cette plateforme va permettre une mise à l'écoute des évènements (= Push, Pull Request, Merge..) liés aux différentes branches de notre projet Github.

Lorsqu'un évènement survient, un runner (= serveur) exécute une action (code d'exécution) en tenant compte de la configuration d'un workflow (étapes du processus) et permet notament : le déploiement de notre code dans un environnement de production.

ℹ️ Un marketplace, rendu disponible par Github Actions, propose l'utilisation d'actions créées par des dévellopeu.rs.ses de la communauté (Ex: Deploy with Node.js, Deploy Node.js with Azure App, etc..)

Procédons à présent à la configuration de notre workflow.

Ouvrons la page de notre projet Github dans notre navigateur et rendons-nous dans l'onglet "Actions".

Le bouton "set up a workflow yourself" permet d'initialiser le fichier .github/workflows/main.yml à la racine de notre projet Github et autorise ainsi la configuration d'un workflow personnalisé.

ℹ️ Ce fichier est capable d'accéder aux variables secrètes enregistrées (accessibles depuis Github.com > Paramètres > Secrets et variables > Actions)

Inaugurons la création de notre fichier en ajoutant les lignes suivantes :

    name: CI/CD Deploy (using SSH)

    on:
      push:
        branches:
          - master

Le processus "CI/CD Deploy (using SSH)" est alors créé.

Il a pour rôle d'écouter les éventuels « Push » depuis la branche « master ».

Il nous faut à présent configurer une série d'étapes et d'actions à effectuer pour permettre à Github Actions de savoir quoi faire lorsqu'un(e) développeu.r.se « Push » du code sur la branche « master »

Pour cela, nous utiliserons l'action Github suivante : appleboy/ssh-action@v0.1.8

Cette action va permettre d'exécuter les différentes étapes de notre workflow de déploiement via l'utilisation du protocole SSH de notre serveur distant.

    name: CI/CD Deploy (using SSH)

    on:
      push:
        branches:
          - master

    jobs:
          build:
            name: Build
            runs-on: ubuntu-latest
            steps:
                - name: Deploy to production server
                  uses: appleboy/ssh-action@v0.1.8
                  with:
                    host: ${{ secrets.HOST }}
                    username: ${{ secrets.USERNAME }}
                    key: ${{ secrets.KEY }}
                    port: ${{ secrets.PORT }}
                    script: printf "Hello World!"

Une nouvelle étape "Deploy to production server" est ajoutée, elle requiert l'utilisation de l'action appleboy/ssh-action@v0.1.8.

Les variables secrètes host, username, key et port de notre répertoire sont alors récupérées et transmises à l'action pour permettre l'ouverture d'une session SSH depuis une authentification par paire de clés SSH.

ℹ️ Si vous avez configuré une phrase de sécurité lors de la création de votre paire de clés SSH, ajoutez la ligne : passphrase: ${{ secrets.PASSPHRASE }} en dessous de la ligne key: ${{ secrets.KEY }}. Elle permettra la prise en charge de votre phrase de sécurité.

La propriété script permet enfin d'ordonner une série d'opérations internes au serveur.

ℹ️ Des logs instantanées sont accessibles pour chaque déploiement et permettent le suivi du processus au fil de son exécution.

Il ne nous reste plus qu'à « commit » notre nouveau fichier .github/workflows/main.yml pour assister au premier déploiement automatisé 🔥

Une fois les modifications effectuées, Github Actions détecte un nouveau « Push » sur la branche « master ».

Une connexion SSH est dès lors initiée par ssh-actions depuis les accès secrets fournis. La commande printf "Hello World!" est alors exécutée au sein de notre serveur.

✅ Si l'authentification est approuvée par notre serveur, l'action retourne la synthèse des commandes à exécuter. Les réponses capturées, pour chaque commande, lors de l'exécution de l'étape "Deploy to production server", sont alors retransmises en temps réel.

======CMD======
printf "Hello World!"

======END======
Hello World!

==============================================
✅ Successfully executed commands to all host.
==============================================

❌ A contrario, le build sera un échec et cessera.

⚙️ Configuration du pipeline CI/CD

Github est dorénavant capable de détecter l'occurence d'un évènement et d'établir une connexion SSH avec notre serveur pour y exécuter une commande.

Une fois la connexion établie, il ne nous reste plus qu'à configurer la série d'opérations à exécuter via bash.

Dans le cas d'une simple application React, les tâches à entreprendre seraient les suivantes :

Se localiser dans le répertoire de notre application (nous utiliserons le répertoire ~/app-to-deploy)
Effectuer un pull du répertoire et ainsi bénéficier d'une version de l'application up-to-date.
Installer les dépendances du projet
Build l'application
Relancer l'application (via l'utilisation d'un process manager comme PM2)

Modifions dès lors notre fichier .github/workflows/main.yml pour y inclure le pipeline de notre CI/CD :

    name: CI/CD Deploy (using SSH)

    on:
      push:
        branches:
          - master

    jobs:
          build:
            name: Build
            runs-on: ubuntu-latest
            steps:
                - name: Deploy to production server
                  uses: appleboy/ssh-action@v0.1.8
                  with:
                    host: ${{ secrets.HOST }}
                    username: ${{ secrets.USERNAME }}
                    key: ${{ secrets.KEY }}
                    port: ${{ secrets.PORT }}
                    script: |
                      cd "app-to-deploy"
                      printf "[1/5] 📥 Pull of repository.."
                      git pull
                      printf "[2/5] 📦 Installation of packages.."
                      npm i
                      printf "[3/5] 🖨 Build of application.."
                      npm run build
                      printf "[4/5] 🔄 Restart the application.."
                      pm2 restart 0
                      printf "[5/5] ✅ Deploy is finished!"

Notre CI/CD est à présent fonctionnel 🎉

Les différentes opérations de notre script sont exécutées unes à unes. Elles seront ensuite retransmises via les logs du déploiement.

======CMD======
cd "app-to-deploy"
printf "[1/5] 📥 Pull of repository.."
git pull
printf "[2/5] 📦 Installation of packages.."
npm i
printf "[3/5] 🖨 Build of application.."
npm run build
printf "[4/5] 🔄 Restart the application.."
pm2 restart 0
printf "[5/5] ✅ Deploy is finished!"

======END======
out: [1/5] 📥 Pull of repository..
out: Updating ecb327c..934abbc
out: Fast-forward
out:  src/App.js | 2 +-
out:  1 file changed, 1 insertion(+), 1 deletion(-)
out: [2/5] 📦 Installation of packages..
out: up to date, audited 1611 packages in 10s
out: 235 packages are looking for funding
out:   run `npm fund` for details
out: 6 high severity vulnerabilities
out: To address all issues (including breaking changes), run:
out:   npm audit fix --force
out: Run `npm audit` for details.
out: [3/5] 🖨 Build of application..
out: > app-to-deploy@0.1.0 build
out: > react-scripts build
out: Creating an optimized production build...
out: Compiled successfully.
out: File sizes after gzip:
out:   46.63 kB  build/static/js/main.80a26327.js
out:   1.78 kB   build/static/js/787.d08cf7c1.chunk.js
out:   541 B     build/static/css/main.073c9b0a.css
out: The project was built assuming it is hosted at /.
out: You can control this with the homepage field in your package.json.
out: The build folder is ready to be deployed.
out: You may serve it with a static server:
out:   npm install -g serve
out:   serve -s build
out: Find out more about deployment here:
out:   https://cra.link/deployment
out: [4/5] 🔄 Restart the application..Use --update-env to update environment variables
out: [PM2] Applying action restartProcessId on app [0](ids: [ '0' ])
out: [PM2] [my-app](0) ✓
out: ┌────┬───────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
out: │ id │ name      │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
out: ├────┼───────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
out: │ 0  │ my-app    │ default     │ N/A     │ fork    │ 34966    │ 0s     │ 15   │ online    │ 0%       │ 3.4mb    │ ***   │ disabled │
out: └────┴───────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
out: [5/5] ✅ Deploy is finished!
==============================================
✅ Successfully executed commands to all host.
==============================================

Il ne tient plus qu'à vous de personnaliser le script d'exécution avant de procéder au déploiement de votre ou vos application(s)/serveur(s).

🚀 Deploy d'une App Node.js avec NGINX et PM2 + Config Linux Server + Certificat SSL

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:05:51 +0000

« Mise en prod' » , « Deploy », « Push ».. Tant d'expressions qui permettent de signifier l'aboutissement d'un long chemin de développement : ça y est, votre code est fin prêt à être déployé dans un environnement de production et votre application/serveur exposé(e) au monde entier.

Si vous n'avez jamais mis d'applications en ligne auparavant, les appréhensions peuvent être nombreuses.

Comment configurer un serveur Linux pour exécuter des applications Node.js ? Pourquoi utiliser un gestionnaire de processus ? Comment mettre en place un certificat SSL et profiter du protocole HTTPS ? Comment configurer la zone DNS d'un nom de domaine ?

⚙️ Pré-configuration de votre serveur

L'utilisation d'un VPS (= Virtual Private Server) est l'une des solutions les plus adaptées lorsque l'on doit déployer par exemple une ou plusieurs applications Node.js.

Vulgairement parlant, un VPS : c'est une machine comme la votre exposée via une adresse IPv4 dédiée, qui a pour vocation d'être allumée 24h/24 - 7j/7. Elle a généralement la particularité d'intégrer un système d'exploitation minimaliste, léger et nécessitant peu de ressources : Linux.

📶 La connexion à ce serveur distant est effectuée via le protocole SSH (Port 22), c'est par l'intermédiaire d'une invite de commande que notre serveur va être configurable.

Lorsque vous commandez un VPS, les informations suivantes vous sont communiquées :

Adresse IP (Host)

Username

Password

Port (22)

Ces informations permettent d'établir une connexion SSH. La plupart des systèmes d'exploitations intègrent aujourd'hui un client SSH mais certains nécessitent l'utilisation d'un client SSH tierce, c'est le cas avec Windows par exemple : l'installation du logiciel PuTTY est alors requise.

Si votre VPS est livré avec un système d'authentification : hôte / nom d'utilisateur / mot de passe, il n'a cependant pas pour vocation à le rester. Ce type d'authentification est exposé à de nombreux types d'attaques, le bruteforce notament.

Pour pallier à cette problématique : l'autorisation d'un client par le serveur depuis une pair de clé SSH préalablement générée

La première mise à niveau du serveur implique alors les actions suivantes :

Autoriser une/des clé(s) pour s'authentifier au protocole SSH
Supprimer l'authentification par mot de passe du protocole SSH

🔑 Générer une nouvelle pair de clé SSH, localement

🌕 Si vous utilisez Linux

Accédez localement à votre dossier ~/.ssh puis générez une nouvelle clé si vous n'en n'avez pas déjà une :

    cd ~/.ssh
    ssh-keygen -t rsa -b 4096 -C "your_label"

Vous n'êtes pas obligé(e) d'inclure une passphrase à votre nouvelle clé, appuyez sur ENTRER sans même saisir de phrase de sécurité, celle-ci est souvent négligée par les développeurs, notament lorsqu'une clé est sollicitée en guise d'authentification via un processus automatisé.

    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/yourusername/.ssh/id_rsa):
    Created directory '/home/yourusername/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/yourusername/.ssh/id_rsa.
    Your public key has been saved in /home/yourusername/.ssh/id_rsa.pub.
    The key fingerprint is:
    SHA256:2m0FfefEAFeJ31mFw87DAfef3FA113ge your_label
    The key's randomart image is:
    +---[RSA 4096]----+
    |      .          |
    |                 |
    | .               |
    |. . . .          |
    |. .=.o .S.       |
    | =o.o. ..   .    |
    |o +   .  . o ..  |
    |.. .      oEoo . |
    |o.        .o+oo  |
    +-----------------+

Votre pair de clé est à présent créée.

Récupérez votre clé publique grâce à la commande suivante : cat ~/.ssh/id_rsa.pub.

C'est cette clé que nous autoriserons côté serveur, nous pourrons ainsi nous authentifier à notre serveur distant sans même avoir à justifier d'un mot de passe*.
(*) sous réserve qu'aucune phrase de sécurité n'ai été définie

🌑 Si vous utilisez Windows

Le logiciel PuTTYGen va vous permettre de générer une nouvelle pair de clé.

Une fois le logiciel ouvert, cliquez sur "Generate", agitez la souris aux 4 coins de la fenêtre (stimulation cryptographique) et patientez un instant durant la génération de votre clé.

Cette clé publique générée a vocation d'être autorisée auprès de notre serveur. Notre clé privée permettra de nous authentifier avec PuTTY via le protocole SSH sans utiliser de mot de passe*.
(*) sous réserve qu'aucune phrase de sécurité n'ai été définie

Cliquez ensuite sur le bouton "Save private key" pour enregistrer votre clé au format .ppk (Putty Private Key - format dédié à PuTTY).

🚦 Connexion au serveur et autorisation de notre nouvelle clé

Il est temps de se connecter pour la première fois à notre serveur, nous utiliserons logiquement l'adresse distante de notre machine, l'identifiant et le mot de passe fournis par notre hébergeur.

    ssh ubuntu@102.49.82.203
    ...

    login as: ubuntu
    ubuntu@102.49.82.203's password:

Une fois connecté(e),

Ouvrez le fichier authorized_keys via la commande : sudo nano ~/.ssh/authorized_keys

[...] Et ajoutez votre clé publique, précédemment générée, en la collant.

ℹ️ Voici un exemple de ce à quoi pourrait ressembler votre fichier ~/.ssh/authorized_keys si vous aviez autorisé plusieurs clés; toutes les clés autorisées peuvent permettre de s'authentifier au serveur sans mot de passe :

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAQQCo9+BpMRYQ/dL3DS2CyJxRF+j6ctbT3/Qp84+KeFhnii7NT7fELilKUSnxS30WAvQCCo2yU1orfgqr41mM70MB your_label
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCb4oUsXZ51L9DmH3UqSnwOAUr9w6AOZa8bYH8qsJAhypAjH9YvQteVXXQEY0ybaVE1cmpIKEyC2jmC/jOJ4b7bivlo2hgnLOrj3FPkDWO2yNNio9RnPXREBx7 special_key

Sauvegardez à présent votre fichier, félicitations 🎉

Vous pouvez dorénavant vous authentifier auprès de votre serveur en utilisant la clé précédemment générée.

Voyons à présent comment s'authentifier à notre serveur.

🔒 S'authentifier à notre serveur via SSH grâce à notre nouvelle clé

🌕 Si vous utilisez Linux

Connectez-vous à votre serveur via la commande traditionnelle : ssh user@host

✅ Aucun mot de passe n'est à présent requis, l'authentification est directement effectuée.

Si une phrase de sécurité (= passphrase) a été configurée lors de la génération de votre clé, cette dernière sera requise lors de la tentative de connexion :

    login as: ubuntu
    Authenticating with public key "id_rsa"
    Passphrase for key "id_rsa":

🌑 Si vous utilisez Windows

Ouvrez le logiciel PuTTY (à ne pas confondre avec PuTTYGen permettant de générer des clés) et renseignez l'adresse de votre serveur distant, définissez le port SSH (22).

Rendez-vous dans la catégorie : Connection > SSH > Auth > Credentials.

Localisez votre clé privée (au format .ppk) préalablement enregistrée lors de l'étape de la génération de clé.

Retournez dans la catégorie "Sessions" puis cliquez sur "Save". Vos informations de connexion (y compris votre clé privée) seront alors gardés en mémoire.

Séléctionnez à présent la session que vous venez de sauvegarder et lancez-là.

Vous êtes à présent authentifié(e) à votre serveur*.
(*) sous réserve qu'aucune phrase de sécurité n'ai été définie

⛔ Désactiver l'authentification par identifiant / mot de passe

Notre authentification via clé SSH est à présent fonctionnelle ✅

L'authentification par l'intermédiaire d'une combinaison identifiant / mot de passe peut alors être supprimée, elle est la potentielle porte d'entrée à d'éventuelles intrustions malveillantes.

Commencons par modifier le fichier /etc/ssh/sshd_config en utilisant la commande :

sudo nano /etc/ssh/sshd_config

Notre mission : repérer les variables suivantes :

PasswordAuthentication
ChallengeResponseAuthentication
UsePAM

[...] et leur attribuer la valeur suivante : no.

ℹ️ Si l'une de ces variables est absente, rajoutez-là manuellement et définissez-là à no.

La variable PubkeyAuthentication quant à elle doit être définie à yes.

Dès lorsque les modifications sont terminées, utilisez généralement CTRL + X pour fermer et saisissez "Y" pour confirmer les changements.

ℹ️ Vérifiez parallèlement qu'aucun fichier .conf ne soit inclus dans les répertoires suivants : /etc/ssh/ssh_config.d et /etc/ssh/sshd_config.d. Certains hébergeurs définissent parfois des variables dans des fichiers de configuration à ces endroits pour, entre autre, autoriser la connexion via identifiant / mot de passe.

Le serveur SSH aura besoin d'être redémarré pour que les changements soient pris en compte, saisissez la commande suivante : sudo systemctl restart sshd ssh.

Notre serveur n'accepte dorénavant plus les connexions avec mot de passe. Seules les clés autorisées via notre registre ~/.ssh/authorized_keys pourront s'authentifier au protocole SSH de notre serveur.

📥 Télécharger et installer la dernière version de Node.js

Node.js est souvent téléchargé depuis les dépôts officiels / PPA (= Personal Package Archives) Ubuntu.

Nous délaisserons cette méthode en téléchargeant directement Node.js depuis la page de téléchargement du site officiel, selon la version souhaitée. Ainsi, nous sommes certains de pouvoir profiter d'une version up-to-date.

ℹ️ Dans un environnement de production, il est recommandé d'utiliser l'une des dernières versions de Node.js.

Dans ce tutoriel, nous utiliserons la version 18.15.0.

1️⃣ Localisez-vous au chemin d'accès par défaut ~ de votre serveur grâce à cd ~/ puis téléchargez la version Node.js cible depuis le site officiel grâce à la commande :

wget https://nodejs.org/dist/v18.15.0/node-v18.15.0-linux-x64.tar.xz

    --2023-04-01 12:49:28
    --`https://nodejs.org/dist/v18.15.0/node-v18.15.0-linux-x64.tar.xz`
    Resolving nodejs.org (nodejs.org)... 2606:4700:10::6814:162e, 2606:4700:10::6814:172e, 104.20.23.46, ...
    Connecting to nodejs.org (nodejs.org)|2606:4700:10::6814:162e|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 23637576 (23M) [application/x-xz]
    Saving to: ‘node-v18.15.0-linux-x64.tar.xz’

    `node-v18.15.0-linux` 100%[===================>]  22.54M  28.9MB/s    in 0.8s    

    2023-04-01 12:49:28 (28.9 MB/s) - ‘node-v18.15.0-linux-x64.tar.xz’ saved [23637576/23637576]

2️⃣ Décompressez le fichier .tar.xz téléchargé en utilisant :

sudo tar -xvf node-v18.15.0-linux-x64.tar.xz

3️⃣ Puis transférez les fichiers source de Node.js dans le répertoire /usr/ en utilisant la commande :

sudo cp -r node-v18.15.0-linux-x64/{bin,include,lib,share} /usr/

4️⃣ Supprimons sans tarder notre fichier node-v18.15.0-linux-x64.tar.xz ainsi que le répertoire décompressé node-v18.15.0-linux-x64, ils ne nous seront plus d'aucune utilité.

sudo rm -rf node-v18.15.0-linux-x64 node-v18.15.0-linux-x64.tar.xz

5️⃣ Ouvrez à présent le script de votre shell via sudo nano ~/.bashrc et exposez Node.js en ajoutant la ligne suivante, à la fin :

export PATH=/usr/node-v18.15.0-linux-x64/bin:$PATH

6️⃣ Rechargez à présent le script shell ~/.bashrc en utilisant source ~/.bashrc.

Node.js est normalement installé ✅

Vérifiez que l'installation soit conforme en saisissant node -v dans votre terminal.

🔐 Authentification auprès de Github

Git est et restera sans doûte le meilleur ami de celles & ceux qui pratiquent la programmation. Il est un outil indispensable du quotidien et sert notament d'intermédiaire entre votre environnement de développement et votre environnement de production.

La configuration de l'authentification avec Github est particulièrement importante.

L'authentification via pair de clé SSH peut par exemple outrepasser la nécessité de justifier d'un mot de passe. Elle peut alors permettre la manipulation automatisée d'un 🌐 repository grâce à un processus de CI/CD (= Continuous Integration/Continuous Delivery).

🔒 Intéressons-nous à l'authentification via pair de clé SSH.

Lors de la configuration de notre serveur Linux : nous avions généré, localement, une pair de clé SSH et nous avions autorisé notre clé publique depuis le serveur.

Cette fois, c'est sur le serveur que la pair de clé SSH va devoir être générée. La clé publique sera transmise à Github via les paramètres de notre compte et les échanges avec Github seront dès lors authentifiés.

Localisez-vous dans le dossier ~/.ssh de votre machine distante puis générez votre nouvelle pair de clé SSH :

    cd ~/.ssh
    ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"

Suivez la procédure de génération, ajoutez ou non une phrase de sécurité puis patientez un instant.

    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): 
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/ubuntu/.ssh/id_rsa
    Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub
    The key fingerprint is:
    SHA256:c7bEyoefeR09TZ9vnEmddK2LwD4XRo4ZCLfmE3kKKTWoM your_email@domain.com
    The key's randomart image is:
    +---[RSA 4096]----+
    |    o . oo  .    |
    |  .  o     . o   |
    | o .  o   . + .  |
    |o      . + + .  .|
    |E s.    S X .   +|
    |.o     . B T..+.+|
    |.       = *.+o.* |
    |  ..  .  *.  .o o|
    |        ..o.     |
    +----[SHA256]-----+

Il ne vous reste plus qu'à copier votre clé publique en utilisant : cat ~/.ssh/id_rsa.pub.

Rendez-vous sur https://github.com/settings/keys, cliquez sur "Nouvelle clé SSH" puis ajoutez votre clé publique en l'identifiant par un nom de référence.

Vérifiez, dans le terminal de votre serveur, que vous êtes bien authentifié en utilisant la commande : ssh -T git@github.com.

Si vous êtes authentifié, vous reçevrez un message similaire à celui-ci 👇

Hi {username}! You've successfully authenticated, but GitHub does not provide shell access.

[...] Vous pouvez à présent cloner votre projet sur votre serveur.

🟰 Cloner une application depuis un repository Git

A la racine ~ de votre serveur distant, clônez votre application grâce à la commande :

git clone git@github.com:{username}/{project}.git

ℹ️ Prenez soin d'actualiser les variables { } par vos données (= nom d'utilisateur Git et nom de projet).

Une fois votre application clônée et accessible en local, localisez-vous à la racine de votre projet à l'aide du nom de votre projet précédé par la commande cd.

ℹ️ Supposons que notre application soit une simple application React.

Créez votre fichier d'environnement de production (dotenv) à la racine (= .env ou .env.local).

Installez vos dépendances et lancez le build de votre projet à l'aide de npm i et npm run build.

⚙️ Vérifiez que votre application puisse se lancer via npm run start et tentez de joindre votre application via l'adresse de votre machine depuis le port utilisé par Node.js.

Mettez fin au processus (CTRL + C).

⚠️ Soyez sûre que votre application soit fonctionnelle en installant les éventuels services dépendants (= (No)SQL database, Redis, Docker, API..)

📂 Utiliser le protocole SFTP dédié aux transferts de fichiers

Que vous utilisiez Mac OS, Windows ou Linux, le logiciel de transfert de fichiers FileZilla vous permettra via une interface graphique de gérer les ressources de votre serveur (répertoires/fichiers).

ℹ️ Le transfert de fichiers se révèle particulièrement indispensable pour les sites web basiques incluant un système d'upload de fichiers. Ces derniers n'utilisant pas de solutions liées au cloud comme S3 AWS / Azure / Google Storage etc.. Les fichiers sont alors stockés sur le serveur.

Le transfert de fichiers requiert l'utilisation d'un protocole FTP (= File Transfert Protocol). Un serveur FTP (Port 21) doit alors être installé sur le serveur.

Pour pallier à cette épreuve, une alternative s'offre à nous : le SFTP (= SSH File Transfert Protocol).

Le SFTP accompli les missions du FTP mais en utilisant un autre protocole : le SSH (Port 22), le même que nous utilisons quotidiennement pour intéragir via shell avec notre serveur distant. Nous bénéficions dès lors des atouts qu'offre le SSH : à savoir une connexion sécurisée via pair de clé SSH.

En principe et selon notre mode opératoire, FileZilla charge notre clé SSH (préalablement générée) et la transmet à notre serveur qui nous autorise à établir la connexion.

Renseignez dès-lors l'adresse IPv4 de votre serveur, votre identifiant, le port : 22 puis procédez à la connexion.

✅ Votre clé SSH est détectée, transmise et approuvée par le serveur, vous êtes authentifié(e).

La clé n'est pas détectée ?

Si la clé n'est pas détectée, vous utilisez probablement Windows. Dans FileZilla, localisez la clé .ppk que vous aviez générée avec PuTTYGen depuis :

Filezilla > Fichier > Gestionnaire de sites > Type d'authentification > Fichier de clef

[...] Et chargez votre clé, la connexion devrait à présent aboutir.

📥 Installer et configurer le gestionnaire de processus PM2

Le gestionnaire de processus va permettre d'initialiser chacune de vos applications Node.js en les répertoriant dans des conteneurs centralisés. Il va occuper un rôle majeur en ce qui concerne la maintenance et le processus de déploiement de vos applications.

Chacun de ces conteneurs peut alors être (re)démarré/arrêté et exploité individuellement.

🔁 En cas de redémarrage impromptu du serveur, le gestionnaire de processus permet de redémarrage de l'intégralité de vos applications afin d'éviter une indisponibilité prolongée de vos services. Il donne également accès aux logs et à un système de monitoring efficace concernant vos processus.

Nous utiliserons PM2, une librairie disponible sur yarn et npm, simple, complète et efficace d'utilisation.

💡 Et si nous n'utilisions pas de gestionnaire de processus ?

Si par exemple vous démarriez votre application via une session SSH sans utiliser de gestionnaire de processus (via npm run start par exemple) : un processus serait alors lancé.

Dans l'hypothèse où vous abandonneriez ce(tte) terminal/session, vous perderiez la main sur le processus mais celui-ci continuerai alors d'être exécuté en arrière plan (vous pourriez évidement le reprendre dans une session ultérieure).

Si hasardeusement, vous oublieriez qu'une application Node.js était déjà en cours d'exécution, vous la lanceriez une nouvelle fois et il n'existerait alors pas moins de deux occurences d'une même application Node.js (x2 processus en arrière plan).

Autrement, si vous aviez par exemple plusieurs applications Node.js sur le même serveur, vous ne pourriez même pas les distinguer dans la liste des processus en cours d'exécution.

C'est à ces problématiques que le gestionnaire de processus PM2 apporte des solutions 🔥

💹 Comment ça fonctionne ?

Installons maintenant notre gestionnaire de processus, sur notre serveur distant, via la commande :

sudo npm i pm2 -g

Vérifiez que PM2 soit installé sur votre machine en exécutant : pm2 -v.

ℹ️ Le drapeau -g permet d'installer la librairie globalement et d'enregistrer la nouvelle variable d'environnement pm2.

Le mode de fonctionnement de PM2 permet d'initialiser un nouveau processus depuis la racine d'une application Node.js, au même niveau que notre traditionnel package.json.

Il intègre d'ailleurs la reconnaissance d'un fichier de configuration intitulé ecosystem.config.js. Dès lorsque ce fichier est présent à la racine de votre projet, il va permettre au gestionnaire de processus de démarrer votre application avec les différentes propriétés spécifiées.

ℹ️ La documentation des différentes propriétés disponibles pour la configuration du fichier ecosystem.config.js est disponible en ligne.

Avant d'initialiser votre application dans PM2, prenez-soin de créer un fichier ecosystem.config.js à la racine de votre projet puis d'y apporter la configuration requise minimale :

    module.exports = {
        apps : [{
            name: 'my-process-name',
            script : "npm run start",
        }]
    };

Exécutez à présent la commande pm2 start à la racine de votre projet.

    [PM2][WARN] Applications my-process-name not running, starting...
    [PM2] App [my-process-name] launched (1 instances)
    ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
    │ id │ name               │ mode     │  ↺   │ status    │ cpu      │ memory   │
    ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
    │ 0  │ my-process-name    │ fork     │ 0    │ online    │ 0%       │ 10.2mb   │
    └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

Le nouveau processus est créé et démarré 🎉

D'autres applications peuvent ainsi être ajoutées à la liste des processus PM2.

ℹ️ La commande pm2 startup ubuntu permet de garantir le redémarrage de vos processus après un éventuel crash/reboot intempestif de votre machine.

L'exécution, l'arrêt et le redémarrage de votre application devra à présent passer par PM2.

    // Lister les processus référencés
    pm2 list

    // Démarrer une application
    pm2 start my-process-name

    // Arrêter une application
    pm2 stop my-process-name

    // Redémarrer une application
    pm2 restart my-process-name

    // Accéder aux logs d'une application
    pm2 logs my-process-name

    // Accéder au panel de monitoring instantanée
    pm2 monit

    // Sauvegarder le référencement des applications chargées
    pm2 save

    // Restaurer des applications depuis une sauvegarde
    pm2 resurrect

    // Démarrer les processus lors du démarrage du système
    pm2 startup ubuntu

📥 Installer et configurer le serveur web NGINX

L'utilisation d'un serveur web en guise de surcouche à Node.js est tout à fait recommandé. Le serveur web Nginx offre par exemple de nombreux avantages :

Concentrer l'audience de vos applications sur un même port (80 par défaut)
Intégrer d'indénombrables fichiers de configuration clairs et documentés. (Voir la documentation officielle)
Optimiser le traitement des requêtes
Gérer la mise en cache et la compression des données

[...] Et surtout : permettre l'utilisation d'un Reverse Proxy 🔥

Le proxy inverse permet de :

Rediriger des requêtes entrantes vers différents serveurs internes utilisant différents protocoles.
Agir en tant que répartiteur de charge entre plusieurs serveurs, si configuré comme tel.
Décharger les serveurs d'une charge d'objets/pages statiques via la gestion d'un cache web local.
Agir en tant que point de terminaison TLS et permettre le chiffrement via certificat SSL.
Réduire la charge de traitement cryptographique (= HTTPS) si installé sur une machine différente des serveurs applicatifs.
[...]

ℹ️ L'utilisation du reverse proxy a pour vocation de n'exposer que le port 80. Ainsi, les différents ports qu'occupent nos applications internes pourront être bloqués par notre pare-feu.

Procédons à l'installation de Nginx sur notre machine distante :

sudo apt install nginx

    Reading package lists... Done
    Building dependency tree... Done
    Reading state information... Done
    The following packages were automatically installed and are no longer required:
      javascript-common libc-ares2 libjs-highlight.js libnode72 nodejs-doc
    Use 'sudo apt autoremove' to remove them.
    The following additional packages will be installed:
      libnginx-mod-http-geoip2 libnginx-mod-http-image-filter
      libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream
      libnginx-mod-stream-geoip2 nginx-common nginx-core
    Suggested packages:
      fcgiwrap nginx-doc ssl-cert
    The following NEW packages will be installed:
      libnginx-mod-http-geoip2 libnginx-mod-http-image-filter
      libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream
      libnginx-mod-stream-geoip2 nginx nginx-common nginx-core
    0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
    Need to get 696 kB of archives.
    After this operation, 2395 kB of additional disk space will be used.
    Do you want to continue? [Y/n]

Saisissez "Y" et appuyez sur ENTRER.

✅ Nginx est à présent installé sur votre machine.

Remplacez intégralement le contenu du fichier /etc/nginx/sites-available/default :

sudo nano /etc/nginx/sites-available/default

[...] par le code suivant :

    server {
        listen 80 default_server;
        listen [::]:80 default_server;

        server_name yourdomain.com www.yourdomain.com;
        location / {
            proxy_pass 'http://127.0.0.1:{port}';
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Port $server_port;
        }
    }

ℹ️ Soyez certain(e) d'avoir remplacer la variable {port} par le port utilisé par votre application Node.js et (www.)yourdomain.com par votre nom de domaine. Nous pourrons ensuite installer un certificat SSL.

Lorsque vous installez Nginx, la taille maximale d'une requête prise en charge par Nginx est restreinte à 1MB par défaut. Au delà, le requête sera rejetée ou ignorée.

Pour modifier ce paramètre, ouvrez le fichier de configuration /etc/nginx/nginx.conf et ajoutez la ligne suivante dans la section http si elle n'existe pas déjà :

client_max_body_size 50M;

⚠️ Vérifiez que la configuration globale soit conforme en exécutant sudo nginx -t puis redémarrez Nginx pour intégrer les modifications.

Utilisez sudo service nginx restart ou sudo systemctl restart nginx.

Lancez à présent votre application via PM2 et essayez de joindre votre application via HTTP (port 80 de votre machine).

ℹ️ L'installation d'un certificat SSL via la librairie Certbot viendra compléter le fichier de configuration /etc/nginx/sites-available/default pour permettre l'utilisation et la redirection HTTPS.

Si vous vouliez par exemple créer des sous-domaines et utiliser plusieurs méthodes de Proxy Reverse, vous pourriez configurer votre fichier /etc/nginx/sites-available/default selon le principe suivant :

    # Domain | www.domain.com

    server {
        server_name domain.com www.domain.com;
        location / {
            proxy_pass 'http://hostname:{port}';
        }
    }

    # Sub-domain n°1 | subdomain1.domain.com

    server {
        server_name subdomain1.domain.com www.subdomain1.domain.com;
        location / {
            proxy_pass 'http://hostname:{port}';
        }
    }

    # Sub-domain n°2 | subdomain2.domain.com

    server {
        server_name subdomain2.domain.com www.subdomain2.domain.com;
        location / {
            proxy_pass 'http://hostname:{port}';
        }
    }

Pour garantir de bonnes conditions de maintenance et renforcer l'organisation structurelle de notre Reverse Proxy, il serait préférable de supprimer notre fichier /etc/nginx/sites-available/default et de créer un fichier pour chaque (sous-)domaine.

L'arborescence des (sous-)domaines serait alors plus simple à distinguer.

    # Domain | www.domain.com

    server {
        server_name domain.com www.domain.com;
        location / {
            proxy_pass 'http://hostname:{port}';
        }
    }

    # Sub-domain n°1 | subdomain1.domain.com

    server {
        server_name subdomain1.domain.com www.subdomain1.domain.com;
        location / {
            proxy_pass 'http://hostname:{port}';
        }
    }

Une fois les fichiers de configurations référents à vos différents (sous-)domaines créés dans le répertoire /etc/nginx/sites-available, créez un lien symbolique pour chacun de vos fichiers depuis ce répertoire, au répertoire /etc/nginx/sites-enabled/ en utilisant :

    cd ~
    sudo ln -s /etc/nginx/sites-available/domain.com /etc/nginx/sites-enabled/domain.com
    sudo ln -s /etc/nginx/sites-available/subdomain1.domain.com /etc/nginx/sites-enabled/subdomain1.domain.com
    ...

⚠️ Vérifiez que la configuration globale soit conforme en exécutant sudo nginx -t puis redémarrez Nginx pour intégrer les modifications.

Utilisez sudo service nginx restart ou sudo systemctl restart nginx.

🛡️ Activation du pare-feu serveur

Dès lorsque nos applications Node.js sont accessible via le port 80 qu'utilise notre serveur web Nginx, il est judicieux d'activer le pare-feu et ainsi n'autoriser que les protocoles ayant pour vocation d'être exploités sur notre machine tels que :

SSH / SFTP (22)
HTTP(S) (80 / 443)

Exécutez les commandes suivantes :

    sudo ufw enable
    sudo ufw allow ssh
    sudo ufw allow http
    sudo ufw allow https

Utilisez la commande sudo ufw status pour obtenir une synthèse des réglementations.

    Status: active

    To                         Action      From
    --                         ------      ----
    22/tcp                     ALLOW       Anywhere                  
    80                         ALLOW       Anywhere                  
    443                        ALLOW       Anywhere                  
    22/tcp (v6)                ALLOW       Anywhere (v6)             
    80 (v6)                    ALLOW       Anywhere (v6)             
    443 (v6)                   ALLOW       Anywhere (v6)

🌐 Configuration de la zone DNS d'un nom de domaine

C'est une étape primordiale lorsqu'une activitée prend naissance sur le web : la configuration de la zone DNS du nom de domaine.

La zone DNS d'un nom de domaine est un espace administratif gérée par une organisation ou un administrateur spécifique qui permet le contrôle sur les différentes entrées du nom de domaine.

Lorsque vous reçevez votre nouveau nom de domaine, la zone DNS de votre nom de domaine est souvent pré-configuré par votre hébergeur de telle sorte à ce que vous puissiez dors et déjà par exemple accéder au protocole FTP du serveur cible via la pré-configuration d'un enregistrement CNAME (= ftp.domain.com).

ℹ️ Retrouvez la liste des différents enregistrements DNS existants

Exemple d'espace d'administration de la zone DNS d'un nom de domaine (OVH) 👇

Ci-dessous, un aperçu textuel de la configuration de la zone DNS de notre nom de domaine :

    $TTL 3600
    @   IN SOA dns200.anycast.me. tech.ovh.net. (2023020018 86400 3600 3600000 60)
                              IN NS     ns200.anycast.me.
                              IN NS     dns200.anycast.me.
                              IN MX     1 mx4.mail.ovh.net.
                              IN MX     10 mx3.mail.ovh.net.
                              IN A      164.132.50.110
                              IN TXT    "1|www.domain.com"
    _autodiscover._tcp        IN SRV    0 0 443 mailconfig.ovh.net.
    _imaps._tcp               IN SRV    0 0 993 ssl0.ovh.net.
    _submission._tcp          IN SRV    0 0 465 ssl0.ovh.net.
    subdomain1                IN CNAME  domain.com.
    autoconfig                IN CNAME  mailconfig.ovh.net.
    autodiscover              IN CNAME  mailconfig.ovh.net.
    ftp                       IN CNAME  domain.com.
    subdomain2                IN CNAME  domain.com.
    www                       IN A      164.132.50.110
    www                       IN TXT    "3|welcome"

La première action à entreprendre : modifier l'adresse IPv4 cible de l'enregistrement de Type A en renseignant l'adresse IPv4 de votre serveur distant, pour les deux entrées existantes : domain.com (Type A) et www.domain.com (Type A).

Le nom de domaine sera dès lors reconnu par n'importe quel naviguateur et dirigera le client à votre serveur distant.

Pour créer un sous-domaine, créez une nouvelle entrée de Type CNAME, ciblez votre nom de domaine et spécifiez l'intitulé du sous-domaine à créer, puis validez.

ℹ️ Un délai de propagation implique parfois d'attendre jusqu'à 24 heures avant de garantir l'accessibilité à votre nouveau sous-domaine.

Lorsque vous requêterez votre sous-domaine, Nginx sera capable d'interprêter l'origine de la requête et vous redirigera auprès de l'application cible (selon votre configuration via proxy).

🔒 Mise en place d'un certificat SSL avec Certbot

Maintenant que notre nom de domaine nous redirige vers notre serveur distant, que le serveur web Nginx interprête l'origine de notre requête et nous redirige vers l'application cible ;

Etablissons une connexion sécurisée entre client/serveur grâce au protocole HTTPS.

L'utilisation du protocole HTTPS nécessite l'utilisation d'un certificat numérique permettant aux navigateurs de vérifier l'identité des serveurs web. Des tiers de confiance, soit des autorités de certification (AC) sont chargées de déléguer les certificats aux serveurs web.

Une librairie nommée « Certbot » récupère des certificats depuis l'autorité de certification Let's Encrypt, (autorité de certification lancée à l'initiative de Mozilla notament). Nous l'utiliserons pour implémenter rapidement notre certificat SSL avec Nginx.

Installons Certbot, depuis notre machine distante :

sudo apt install certbot python3-certbot-nginx

Procédons à l'installation de notre certificat SSL en utilisant Certbot :

sudo certbot --nginx -d domain.com -d www.domain.com

    Saving debug log to '/var/log/letsencrypt/letsencrypt.log'
    Enter email address (used for urgent renewal and security notices)
     (Enter 'c' to cancel): your_email@domain.com

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Please read the Terms of Service at
    https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
    agree in order to register with the ACME server. Do you agree?
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    (Y)es/(N)o: y

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Would you be willing, once your first certificate is successfully issued, to
    share your email address with the Electronic Frontier Foundation, a founding
    partner of the Lets Encrypt project and the non-profit organization that
    develops Certbot? We would like to send you email about our work encrypting the web,
    EFF news, campaigns, and ways to support digital freedom.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    (Y)es/(N)o: y
    Account registered.
    Requesting a certificate for 'domain.com' and 'www.domain.com'

    Successfully received certificate.
    Certificate is saved at: '/etc/letsencrypt/live/domain.com/fullchain.pem'
    Key is saved at:         '/etc/letsencrypt/live/domain.com/privkey.pem'
    This certificate expires on 2023-07-01.
    These files will be updated when the certificate renews.
    Certbot has set up a scheduled task to automatically renew this certificate in the background.

    Deploying certificate
    Successfully deployed certificate for 'domain.com to' '/etc/nginx/sites-enabled/default'
    Successfully deployed certificate for 'www.domain.com' to '/etc/nginx/sites-enabled/default'
    Congratulations! You have successfully enabled HTTPS on 'https://domain.com' and 'https://www.domain.com'

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you like Certbot, please consider supporting our work by:
     * Donating to ISRG / Lets Encrypt:   https://letsencrypt.org/donate
     * Donating to EFF:                    https://eff.org/donate-le
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Une règle a été créée auprès de votre serveur web pour rediriger le client du protocole HTTP au HTTPS. Une tâche pour renouveller le certificat a quant à elle été initialisée et sera renouvellée chaque 90 jours.

Vérifiez que celle-ci soit créée via sudo systemctl status certbot.timer

    ● certbot.timer - Run certbot twice daily
    Loaded: loaded ('/lib/systemd/system/certbot.timer'; enabled; vendor preset:>
    Active: active (waiting) since Sun 2023-04-02 10:50:45 UTC; 4min 58s ago
    Trigger: Sun 2023-04-02 15:19:19 UTC; 4h 23min left
    Triggers: ● certbot.service

    Apr 02 10:50:45 vps systemd[1]: Started Run certbot twice daily.

Un email de Let's Encrypt devrait vous parvenir avant l'expiration de votre certificat.

Utilisez sudo certbot renew --dry-run à l'avenir pour renouveller votre certificat.

ℹ️ Vous pourrez remarquer que le fichier de configuration Nginx lié au nom de domaine que vous avez certifié à été modifié par Certbot. Notre fichier /etc/nginx/sites-available/default ou /etc/nginx/sites-available/domain.com a hérité de nouvelles propriétés pour permettre l'utilisation du protocole HTTPS.

Félicitations 🎉

Vous pouvez dorénavant profiter de votre application depuis le protocole HTTPS.

👤 Implémenter un système d'authentification via LinkedIn avec React & NestJS

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:05:38 +0000

L'implémentation d'un système d'authentification via LinkedIn peut présenter de nombreux avantages pour votre plateforme.

Dans un premier temps, il permet de vous prémunir contre les bots & les logiciels automatisés 🤖. En effet, la création d'un compte LinkedIn requiert le renseignement d'un numéro de téléphone. On peut dès lors considérer qu'un utilisateur authentifié via LinkedIn auprès de votre plateforme est une personne réelle 🙍‍♂️.

Mais l'authentification via LinkedIn permet surtout l'obtention de données ayant trait à l'identité réelle de l'utilisateur se connectant à votre plateforme. Il s'agit donc d'une solution pertinente pour obtenir le profil professionnel d'un internaute.

Je vous propose, dans cet article, de découvrir comment implémenter une solution d'authentification via LinkedIn en créant : une application React ainsi qu'une API NestJS.

Source Github 👇
https://github.com/MessageGit/oauth-sign-in-with-linkedin.

⚠️ Pré-requis

Pour implémenter un système d'authentification via LinkedIn, vous devez tout d'abord :

Être détenteur d'un compte utilisateur LinkedIn valide (Si vous n'avez pas de compte LinkedIn, créez-en un en cliquant ici).

Être propriétaire d'une page professionnelle LinkedIn (à l'effigie de votre plateforme) (Si vous n'avez pas de page professionnelle, créez-en une en cliquant ici).

Créer une application LinkedIn (nécessite de satisfaire les deux pré-requis précédents). Pour cela, rendez-vous sur la page de création d'une nouvelle application puis complétez le formulaire en renseignant les informations suivantes : nom de l'application, URL de votre page professionnelle, upload d'un logo, acceptation des CGU.

[...] Votre nouvelle application, une fois créée, devrait apparaître dans le tabeau de bord « développeurs » de votre compte LinkedIn, cliquez-ici pour y accéder.

Il ne vous reste plus qu'à cliquer sur votre nouvelle application pour accéder à son panel de gestion 🎉
(Voir exemple ci-dessous)

⚙️ Configuration préalable via LinkedIn Developers

Le fonctionnement de la connexion OAuth 2 via LinkedIn ne diffère pas grandement des autres services qui l'intègrent (comme par exemple la connexion via Google/Facebook).

Un système de « scopes » est présent et permet à l'utilisateur de réguler l'accord des permissions léguées à l'application, point positif en faveur de l'aspect sécuritaire de la plateforme.

ℹ️ Si la présence de « scopes » semble être standard, rappelons tout de même que certain(e)s réseaux sociaux/applications n'intègrent pas ce système précautionneux voué à limiter l'exploitation des ressources par une application tierce. C'est le cas de la messagerie sécurisée Telegram notamment.

Par défaut, votre application (fraîchement créée dans le chapitre précédent) n'intègre pas la connexion via LinkedIn, il faudra l'activer manuellement en vous rendant dans la rubrique « Products » de votre application (toujours dans le panel de gestion de votre application LinkedIn developers).

Cliquez ensuite sur le bouton « Request access » lié au produit nommé « Sign In with LinkedIn ».

Une fois le produit activé, deux nouveaux scopes feront leur apparition dans la section « OAuth 2.0 scopes » de la rubrique « Auth » : r_emailaddress ainsi que r_liteprofile.

C'est dans cette même rubrique que vont se manifester de nombreuses informations essentielles à l'implémentation de la solution d'authentification via LinkedIn.

La section « Application credentials » va répertorier le Client ID & le Client Secret, deux informations primordiales permettant d'identifier votre application lorsque vos futurs utilisateurs accéderont au portail d'authentification via LinkedIn.

La section « OAuth 2.0 settings » quant à elle va permettre d'autoriser des URLs de redirection pour votre application. Une fois l'authentification de vos utilisateurs validée, LinkedIn les redirigera vers l'URL demandée (sous réserve que cette dernière soit autorisée dans cette même section).

Une fois la configuration de l'application via le panel LinkedIn developers terminée, il est temps de passer à l'implémentation technique du système d'authentification !

📸 Développement de la web application React

Avant de débuter l'initialisation de notre application React, il me semble judicieux de résumer les opérations à entreprendre via l'application front pour procéder à l'authentification d'un utilisateur LinkedIn.

👤 Aspect procédural de l'authentification client

1ère étape de l'authentification 👇

Rediriger le client vers le portail d'authentification LinkedIn en y apportant des informations telles que : l'URI de redirection souhaité (dans l'éventualité où l'authentification de notre client est un succès), les scopes requis par notre application, l'identifiant même de notre application, etc..

2ème étape de l'authentification 👇

Partons du principe que notre client soit parvenu à se connecter à LinkedIn : ce dernier est dès lors redirigé à l'URI que nous avons fournit à LinkedIn lorsque nous l'avons renvoyé vers le portail d'authentification. Sa redirection vers notre URI personnalisée est accompagnée d'un query params « code », il s'agit là d'un « authorization code » que nous enverrons à notre API pour obtenir un droit d'exploitation des ressources de notre client (sous réserve que l'exploitation soit faite par notre API exclusivement).

[...] Nous verrons dans le chapitre suivant comment échanger le code d'autorisation, résultant de la connexion de notre client à LinkedIn puis comment obtenir l'autorisation d'exploitation des ressources LinkedIn de notre client.

🌐 Initialisation de la web application React

Maintenant que nous avons étudié l'aspect procédural de l'authentification côté client, tâchons de l'implémenter via une application React.

Commençons par initialiser une nouvelle application React en saisissant la commande suivante dans un terminal : npx create-react-app linkedin-oauth-app.

Nous idéaliserons une architecture/arborescence d'application très minimaliste et assez peu élaborée telle que la suivante :

    > linkedin-oauth-app
        > node_modules
        > public
        > src
            > api
            > assets
            App.tsx
            index.css
            index.js
        .env
        .env.example
        .gitignore
        package.json
        README.md
        tsconfig.json

🗒️ Déclaration des variables d'environnement

Déclarons sans plus attendre les variables d'environnement indispensables au fonctionnement de notre système d'authentification, et plus globalement, au fonctionnement de notre application :

    # MAIN
    REACT_APP_API_URL=

    # LINKEDIN
    REACT_APP_LINKEDIN_CLIENT_ID=
    REACT_APP_LINKEDIN_SCOPES=
    REACT_APP_LINKEDIN_REDIRECT_URI=

[...] Notre fichier .env (registre des variables d'environnement) sera identique au fichier .env.example (ci-dessus), à la seule différence que celui-ci intégrera des valeurs.

🤔 Pourquoi un fichier .env et .env.example ?

ℹ️ Le principe de cette mesure sécuritaire est simple. Pour celles & ceux qui n'en ont pas connaissance : le fichier .env, référencé dans notre fichier .gitignore, peut inclure une infinité d'informations sensibles selon la complexité de l'application, il n'a donc pas vocation à intégrer notre répertoire Github.
Notre fichier .env.example est, quant à lui, le modèle des variables d'environnement. Il sera respectivement publié sur notre répertoire Github à titre d'exemple et n'intégrera donc aucune valeur.

Vous pouvez d'ores et déjà incrémenter la clé REACT_APP_LINKEDIN_SCOPES par la valeur suivante : r_liteprofile,r_emailaddress. Cette dernière correspond à la solution « Sign-In with LinkedIn ».

Vous retrouverez la valeur de la clé REACT_APP_LINKEDIN_CLIENT_ID et REACT_APP_LINKEDIN_REDIRECT_URI dans le panel LinkedIn Developers de votre application, rubrique « Auth ».

La clé REACT_APP_API_URL correspondra quant à elle à l'URL de votre API, mais nous ne l'avons pas encore créée, nous y reviendrons donc ultérieurement 😜

Dans notre fichier App.tsx, nous importerons les variables d'environnement correspondantes à LinkedIn sous forme d'object Javascript :

import React from 'react';

const App = () => {
    /* Load LinkedIn credentials from dotenv */
    const LINKEDIN_ENV = {
        CLIENT_ID: process.env['REACT_APP_LINKEDIN_CLIENT_ID'],
        SCOPES: process.env['REACT_APP_LINKEDIN_SCOPES'],
        REDIRECT_URI: process.env['REACT_APP_LINKEDIN_REDIRECT_URI'],
    }

    // (...)
}

📤 Implémentation technique et redirection client

A titre d'exemple, un simple bouton « Se connecter via LinkedIn » permettant la redirection du client au portail d'authentification LinkedIn fera l'affaire. Inutile de configurer plusieurs pages ou d'aborder un développement plus complexe, l'enjeu de cet exemple étant de saisir le fonctionnement de l'authentification.

Choisissez un jolie logo LinkedIn, il intégrera notre bouton personnalisé « Se connecter via LinkedIn » et nous permettra de rediriger notre client à l'adresse suivante :

https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=${LINKEDIN_ENV.CLIENT_ID}&scope=${LINKEDIN_ENV.SCOPES}&redirect_uri=${LINKEDIN_ENV.REDIRECT_URI}

Décomposons cette adresse pour l'analyser & la comprendre :

https://www.linkedin.com/oauth/v2/authorization correspond à l'URL du portail d'authentification.

?response_type=code précise que nous attendons un code d'authorization.

&client_id=${LINKEDIN_ENV.CLIENT_ID} permet d'identifier notre application auprès des serveurs LinkedIn.

&scope=${LINKEDIN_ENV.SCOPES} permet de spécifier les scopes requis par notre application.

&redirect_uri=${LINKEDIN_ENV.REDIRECT_URI} permet de préciser l'URI à laquelle LinkedIn doit rediriger le client connecté.

import React from 'react';

import LinkedInIcon from './assets/linkedin_icon.png';

const App = () => {

  /* Load LinkedIn credentials from dotenv */
  const LINKEDIN_ENV = {
    CLIENT_ID: process.env['REACT_APP_LINKEDIN_CLIENT_ID'],
    SCOPES: process.env['REACT_APP_LINKEDIN_SCOPES'],
    REDIRECT_URI: process.env['REACT_APP_LINKEDIN_REDIRECT_URI'],
  }

  /* Handle the client redirection to LinkedIn authentication portal */
  const onSignInLinkedIn = () => {
    window.location.replace(`https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=${LINKEDIN_ENV.CLIENT_ID}&scope=${LINKEDIN_ENV.SCOPES}&redirect_uri=${LINKEDIN_ENV.REDIRECT_URI}`);
  }

  return (
    <div className="App">

        <button className="LinkedIn_Button" onClick={onSignInLinkedIn}>
          <img src={LinkedInIcon} alt="Logo LinkedIn" className="LinkedIn_Icon" />
          <span>Se connecter via LinkedIn</span>
        </button>

    </div>
  );
}

export default App;

A ce stade, le bouton « Se connecter via LinkedIn » nous redirige vers le portail d'authentification LinkedIn :

Si une erreur survient, vérifiez que les variables d'environnement saisies correspondent bien aux credentials fournis pour votre application, que le produit « Sign-In with LinkedIn » soit bien activé, que les scopes spécifiés soient valides & que l'URI de redirection transmise via l'URI du portail d'authentification soit autorisée via le panel de gestion de votre application depuis LinkedIn developers.

ℹ️ N'oubliez pas de re-démarrer votre application React une fois les variables d'environnement modifiées. Celles-ci ne se synchronisent pas automatiquement lors de leur modification.

Si la configuration de votre application est correcte & que le formulaire d'authentification s'affiche sans problèmes, essayez alors de vous connecter :

L'application requiert dès lors, comme prévu, les scopes préalablement configurés tels que :

Les informations basiques du profil utilisateur (= Utiliser votre nom et photo)
L'adresse e-mail de l'utilisateur (= Utiliser l'adresse e-mail principale associée à votre compte LinkedIn)

[...] Il ne vous reste plus qu'à autoriser l'exploitation de ces scopes par l'application pour être redirigé à l'URI transmise au préalable, accompagné d'un « authorization code » qui se présente sous forme de query params, tel que :

?code=AQVumAQMn0w5BWznTRD0nnMRDA_fBYNzBBHe3yxmOxMQvm9nW0yw8b7QrUNffvuEkSYlYOXU26FGL7vvm7W0-oe8pqyDFXj5w6JxW3A0bhCLPIXQsYMZfP_9QwRrJDPDdjZIYhPILu0xfGEWaM44Isy6FxYTtzMLf1HxkXdqGUVoJjR_TGPEpC-c3Dcj-oqJue6I7NgsurIZltYFuQw

ℹ️ Notez qu'en procédant à cette authentification, vous léguez des permissions d'exploitation des ressources liées à votre profil LinkedIn, à une application tierce. Pour révoquer ces permissions, vous pouvez vous rendre dans les préférences de votre profil LinkedIn puis dans : Confidentialité des données > Autres applications > Services autorisés > Nom de l'application > Supprimer.

📥 Récupération du code d'autorisation et transmission à l'API

Actuellement, nous avons un bouton permettant de rediriger le client vers le portail d'authentification LinkedIn. Si la connexion d'un utilisateur est valide, il est redirigée vers notre application React, avec un code d'autorisation.

L'enjeu est maintenant de récupérer ce code d'autorisation pour le transmettre à notre API.

Toujours dans notre fichier App.tsx, tâchons sans plus tarder de le récupérer :

    /* Check if a Linkedin authorization code is provided */
    const authorizationCode = new URLSearchParams(window.location.search).get('code');

La constante authorizationCode intègre désormais le code d'autorisation retourné par LinkedIn.

A défaut, cette dernière sera respectivement undefined. Il ne nous reste plus qu'à traiter ce code dès lorsque notre App.tsx est initialisé, dans l'hypothèse que ce dernier ne soit pas undefined. Nous utiliserons le hook React useEffect pour se faire :

import React, {useEffect} from 'react';

import LinkedInIcon from './assets/linkedin_icon.png';

const App = () => {

    /* Load LinkedIn credentials from dotenv */
    const LINKEDIN_ENV = {
        CLIENT_ID: process.env['REACT_APP_LINKEDIN_CLIENT_ID'],
        SCOPES: process.env['REACT_APP_LINKEDIN_SCOPES'],
        REDIRECT_URI: process.env['REACT_APP_LINKEDIN_REDIRECT_URI'],
    }

    /* Handle the client redirection to LinkedIn authentication portal */
    const onSignInLinkedIn = () => {
        window.location.replace(`https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=${LINKEDIN_ENV.CLIENT_ID}&scope=${LINKEDIN_ENV.SCOPES}&redirect_uri=${LINKEDIN_ENV.REDIRECT_URI}`);
    }

    /* Check if a Linkedin authorization code is provided */
    const authorizationCode = new URLSearchParams(window.location.search).get('code');

    useEffect(() => {
        if (authorizationCode) {
          // TODO: Send authorization code to server here
        }
    }, [authorizationCode]);

    return (
        <div className="App">

            <button className="LinkedIn_Button" onClick={onSignInLinkedIn}>
              <img src={LinkedInIcon} alt="Logo LinkedIn" className="LinkedIn_Icon" />
              <span>Se connecter via LinkedIn</span>
            </button>

        </div>
    );

}

export default App;

Dans notre hook useEffect, le code d'autorisation peut enfin être exploité (sous réserve qu'il soit définit).

Installons à présent la librairie axios, librairie très réputée permettant d'émettre des requêtes. Nous pourrions également utiliser n'importe quelle autre librairie de ce type, voir utiliser simplement l'API fetch intégrée nativement dans Javascript et permettant de d'exploiter des requêtes AJAX.

Une fois la librairie installée, nous créerons une instance axios qui se basera sur la variable d'environnement REACT_APP_API_URL préalablement déclarée :

    import axios from 'axios';

    const baseURL = process.env['REACT_APP_API_URL'];
    export default axios.create({ baseURL, withCredentials: true });

Une fois que notre API sera créée et exposée, nous n'aurons qu'à incrémenter notre variable d'environnement REACT_APP_API_URL par l'URL de notre API et utiliser l'instance déclarée ci-dessus pour échanger avec cette dernière.

Revenons dans notre fichier App.tsx, importons notre instance axios puis requêtons le futur end-point de notre API auquel nous enverrons le code d'autorisation reçu :

import React, {useEffect} from 'react';
import API from './api/api'; // import of our axios instance

import LinkedInIcon from './assets/linkedin_icon.png';

const App = () => {

    /* Load LinkedIn credentials from dotenv */
    const LINKEDIN_ENV = {
        CLIENT_ID: process.env['REACT_APP_LINKEDIN_CLIENT_ID'],
        SCOPES: process.env['REACT_APP_LINKEDIN_SCOPES'],
        REDIRECT_URI: process.env['REACT_APP_LINKEDIN_REDIRECT_URI'],
    }

    /* Handle the client redirection to LinkedIn authentication portal */
    const onSignInLinkedIn = () => {
        window.location.replace(`https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=${LINKEDIN_ENV.CLIENT_ID}&scope=${LINKEDIN_ENV.SCOPES}&redirect_uri=${LINKEDIN_ENV.REDIRECT_URI}`);
    }

    /* Check if a Linkedin authorization code is provided */
    const authorizationCode = new URLSearchParams(window.location.search).get('code');

    useEffect(() => {
        if (authorizationCode) {
            API.post('linkedin/auth/login', { authorization_code: authorizationCode })
                .then((res) => console.log('Request received', res))
                .catch((err) => console.log('An error occured', err));
        }
    }, [authorizationCode]);

    return (
        <div className="App">

            <button className="LinkedIn_Button" onClick={onSignInLinkedIn}>
              <img src={LinkedInIcon} alt="Logo LinkedIn" className="LinkedIn_Icon" />
              <span>Se connecter via LinkedIn</span>
            </button>

        </div>
    );

}

export default App;

Dans l'implémentation de notre requête ci-dessus, nous spéculons à la fois sur :

l'end-point cible de notre API (nous avons choisi linkedin/auth/login)
la dénomination de la clé passée dans le body de notre requête (nous avons choisi authorization_code)

📌 Récapitulons :

Si l'on part du principe que l'URL de notre futur API est http://localhost:8080/ et que la variable d'environnement REACT_APP_API_URL est respectivement incrémentée par cette valeur/url, notre application React émettra ici une requête POST à l'adresse http://localhost:8080/linkedin/auth/login avec une clé authorization_code en body incluant la valeur du code d'autorisation retourné par LinkedIn pour notre utilisateur.

🏗️ Développement de l'API avec NestJS

Maintenant que notre application web est fonctionnelle et capable de transmettre le code d'autorisation client à l'API, conçevoir l'API il va falloir pour exploiter les données de l'utilisateur LinkedIn en toute sécurité.

Nous utiliserons NestJS, un framework Typescript basé sur Node.js mais vous pouvez évidement choisir un framework ou une technologie plus à votre aise selon vos habitudes.

Ci-dessous, nous verrons comment entreprendre l'implémentation via NestJS.

🧰 Initialisation du serveur & configuration préalable

Une fois NestJS installé, initialisez un nouveau projet via la commande : nest new linkedin-oauth-api.

Encore une fois, nous privilégierons une arborescence de projet simpliste/minimaliste et une architecture en microservices, NestJS étant idéal pour ce type d'architecture.

    > linkedin-oauth-api
        > dist
        > node_modules
        > src
            > config
            > microservices
            app.module.ts
            main.ts
        .env
        .env.example
        .eslintrc.js
        .gitignore
        .prettierrc
        nest-cli.json
        package.json
        tsconfig.build.json
        tsconfig.json

Au même titre que notre application web, configurons les fichiers relatifs aux variables d'environnement .env et .env.example :

    PORT=8080
    NODE_ENV=development

    LINKEDIN_API_CLIENT_ID=
    LINKEDIN_API_CLIENT_SECRET=
    LINKEDIN_API_REDIRECT_URI=

Il ne tient plus qu'à vous de le compléter selon les credentials fournis pour votre application LinekdIn.

ℹ️ Rappel : retrouvez les credentials liées à votre application via le panel LinkedIn developers, au sein de la rubrique « Auth ».

Pour lire les variables d'environnement avec NestJS, nous aurons besoin d'installer une librairie conçue par les soins des développeurs du framework, à savoir : @nestjs/config, utilisez donc npm i --save @nestjs/config si ce n'est pas déjà fait.

Initialisez ensuite le fichier root > src > config > config.ts en y ajoutant le code suivant :

interface LinkedInConfig {
    clientId: string;
    clientSecret: string;
    redirectUri: string;
}

interface ConfigProps {
    port: number;
    linkedIn: LinkedInConfig;
}

export const config = (): ConfigProps => ({
    port: parseInt(process.env.PORT, 10) || 8080,
    linkedIn: {
        clientId: process.env.LINKEDIN_API_CLIENT_ID,
        clientSecret: process.env.LINKEDIN_API_CLIENT_SECRET,
        redirectUri: process.env.LINKEDIN_API_REDIRECT_URI,
    }
});

Même si nous avons ajouté la clé NODE_ENV par convention, aux fichiers relatifs aux variables d'environnement, nous n'en ferons pas grand chose dans ce tutoriel.

Une fois le fichier de config configuré et les types ajoutés, il faudra dorénavant l'importer dans le fichier app.module.ts comme suit :

import { Module } from '@nestjs/common';

/* NestJS Config */
import { ConfigModule } from '@nestjs/config'; // import of our @nestjs/config lib.
import { config } from './config/config';

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      load: [config]
    }),
  ],
  controllers: [],
  providers: [],
})
export class AppModule {}

[...] Le plus haut fichier de votre projet main.ts devra intégrer le code suivant :

import { NestFactory } from '@nestjs/core';
import { Logger } from '@nestjs/common';
import { AppModule } from './app.module';
import { ConfigService } from '@nestjs/config'; // import of our @nestjs/config lib.

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.enableCors({
    origin: true,
    methods: 'GET,HEAD,PUT,PATCH,POST,DELETE,OPTIONS',
    credentials: true,
  });

  const configService = app.get(ConfigService);
  const port = configService.get<number>('port'); // get port from dotenv file

  await app.listen(port, '0.0.0.0');
  console.log(`\n\n\x1b[34m🚀 Server is now available at the \x1b[37m${await app.getUrl()}\x1b[34m address!\x1b[0m`);
}

bootstrap();

🎉 Notre API peut maintenant être démarrée en mode développement via la commande : npm run start:dev.

⚙️ Initialisation de notre nouveau microservice

Maintenant que notre API est exposée via http://localhost:8080/, il nous faut créer la route permettant l'échange du code d'autorisation reçu par notre web-application contre un jeton d'accès permettant l'exploitation des ressources utilisateurs. Créons alors le microservice linkedin.

    > microservices
        > linkedin
            > api
                linkedin.api.ts // next chapter
            > controllers
                linkedin.controller.ts
            > objects
                linkedin-user-profile.object.ts // next chapter
                linkedin-user-token.object.ts // next chapter
            > services
                linkedin.service.ts
            linkedin.module.ts

1️⃣ Déclaration du service linkedin

Le fichier src > microservices > linkedin > services > linkedin.service.ts nous permettra d'implémenter l'intégralité des méthodes liées à LinkedIn.

import { Injectable } from '@nestjs/common';

@Injectable()
export class LinkedInService {
    constructor() {}

    async login(authorizationCode: string): Promise<any> {
        console.log('> Authorization code received :', authorizationCode);
        // ...
    }
}

2️⃣ Déclaration du controlleur linkedin

Le fichier src > microservices > linkedin > controllers > linkedin.controller.ts permettra de définir la route d'accès, gérer la réception des données fournis dans le corps de la requête et s'assurera de transmettre les informations aux méthodes de notre service préalablement déclaré.

import { Body, Controller, Post } from '@nestjs/common';

import { LinkedInService } from 'src/microservices/linkedin/services/linkedin.service';

@Controller('linkedin')
export class LinkedInController {
  constructor(private readonly linkedInService: LinkedInService) {}

  @Post('auth/login')
  async login(@Body('authorization_code') authorizationCode: string): Promise<any> {
      return await this.linkedInService.login(authorizationCode);
  }

}

3️⃣ Déclaration du module linkedin

Le fichier src > microservices > linkedin > linkedin.module.ts fera office de porte d'accès à notre controlleur puis à notre service, il assurera l'import global des fichiers préalablement déclarés et permettra d'y greffer des modules / services complémentaires, il est une base rattaché au corps de notre serveur.

import { Module } from '@nestjs/common';

import { LinkedInController } from 'src/microservices/linkedin/controllers/linkedin.controller';
import { LinkedInService } from 'src/microservices/linkedin/services/linkedin.service';

@Module({
  imports: [],
  controllers: [LinkedInController],
  providers: [LinkedInService],
})
export class LinkedInModule {}

4️⃣ Import de notre module auprès du module global

Notre fichier app.module.ts est l'un des fichiers des plus haut-niveau dans l'architecture de notre application, il est en tout cas le module parent à notre serveur. C'est auprès de ce dernier qu'il nous faudra s'assurer de l'import de notre nouveau module linkedin.

import { Module } from '@nestjs/common';

/* NestJS Config */
import { ConfigModule } from '@nestjs/config';
import { config } from './config/config';

/* Imported modules */
import { LinkedInModule } from './microservices/linkedin/linkedin.module'; // import of LinkedIn module

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      load: [config]
    }),
    LinkedInModule, // import of LinkedIn module
  ],
  controllers: [],
  providers: [],
})
export class AppModule {}

A ce stade, la connexion LinkedIn via notre web-application React doit être capable de provoquer l'impression du code d'autorisation via notre serveur 🎉

🔐 Obtention d'un jeton d'accès depuis un code d'autorisation

Maintenant que nous reçevons le code d'autorisation au sein de la méthode login(...) de notre service LinkedIn, tâchons de l'échanger à LinkedIn contre un jeton d'accès.

Pour commencer, nous créerons le SDK LinkedIn. Celui-ci nous permettra de faire appel à des méthodes qui, quant à elles, se chargeront de formuler les requêtes adéquates auprès des serveurs de LinkedIn. Il s'agit ni plus ni moins que de déclarer une instance axios (comme nous l'avons fait avec React) et de déclarer des méthodes invoquant cette instance, en ciblant des routes spécifiques.

import { ConfigService } from "@nestjs/config";
import axios from "axios";

const linkedInAuthentication = () => {
    const axiosInstance = axios.create({
        baseURL: 'https://www.linkedin.com/oauth/v2',
        withCredentials: true,
    });
    return axiosInstance;
}
export const loginLinkedIn = async (code: string) => /* Get accessToken from an authorization code */
    await linkedInAuthentication().get('/accessToken', {
        params: {
            grant_type: 'authorization_code',
            client_id: new ConfigService().get('LINKEDIN_API_CLIENT_ID'),
            client_secret: new ConfigService().get('LINKEDIN_API_CLIENT_SECRET'),
            code,
            redirect_uri: new ConfigService().get('LINKEDIN_API_REDIRECT_URI'),
        },
    });
export const checkSessionValidity = async (accessToken: string) => {/* Introspect and verify an accessToken */
    const body = {
        client_id: new ConfigService().get('LINKEDIN_API_CLIENT_ID'),
        client_secret: new ConfigService().get('LINKEDIN_API_CLIENT_SECRET'),
        token: accessToken,
    };
    return await linkedInAuthentication().post('/introspectToken', new URLSearchParams(body), {
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    });
}

La méthode checkSessionValidity ci-dessus est d'une importance toute particulière.

En effet, nombreu.x.ses sont les développeu.r.ses à vérifier l'état de validité d'un jeton d'accès en essayant d'obtenir des ressources utilisateurs. Le problème de ce procédé est le suivant : l'obtention de ressources liées à un utilisateur augmente le quota d'exploitation de votre application pour une route spécifique.

Si à priori, en phase de test et/ou lors d'une utilisation de votre application à faible traffic, aucun problème ne survient, l'application montrera vite des signes de faiblesse et rendra des fonctionnalités obsolètes lors de son évolution.

La route cible de la méthode checkSessionValidity n'a, quant à elle, aucun impact sur le quota d'utilisation des services par votre application. Elle peut être sollicitée par un guard, decorator mais encore un middleware pour attester ou non de la validité d'un jeton d'accès utilisateur.

ℹ️ Les plateformes comme LinkedIn, Facebook, Google etc.. se prémunissent de la surexploitation de leurs serveurs en instaurant ces limitations à quota réinitialisable.

[...] Après avoir installé la librairie class-validator en utilisant npm i --save class-validator, il nous faudra créer l'objet LinkedInUserTokenObject, cet object incluera le jeton d'accès utilisateur ainsi que sa date d'expiration.

import { IsNumber, IsString } from "class-validator";

export class LinkedInUserTokenObject {
    @IsString()
    accessToken: string;

    @IsNumber()
    expireIn: number;
}

Revenons maintenant à la méthode login(...) de notre service linkedin.service.ts :

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { loginLinkedIn } from 'src/microservices/linkedin/api/linkedin.api';

import { LinkedInUserTokenObject } from '../objects/linkedin-user-token.object';

@Injectable()
export class LinkedInService {
    constructor() {}

    async login(authorizationCode: string): Promise<LinkedInUserTokenObject> {
        try {
            const response = await loginLinkedIn(authorizationCode);
            const { access_token: accessToken, expires_in: expireIn } = response.data;
            return { accessToken, expireIn }
        } catch (err) {
            throw new UnauthorizedException('Unable to login as LinkedIn user from the provided authorization code!');
        }
    }

}

Puis à notre controlleur linkedin.controller.ts :

import { Body, Controller, Post } from '@nestjs/common';

import { LinkedInService } from 'src/microservices/linkedin/services/linkedin.service';
import { LinkedInUserTokenObject } from '../objects/linkedin-user-token.object';

@Controller('linkedin')
export class LinkedInController {
    constructor(private readonly linkedInService: LinkedInService) {}

    @Post('auth/login')
    async login(@Body('authorization_code') authorizationCode: string): Promise<LinkedInUserTokenObject> {
        const token: LinkedInUserTokenObject = 
            await this.linkedInService.login(authorizationCode); // Get permissions from LinkedIn server(s)
        return token;
    }

}

Si nous inspectons à présent l'onglet "Réseau/Network" de notre navigateur, une fois la redirection depuis le portail d'authentification LinkedIn effectuée, on peut remarquer que la requête émise avec le code d'autorisation reçoit bel & bien une réponse incluant les propriétés de l'utilisateur : accessToken et expireIn.

Evidemment, nous retournons ces informations uniquement pour analyser le résultat et savoir notre code fonctionnel.

Nous allons maintenant voir comment obtenir les informations d'un utilisateur depuis ce précieux accessToken que nous obtenons.

📥 Exploitation des ressources liées à un utilisateur LinkedIn

Pour exploiter les ressources auxquelles notre application est autorisée à accéder, une mise à jour de notre SDK LinkedIn s'impose, nous ajouterons dans notre fichier src > microservices > linkedin > api > linkedin.api.ts, x2 nouvelles routes permettant de récupérer :

l'adresse e-mail de l'utilisateur
le nom/prénom & image de profil de l'utilisateur

import { ConfigService } from "@nestjs/config";
import axios from "axios";

/* (1) LinkedIn API | global endpoint */
const linkedInAPI = () => {
    const axiosInstance = axios.create({
        baseURL: 'https://api.linkedin.com/v2',
        withCredentials: true,
    });
    return axiosInstance;
}
/* [LinkedIn] Get email address */
export const getLinkedInEmailAddress = async (accessToken: string) => 
    linkedInAPI().get(`/emailAddress?q=members&projection=(elements*(handle~))`, {headers: { Authorization: `Bearer ${accessToken}` }});
/* [LinkedIn] Get (first/last)name and profile picture */
export const getLinkedInProfile = async (accessToken: string) => 
    linkedInAPI().get(`/me?projection=(id,firstName,lastName,emailAddress,profilePicture(displayImage~:playableStreams))`, {headers: { Authorization: `Bearer ${accessToken}` }});


/* (2) Authentication */
const linkedInAuthentication = () => {
    const axiosInstance = axios.create({
        baseURL: 'https://www.linkedin.com/oauth/v2',
        withCredentials: true,
    });
    return axiosInstance;
}
export const loginLinkedIn = async (code: string) => /* Get accessToken from an authorization code */
    await linkedInAuthentication().get('/accessToken', {
        params: {
            grant_type: 'authorization_code',
            client_id: new ConfigService().get('LINKEDIN_API_CLIENT_ID'),
            client_secret: new ConfigService().get('LINKEDIN_API_CLIENT_SECRET'),
            code,
            redirect_uri: new ConfigService().get('LINKEDIN_API_REDIRECT_URI'),
        },
    });
export const checkSessionValidity = async (accessToken: string) => {/* Introspect and verify an accessToken */
    const body = {
        client_id: new ConfigService().get('LINKEDIN_API_CLIENT_ID'),
        client_secret: new ConfigService().get('LINKEDIN_API_CLIENT_SECRET'),
        token: accessToken,
    };
    return await linkedInAuthentication().post('/introspectToken', new URLSearchParams(body), {
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    });
}

Le type de l'object LinkedInUserProfileObject ayant pour vocation de répertorier les informations de notre utilisateur doit être créé :

import { IsNumber, IsString } from "class-validator";

export class LinkedInUserProfileObject {
    @IsString()
    firstName: string;

    @IsString()
    lastName: string;

    @IsString()
    email: string;

    @IsString()
    profileImageUrl: string;
}

Une nouvelle méthode permettant de récupérer le profil utilisateur depuis l'accessToken obtenu doit ensuite être implémentée dans notre fichier linkedin.service.ts :

import { Injectable, InternalServerErrorException, UnauthorizedException } from '@nestjs/common';
import { getLinkedInEmailAddress, getLinkedInProfile, loginLinkedIn } from 'src/microservices/linkedin/api/linkedin.api';

import { LinkedInUserTokenObject } from '../objects/linkedin-user-token.object';
import { LinkedInUserProfileObject } from '../objects/linkedin-user-profile.object';

@Injectable()
export class LinkedInService {
    constructor() {}

    async login(authorizationCode: string): Promise<LinkedInUserTokenObject> {
        try {
            const response = await loginLinkedIn(authorizationCode);
            const { access_token: accessToken, expires_in: expireIn } = response.data;
            return { accessToken, expireIn }
        } catch (err) {
            throw new UnauthorizedException('Unable to login as LinkedIn user from the provided authorization code!');
        }
    }

    async getProfile(accessToken: string): Promise<LinkedInUserProfileObject> {
        /* (1) Get email of LinkedIn client */
        const req1 = await getLinkedInEmailAddress(accessToken);
        const email = req1?.data?.elements[0]['handle~'].emailAddress;

        /* (2) Get (first/last)name and profile image of LinkedIn client */
        const req2 = await getLinkedInProfile(accessToken);
        const firstName = req2?.data?.firstName?.localized?.fr_FR;
        const lastName = req2?.data?.lastName?.localized?.fr_FR;
        const profileImageUrl = req2?.data?.profilePicture['displayImage~']?.elements[0]?.identifiers[0]?.identifier;

        if (!firstName || !lastName || !profileImageUrl || !email) throw new InternalServerErrorException('An error occured while parsing the retrieved profile from LinkedIn!');
        return {
            firstName,
            lastName,
            email,
            profileImageUrl,
        }
    }
}

Il ne nous reste plus qu'à modifier notre fichier linkedin.controller.ts pour retourner les informations de l'utilisateur plutôt que de retourner le jeton d'accès client :

import { Body, Controller, Post } from '@nestjs/common';

import { LinkedInService } from 'src/microservices/linkedin/services/linkedin.service';
import { LinkedInUserTokenObject } from '../objects/linkedin-user-token.object';
import { LinkedInUserProfileObject } from '../objects/linkedin-user-profile.object';

@Controller('linkedin')
export class LinkedInController {
  constructor(private readonly linkedInService: LinkedInService) {}

  @Post('auth/login')
  async login(@Body('authorization_code') authorizationCode: string): Promise<any> {
    const token: LinkedInUserTokenObject = 
        await this.linkedInService.login(authorizationCode); // Get permissions from LinkedIn server(s)
    const profile: LinkedInUserProfileObject = 
        await this.linkedInService.getProfile(token.accessToken); // Get profile from LinkedIn server(s)
    return profile;
  }

}

Félicitations 🎉

Les informations de l'utilisateur ayant procédé à l'authentification LinkedIn sont dorénavant renvoyées au client.

Il ne tient plus qu'à vous d'utiliser ces informations selon vos ambitions, vous pourriez par exemple :

- Sauvegarder les informations liées à cet utilisateur en base de données dans le cadre d'une connexion/inscription via LinkedIn.
- Garder en cache ou retourner les informations de l'utilisateur et les sauvegarder en cache front-end (via cookies http-only ou local storage, etc..)
- etc..

🎁 Bonus

-> (Source) Retrouvez l'intégralité du code qui constitue ce tutoriel via ce répertoire Github.

⏰ Les fonctions Debounce et Throttle : comment ça fonctionne ?

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:05:28 +0000

Intégrées dans les applications web / mobiles & logiciels bureau, elles se cachent souvent derrière un champ de recherche pour habriter client/serveur d'une pluie de requêtes indésirables, voir même dans le défilement vertical d'une page pour épargner une infinité d'opérations inutiles à votre navigateur.

Les fonctions Debounce et Throttle régulent au quotidien les performances de nos applications, mais comment fonctionnent t-elles ? Quelle approche aborder en utilisant React ?

🔄 La fonction « Debounce »

La fonction « Debounce » permet de limiter le nombre d'exécution d'une fonction en l'exécutant une seule fois à terme d'un délai donné, sous réserve que la fonction ne soit pas réinvoquée, le cas échéant, le délai est alors renouvellé.

Elle consiste à réguler le nombre d'appels à une fonction en l'exécutant une seule fois, à terme d'une série d'évènements.

A quel moment est-ce nécessaire ?

Pour comprendre l'intérêt du debounce, nous utiliserons l'exemple d'une barre de recherche grâce à laquelle nous pourrions suggérer des résultats au fur et à mesure de notre saisie (sans avoir à utiliser de bouton de validation).

import React, {useState} from "react";

const Debounce = () => {
    const [searchValue, setSearchValue] = useState('');

    // Fetch articles with HTTP Request
    const fetchArticles = () => {
        console.log('fetchArticles() is called!');
    }

    /* Handle the value of search input */
    const handleSearchValue = (e) => {
        const newValue = e.target.value;
        setSearchValue(newValue);
        fetchArticles(); // Request to fetch articles
    }

    return (
        <div>
            <input 
                type="text" 
                name="searchValue" 
                value={searchValue}
                onChange={handleSearchValue} 
                placeholder="Votre recherche ici.."
            />
            <br />
            {searchValue && (
                <p>Voici les articles correspondant à:<br/><b>« {searchValue} »</b></p>
                /* ... Display articles ... */
            )}
        </div>
    );
}

export default Debounce;

La première idée à nous venir à l'esprit, et généralement la plus simple à mettre en oeuvre : se mettre à l'écoute d'un input de type texte et suggérer des articles chaque fois que le texte change.

ℹ️ Dans l'exemple ci-dessus, l'état searchValue a pour vocation d'être synchronisé avec le champ de recherche. Il sera actualisé selon la valeur de notre input grâce à la callback handleSearchValue.

Si le résultat escompté semble fonctionnel, il convient cependant d'admettre que le fetch permettant de récupérer nos articles via l'utilisation de la fonction fetchArticles(..) sera quant à lui effectué autant de fois que la valeur de notre champ de recherche sera modifiée.

La conséquence de cette maladresse : de nombreux problèmes de performance menaçant directement l'intégrité de votre application/serveur.

En effet, supposons qu'un internaute effectue la recherche suivante:

« Debounce et throttle, comment ça fonctionne ? »

La callback handleSearchValue et la fonction fetchArticles(..) sont alors invoquées 45 fois.

Si l'on suppose que la requête effectuée pour récupérer les articles auprès de notre serveur requiert 70.0kB, pas moins de 3,15Mo seront en réalité téléchargés à travers l'exécution de 45 requêtes.

Résultat de la recherche : 3,08Mo téléchargé inutilement.

C'est donc à l'occasion de l'exécution de notre fonction fetchArticles(..) que le debounce va être nécessaire et ainsi permettre une seule et unique exécution de notre requête, à terme de la saisie de l'utilisateur et non pas à chaque fois que la valeur de notre champ de recherche est modifiée.

Comment ça fonctionne ?

🟨 Approche globale en Javascript

La fonction Debounce nécessite généralement deux paramètres :

Une callback, nous utiliserons cb (qui sera retournée sous condition).
Un temps donné, nous utiliserons delay (en millisecondes).

const debounce = (cb, delay = 1000) => {
    let timer;
    return (...args) => {
        clearTimeout(timer); // Clear of timeout if exist
        timer = setTimeout(() => {
            cb(...args); // Return the callback
        }, delay);
    };
};

La fonction debounce(..) à pour rôle d'initialiser un timer selon delay et de le réinitialiser chaque fois que la fonction est appelée. Lorsque le timer arrive à échéance, il retourne la callback cb fournie en premier paramètre qui permet son exécution.

Ainsi, la callback cb ne sera exécutée qu'à terme du delai spécifié si aucun ré-appel de la fonction ne survient d'ici là.

Note : La fonction debounce est fournie dans de nombreuses librairies Javascript dont lodash, la plus connue.

⚙️ Hook React personnalisé useDebounce

La fonction debounce peut parfois hériter de paramètres complémentaires, ça peut être le cas notament lors de la création d'un hook personnalisé avec React. La dénomination de notre hook devient alors useDebounce, c'est la solution que je vous propose de passer en revue 👇

import React, { useRef, useEffect } from 'react';

export const useDebounce = (cb, delay, deps) => {
    const timeout = useRef();
    useEffect(() => {
        timeout.current = setTimeout(cb, delay);
        return () => clearTimeout(timeout.current);
    }, deps);
}

On retrouve ici la logique propre au debounce qui permet d'initialiser un timer depuis un delay dans l'optique de retourner une callback : le timer est initialisé lorsque le composant est monté et détruit lorsque le composant est démonté grâce à l'utilisation du hook useEffect.

Voyons à présent comment exploiter ce nouveau hook depuis notre blog :

import React, {useState} from "react";

import {useDebounce} from "src/hooks/useDebounce"; // CUSTOM HOOK PATH

const Debounce = () => {
    const [searchValue, setSearchValue] = useState('');

    // Fetch articles with HTTP Request
    const fetchArticles = () => {
        console.log('fetchArticles() is called!');
    }

    /* Use of debounce hook to fetch articles */
    useDebounce(async () => {
        if (searchValue) fetchArticles();
        // else .. 
    }, 1000, [searchValue]); 

    /* Handle the value of search input */
    const handleSearchValue = (e) => {
        const newValue = e.target.value;
        setSearchValue(newValue);
    }

    return (
        <div>
            <input 
                type="text" 
                name="searchValue" 
                value={searchValue}
                onChange={handleSearchValue} 
                placeholder="Votre recherche ici.."
            />
            <br />
            {searchValue && (
                <p>Voici les articles correspondant à:<br/><b>« {searchValue} »</b></p>
                /* ... Display articles ... */
            )}
        </div>
    );
}

export default Debounce;

Notre debounce est enfin opérationnel 🎉

Vous l'avez certainement remarqué 🧐 : notre hook useDebounce a finalement l'allure d'un useEffect.

Seulement, il inclut à présent la logique et le comportement de notre fonction debounce.

La callback handleSearchValue est de ce fait réduite à sa seule et unique fonction : garantir la synchronicité de la valeur de notre barre de recherche avec l'état searchValue, alors que : parallèlement, notre debounce est à l'écoute des changements de cet état.

Le fetch des articles sera ainsi exécuté 1 seconde après la fin de saisie de l'utilisateur dans la barre de recherche (sachant que delay équivaut 1000ms), sous réserve que la recherche ne soit pas nulle.

Note : La callback transmise à notre hook useDebounce sera exécutée une première fois par défaut lorsque le composant Debounce sera monté. Cela peut représenter une contrainte dans certaines situations, une mesure conditionnelle devient nécessaire.

⏯️ La fonction « Throttle »

La fonction « Throttle » permet de réguler le nombre d'exécution d'une fonction invoquée par une série d'évènements en l'exécutant une seule fois (toutes les 1000ms par exemple) selon un interval donné.

Elle est souvent utilisée pour appréhender une surexploitation des ressources et d'éventuels problèmes de performance à travers un excès d'opérations.

Quand est-ce nécessaire ?

Reprenons l'exemple de notre blog et intéressons-nous à présent à la page de visualisation des articles : supposons que nous voulions implémenter un système de suivi des chapitres selon la position vertical du client par rapport à la hauteur de la page.

Nous aurions naturellement besoin des propriétés retournées par l'évènement scroll :

useEffect(() => {
    /* Chapters following feature */
    const updateCurrentChapter = (scrollTop, scrollAvailable) => {
        console.log(`scroll progress => ${scrollTop}/${scrollAvailable}`); // debug
        // Feature implementation here..
    }
    /* Handle scroll */
    const handleScroll = (e) => {
        const scrollAvailable = (document.body.scrollHeight - window.innerHeight);
        const scrollTop = window.pageYOffset;
        updateCurrentChapter(scrollTop, scrollAvailable); // Throttle is required here
    }
    window.addEventListener("scroll", handleScroll);
    return () => window.removeEventListener("scroll", handleScroll);
}, []);

Si implémenter la nouvelle feature dans notre callback handleScroll semble idéal, elle peut pour autant impliquer de véritables problèmes de performance au fil de l'évolution de l'application.

En effet, de nouvelles fonctionnalités sont susceptibles d'être ajoutées et greffées à l'évènement scroll, les opérations cumulées les unes avec les autres peuvent représenter une charge de calculs trop importante quant au nombre d'occurences excessif de l'évènement scroll.

C'est à cette occasion que le « Throttle » se révèle utile.

Il va permettre d'exécuter notre fonction updateCurrentChapter(..) et potentiellement d'autres fonctions nécessitant l'évènement scroll, au fil du déroulement de la page grâce à l'évènement scroll, à une fréquence plus raisonnable.

Si l'évènement scroll peut, dans cet exemple, invoquer notre fonction updateCurrentChapter(..) jusqu'à 18 fois par seconde, on pourrait dorénavant décider de ne l'exécuter qu'une seule fois en l'espace d'une seconde et ainsi déshériter notre naviguateur d'une charge de calculs inutile pour parvenir au même résultat.

Comment ça fonctionne ?

🟨 Approche globale en Javascript

La fonction Throttle nécessite généralement deux paramètres:

Une callback, nous utiliserons cb (qui sera retourné sous condition)
Un delai, nous utiliserons delay (en millisecondes)

const throttle = (cb, delay) => {
    let wait = false;
    return (...args) => {
        if (wait) return;
        cb(...args);
        wait = true;
        setTimeout(() => {
            wait = false;
        }, delay);
    }
}

Lorsque notre fonction throttle(..) est invoquée, la callback cb fournie est instantanément retournée (sous réserve qu'elle n'ai pas été invoquée depuis delay millisecondes), il faudra à présent attendre delay millisecondes avant qu'elle puisse être retournée à nouveau.

Ainsi, le throttle permet de réduire le nombre d'occurence d'une fonction lorsqu'elle est parfois excessivement invoquée par une série d'évènements.

ℹ️ Note : La fréquence d'appels est réduite et on peut s'assurer que la fonction ne soit exécutée qu'une seule fois toutes les delay millisecondes.

⚙️ Hook React personnalisé useThrottle

Oublions à présent notre blog et concentrons-nous sur le fonctionnement du throttle grâce à un bouton à cliquer. L'enjeu est simple : cliquer rapidement sur un bouton et incrémenter un compteur tout en l'empêchant de s'incrémenter plus d'une fois toutes les X secondes selon delay.

Le principe est le même que le cas précédent : réguler l'exécution d'une fonction invoquée par une série d'évènements excessivement nombreux.

Pour cela, commencons par créer notre nouveau hook React useThrottle.

import { useEffect, useRef, useState } from 'react';

export const useThrottle = (value, delay = 500) => {
    const [throttledValue, setThrottledValue] = useState(value);
    const lastExecuted = useRef(Date.now());

    useEffect(() => {
        if (Date.now() >= lastExecuted.current + delay) {
            lastExecuted.current = Date.now();
            setThrottledValue(value);
        } else {
            /* Last update */
            const timeout = setTimeout(() => {
                lastExecuted.current = Date.now();
                setThrottledValue(value);
            }, delay);
            return () => clearTimeout(timeout);
        }
    }, [value, delay]);

    return throttledValue;
}

Vous l'avez remarqué, notre callback cb auparavant utilisée a été délaissée au profit d'une valeur value. Quelque soit la fréquence à laquelle value est modifiée, notre throttle garantie de l'actualiser et la retourner mais ne l'actualisera pas plus d'une fois chaque delay millisecondes.

Une fois le composant monté, l'object lastExecuted devient persistant : on lui attribuera une date Date.now() grâce à laquelle nous déterminerons si la valeur value doit être modifiée et si la date lastExecuted.current doit être raffraichit.

Lorsque value change, le throttle est sollicité. Si elle n'a pas été changée durant les delay millisecondes, on raffraichit la valeur retournée et actualisons la date lastExecuted.current, le cas échéant nous lançons un timer pour une dernière exécution dans l'hypothèse où aucun nouvel appel ne vienne l'annuler.

Implémentons à présent notre bouton et nos compteurs :

import React, { useState, useEffect } from 'react';

import { useThrottle } from 'src/hooks/useThrottle';

const Throttle = () => {
    const [clickCount, setClickCount] = useState(0);
    const [clickCountThrottle, setClickCountThrottle] = useState(0);

    const throttledValue = useThrottle(clickCount, 1000);
    useEffect(() => {
        if (throttledValue) setClickCountThrottle(clickCountThrottle + 1);
    }, [throttledValue]);

    return (
        <div className="Container">
            <h2>Throttle</h2>
            <div className="Content">
                <button onClick={() => setClickCount(clickCount + 1)}>Cliquez-moi</button>
            </div>
            <div className="Content">
                <div className="Result_Item">
                    <i>Nb. de click (sans throttle)</i><br />
                    <span>{clickCount}</span>
                </div>
                <div className="Result_Item">
                    <i>Nb. de click (avec throttle 1000ms)</i><br />
                    <span>{clickCountThrottle}</span>
                </div>
            </div>
        </div>
    )
}

export default Throttle;

Et voilà 🎉

Si l'on clique 11 fois sur notre bouton en moins de 2 secondes, notre état clickCountThrottle ne sera incrémenté que 2 fois. clickCount en revanche sera égal à 11.

La valeur throttledValue utilisant notre fonction throttle(..) et basé sur la valeur de clickCount peut à présent être utilisée et devenir une dépendance pour ainsi permettre l'exécution d'une ou plusieurs fonctions grâce au hook useEffect.

Liens et sources

Les snippets de code inclus dans cet articles peuvent être retrouvés depuis une source accessible depuis un repo. Github (voir ci-dessous).

Les exemples peuvent être simulés via une démo live hébergé par CodeSandbox.io (lien ci-dessous), ainsi, le code incluant les différentes fonctions étudiées est accessible à tou.s.tes.

Github Repository (Source)
https://github.com/MessageGit/debounce-and-throttle-react-hooks

Live Demo (CodeSandbox.io)
https://licvw6-3000.csb.app/

Lodash (JS Lib. including Debounce and Throttle functions)
https://lodash.com/

⭐ Les 10 outils indispensables dans le quotidien d'un(e) developpeu.r.se

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:05:18 +0000

Si l'on peut facilement assimiler le monde du développement à un long parcours abondant de problèmes en tout genre, un véritable arsenal de solutions s'est construit avec le temps pour faciliter le quotidien des développeu.rs.ses.

Ces solutions sont des outils web, programmes et librairies. Des utilitaires qui s'associent avec vos projets du quotidien et garantissent leur bon développement.

La plupart de ces utilitaires sont gratuits d'utilisation et vous permettent de gagner un temps considérable ☀️

Voici 10 utilitaires que j'utilise quotidiennement en tant que développeur 👇

ℹ️ Shields.io

Shields.io est un générateur de badges en ligne utilisé par exemple pour compléter les informations liées à un répertoire Github. Il permet notament d'informer quant aux propriétés du projet : Numéro de version, Nombre de pull requests / issues, statut d'un serveur Discord, Suivi des informations liées au dernier build, etc..
Visitez ce site à l'adresse : https://shields.io/

🌐 Ngrok

Ngrok est un utilitaire permettant d'exposer un(e) application/serveur local(e) publiquement sur internet (depuis un protocole quel qu'il soit). Un sous-domaine vous est dédié et une adresse web est générée. Ngrok permet dès lors à n'importe quel client disposant d'une connexion internet de communiquer avec votre service.
Visitez ce site à l'adresse : https://ngrok.com/

〽️ Upptime

Upptime est une librairie Github open-source permettant de suivre l'accessibilité et l'état de vie de vos différentes applications web en fournissant un rapport de statistiques via Github Pages et par l'intermédiaire de commits.

Site de la librairie : https://upptime.js.org/
Lien Github : https://github.com/upptime/upptime

🐳 Docker

On ne le présente plus. Docker est le célèbre utilitaire d'origine 🇲🇫 permettant la conteneurisation de processus : une solution plus légère que la virtualisation qui permet d'empaqueter une application ainsi que ses dépendances dans un conteneur isolé. Le conteneur, une fois configuré, peut ainsi être lancé sur n'importe quel serveur équipé de Docker.

ℹ️ L'outil Docker Compose permet le déploiement de plusieurs conteneurs via la configuration d'un fichier YAML.

En bref, Docker exploite et émule les ressources d'OS légers/minifiés pour lancer des processus divers (par exemple : héberger une base de donnée, lancer un serveur Redis, etc..)

Site de la plateforme : https://www.docker.com/

📋 Notion

Notion est une application de prise de notes permettant la création de wikis, agencement de documentations, création de rappels etc.. Elle est dédiée à un usage collectif et individuel : aussi bien utile en entreprise que pour soi. Elle est la copie numérique parfaite d'un calepin à toujours avoir sous la main.

L'application est disponible avec tous les systèmes d'exploitations (y compris mobile).
Site de la plateforme : https://www.notion.so/

🔴 FileZilla

Le logiciel client FileZilla est strictement indispensable dans les missions quotidiennes d'un(e) DevOps. Il permet l'exploitation du protocole FTP (Port 21) ou SFTP via SSH (Port 22). A savoir : le transfert de fichiers depuis différentes machines.

Une arborescence fluide et concise des répertoires et fichiers est proposée par FileZilla. Le logiciel garantit la bonne exécution de l'intégralité de vos opérations liées au transfert de fichiers.

ℹ️ FileZilla prend également en charge l'authentification via paire de clés depuis l'agent SSH, dans le cas d'une connexion SFTP.
Site de la plateforme : https://filezilla-project.org/

🧍Postman

Postman est un logiciel permettant l'exécution de requêtes HTTP(S). Il propose une interface claire et optimisée qui facilite la perception structurelle des données envoyées/reçues autorisant la gestion intégrale des paramètres liées aux requêtes (Ex: headers, cookies, méthode, etc..)

Le logiciel permet l'importation/exportation de collections personnalisables au format JSON.

L'utilisateur peut dès lors :

Référencer ses requêtes
Lier des exemples de réponse pour chaque requête
Créer et utiliser des variables d'environnement
Apporter de la documentation pour chaque requête ...

[...] Puis publier le fichier .json sur le dépôt distant d'un projet collectif pour garantir l'accessibilité du schema/mapping lié aux différents end-points de l'API du projet.
Site du logiciel : https://www.postman.com/

🗒️ Dev.to

Dev.to regroupe une communauté de développeu.rs.euses garantissant une veille technologique active quant aux dernières évolutions / tendances. On y trouve quotidiennement : documentation, tips du quotidien, retours d'expérience, synthèses, « cheatsheets », comparaisons techniques, etc..

La plateforme propose également une newsletter synthétique pour recevoir les dernières publications de la communauté chaque semaine.
Site de la plateforme : https://dev.to/

🗃️ DevHints.io

DevHints.io est un site répertoriant les différentes syntaxes et conventions liées à chaque language de programmation / framework.

Ce site est très utile pour les dévelopeu.rs.euses passant régulièrement d'un language à un autre, il permet via des « cheatsheets » pertinentes de se remémorer les bonnes pratiques liées à la syntaxe d'un language de programmation.

Site de la plateforme : https://devhints.io/

👥 DeepL

DeepL est un traducteur en ligne performant permettant de traduire jusqu'à 31 langues différentes en entrée ou sortie. DeepL est réputé pour la puissance et la pertinence de sa capacité de traduction.
Site de la plateforme : https://www.deepl.com/translator

⛏ Le scraping, une technologie d'extraction de contenu web

Grégory CHEVALLIER — Tue, 17 Oct 2023 07:04:13 +0000

A l'heure où l'on ne dénombre pas moins de 1,8Md de sites mis en ligne sur le Web, la quantité de données qui y transite quotidiennement reste pour le moins difficile à estimer. Certaines données font parfois l'objet de toutes les convoitises et les méthodes employées pour les importer nécessitent parfois un certain niveau d'expertise.

Le scraping, qu'est ce que c'est ?

Le scraping (ou "grattage" en français) consiste à extraire des données depuis un site web par l'intermédiaire d'un programme informatique automatisé. Son fonctionnement est étroitement similaire à celui des robots quotidiennement déployés par les moteurs de recherches pour permettre notamment l'indexation des sites web.

D'un point de vue technique, plusieurs langages de programmation permettent la conception d'un logiciel de scraping, parmi les plus connus, on retrouve Python, Javascript ainsi que de nombreux frameworks facilitant leur utilisation. Pour Javascript : Selenium, PhantomJS et pour Python : BeautifulSoup et Scrapy.

Le scraping étape par étape

Le processus commence tout d'abord par l'exécution d'une requête HTTP qui réceptionne le contenu distant d'une page web (autrement dit, le document HTML). Le programme de scraping effectue par la suite un travail dit de "Parsing" (découpage), qui consiste à analyser la structure du code réceptionné depuis les balises qui le composent et prélever les informations essentielles. Une fois les données prélevées, elles pourront ensuite être réunies au sein d'un document texte/json ou d'une base de données, puis ré-utilisées au bon vouloir de celui ou celle qui les détiennent.

var webPage = require('webpage')
var page = webPage.create();

page.open('http://phantomjs.org', function (status) {
  var content = page.content;
  console.log('Content: ' + content);
  phantom.exit();
});;

Ci-dessus, un exemple de code permettant l'importation intégrale du contenu de la page web distante au format HTML
Framework: PhantomJS.

L'un des principaux avantages à automatiser une tâche de scraping est la garantie d'importer une vaste quantité de données "fraîches" en un temps record et, facultativement, de manière quotidienne.

Certains programmes de scraping sont commercialisés et publiquement déployés comme des services à part entière. L'intérêt de recourir à de telles pratiques varie également selon les besoins et les secteurs d'activités. Globalement, les entreprises utilisent ces données pour analyser leur concurrence ou un secteur qu'elles jugent stratégique.

Pourquoi cette pratique est t-elle malgré tout critiquée ?

Le scraping, de manière modérée ou ponctuelle ne représente pas de problème majeur en soi : il permet d'accélérer et automatiser ce qu'un humain aurait réalisé en beaucoup plus de temps en ayant recours au copier/coller. Cependant, il génère à grande échelle un trafic important et indésirable qui crée un ralentissement des sites victimes de ce processus, les utilisateurs légitimes sont alors pénalisés.

De plus, aucune entreprise ne souhaite retrouver ses données exploitées, et, parfois, abusivement ré-utilisées par une autre entité. On parle alors d'un détournement de traffic.

Comment s'en protéger ?

Une multitude de protections, aux niveaux de difficultés techniques variables, peuvent être mises en place pour échapper à ce phénomène.

La limitation des requêtes

Cette précaution consiste à identifier chaque visiteur et limiter le nombre de requêtes par seconde à destination du site, au-delà de cette limite, il est possible de le bloquer momentanément voir définitivement en cas d'abus avéré. Cette protection, bien qu'efficace, doit être configurée en bonne et due forme, au risque de bloquer des utilisateurs légitimes et ainsi compromettre l'accessibilité du site.

La mise en place d'un captcha.

Il s'agit d'une vérification manuelle ou automatisée permettant de déterminer si le visiteur est bien un humain et non pas un robot. En proposant par exemple une énigme simple à résoudre ou un texte à recopier. Le captcha invisible est aujourd'hui privilégié, il ne force pas l'utilisateur à réaliser d'action et ne cause aucun tort à l'UX du site, mais requiert d'autres méthodes d'identifications (mouvement de souris, scroll sur la page ...) pour déterminer si celui-ci est bel & bien humain.

La modification régulière et/ou intempestive des codes de balisage HTML.

Un programme de scrapping, pour l'analyse d'une page, se focalise essentiellement sur la structure statique qui compose le document. De nombreuses méthodes relatives au changement de cette structure permet de rendre caduque la plupart des programmes de scraping. Ainsi, lors de leur exécution, plus rien ne leur permet de savoir où chercher les informations pour lesquelles ils ont été configurés.

La mise en images d'informations textuelles sensibles.

Cette option est à éviter autant que possible, les images étant inaccessibles aux utilisateurs malvoyants.

C'est ainsi que les développeurs s'adonnent à un véritable jeu du chat et de la souris. Et pour cause, les “scrapers“ peuvent malgré tout redoubler d'ingéniosité et trouver des parades aux précautions mentionnées ci-dessus.

Ils peuvent par exemple :

Recourir (pour les plus motivés) à des technologies d'analyses optique (OCR) pour remplir les captcha ou prélever des informations cachées dans du contenu mis en image.
Automatiser l'utilisation de Proxy/VPN pour leur permettre d'exécuter un programme depuis plusieurs IP's différentes.
Ralentir leurs scripts pour qu'ils restent sous le seuil de limitations des requêtes de votre site et ensuite l'exécuter sur plusieurs machines possédant des IP's différentes.

Que dit la loi ?

Un dernier point reste malgré tout à éclaircir vis à vis de cette pratique, si la mise en service d'un de ces programme ne relève pas d'un manquement direct aux législations en vigueur, qu'en est t-il du seuil de tolérance lié à ces méthodes aux opinions controversées et dans quel cas est t-il outrepassé ?

L'article 323-3 du Code Pénal indique "Le fait d'introduire frauduleusement des données dans un système de traitement automatisé, d'extraire, de détenir, de reproduire, de transmettre, de supprimer ou de modifier frauduleusement les données qu'il contient est puni de cinq ans d'emprisonnement et de 150 000 € d'amende." le terme "système de traitement automatisé" n'a pas de définition exacte et peux couvrir la majorité des sites.

Pour finir, l'Article L342-1 du code de la propriété intellectuelle ne manque surtout pas à rappeler qu'un producteur de base de données à le droit d'interdire:

L'extraction, par transfert permanent ou temporaire de la totalité ou d'une partie qualitativement ou quantitativement substantielle du contenu d'une base de données sur un autre support, par tout moyen et sous toute forme que ce soit.

La réutilisation, par la mise à la disposition du public de la totalité ou d'une partie qualitativement ou quantitativement substantielle du contenu de la base, quelle qu'en soit la forme.

Mais aussi que ces droits peuvent être transmis, cédés ou faire l'objet d'une licence.