DEV Community: Guillaume

Symfony et Shadcn/ui

Guillaume — Sat, 02 Aug 2025 07:36:02 +0000

Hi guys !

J'espère que vous avez tous vu les nouveaux kits de démarrage de Laravel avec Inertia, React et Shadcn/UI. C'est beau...compliqué mais beau.

Suite à mon précédent article React dans Symfony avec Vite je me suis demandé pour les besoin d'un projet comment faire un front en React avec Shadcn/UI et un backend Symfony.

Quelques précisions : ici on va utiliser une structure "Fullstack" (tout dans le même projet) alors qu'on pourrait coder un front en React isolé et juste le backend en Symfony. Pour des raisons de simplicité, notamment pour la gestion de l'authentification, c'est beaucoup plus simple de faire comme ça. Mais au final, notre front et notre back vont bien communiquer via des API REST comme si ils étaient isolés.

Allez c'est parti !

Création du projet et ajout de React

Je ne vais pas refaire le tuto. Créez votre projet comme indiqué dans mon précédent tuto React dans Symfony avec Vite

Vérifiez bien que React marche.

Installation de Tailwind

On va installer Tailwind et son plugin Vite.

A la racine de votre projet :

npm install tailwindcss @tailwindcss/vite

Puis ouvrez le fichier vite.config.js et configurez-le comme suit:

import { defineConfig } from "vite";
import symfonyPlugin from "vite-plugin-symfony";
import react from '@vitejs/plugin-react';
import path from "path"
import tailwindcss from "@tailwindcss/vite"

export default defineConfig({
    plugins: [
        react(),
        tailwindcss(),
        symfonyPlugin(),
    ],
    build: {
        rollupOptions: {
            input: {
                app: "./assets/main.jsx"
            },
        }
    },
    resolve: {
        alias: {
            "@": path.resolve(__dirname, "./assets"),
        },
    }
});

On a ajouté :

L'import du plugin Tailwind ligne 5
le plugin dans la liste des plugins
On a ajouté l'alias '@' qu'on définit à la racine de notre répertoire assets (important pour la suite sinon Shadcn ne sait pas où mettre ses composants)

Puis ajoutez la ligne suivante dans assets/styles/app.css:

@import "tailwindcss";

Ajoutez 2/ 3 classes dans votre App.jsx pour vérifier que ça marche bien après avoir relancé un "npm run dev"

Installation de Shadcn/UI

On installe tous les pré-requis:

npm install class-variance-authority clsx tailwind-merge lucide-react tw-animate-css

Et là... la doc n'est pas claire et il y a une incohérence.

Celle-ci ne fait mention que du fichier tsconfig.json, or celui-ci appelle 2 autres fichiers tsconfig.app.json et tsconfig.node.json (faut lire hein, c'est marqué dedans !).

Note : Pour aller récupérer les 2 fichiers absents de la documentation, j'ai créé un projet Vite bidon (avec npm create vite@latest my-project)

Créons maintenant nos 3 fichiers à la racine de notre projet.

tsconfig.json

{
    "files": [],
    "references": [
        {
            "path": "./tsconfig.app.json"
        },
        {
            "path": "./tsconfig.node.json"
        }
    ],
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "@/*": ["./assets/*"]
        }
    }
}

tsconfig.app.json

{
  "compilerOptions": {
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo",
    "target": "ES2022",
    "useDefineForClassFields": true,
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "verbatimModuleSyntax": true,
    "moduleDetection": "force",
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "erasableSyntaxOnly": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedSideEffectImports": true
  },
  "include": ["assets"]
}

tsconfig.node.json

{
  "compilerOptions": {
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo",
    "target": "ES2023",
    "lib": ["ES2023"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "verbatimModuleSyntax": true,
    "moduleDetection": "force",
    "noEmit": true,

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "erasableSyntaxOnly": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedSideEffectImports": true
  },
  "include": ["vite.config.ts"]
}

Note : je n'ai rien modifié (simplement copié du projet Vite exemple) sauf la dernière ligne "include": ["assets"] de tsconfig.app.json que j'ai modifié de 'src' à 'assets' pour coller à nos répertoires Symfony.

Mais c'est pas fini !

On va ajouter les styles Shadcn à notre CSS.

Ouvrez le fichier assets/styles/app.css et ajouter les lignes comme suit (nous ne devriez avoir que la première ligne déjà présente):

@import "tailwindcss";
@import "tw-animate-css";

@custom-variant dark (&:is(.dark *));

:root {
  --background: oklch(1 0 0);
  --foreground: oklch(0.145 0 0);
  --card: oklch(1 0 0);
  --card-foreground: oklch(0.145 0 0);
  --popover: oklch(1 0 0);
  --popover-foreground: oklch(0.145 0 0);
  --primary: oklch(0.205 0 0);
  --primary-foreground: oklch(0.985 0 0);
  --secondary: oklch(0.97 0 0);
  --secondary-foreground: oklch(0.205 0 0);
  --muted: oklch(0.97 0 0);
  --muted-foreground: oklch(0.556 0 0);
  --accent: oklch(0.97 0 0);
  --accent-foreground: oklch(0.205 0 0);
  --destructive: oklch(0.577 0.245 27.325);
  --destructive-foreground: oklch(0.577 0.245 27.325);
  --border: oklch(0.922 0 0);
  --input: oklch(0.922 0 0);
  --ring: oklch(0.708 0 0);
  --chart-1: oklch(0.646 0.222 41.116);
  --chart-2: oklch(0.6 0.118 184.704);
  --chart-3: oklch(0.398 0.07 227.392);
  --chart-4: oklch(0.828 0.189 84.429);
  --chart-5: oklch(0.769 0.188 70.08);
  --radius: 0.625rem;
  --sidebar: oklch(0.985 0 0);
  --sidebar-foreground: oklch(0.145 0 0);
  --sidebar-primary: oklch(0.205 0 0);
  --sidebar-primary-foreground: oklch(0.985 0 0);
  --sidebar-accent: oklch(0.97 0 0);
  --sidebar-accent-foreground: oklch(0.205 0 0);
  --sidebar-border: oklch(0.922 0 0);
  --sidebar-ring: oklch(0.708 0 0);
}

.dark {
  --background: oklch(0.145 0 0);
  --foreground: oklch(0.985 0 0);
  --card: oklch(0.145 0 0);
  --card-foreground: oklch(0.985 0 0);
  --popover: oklch(0.145 0 0);
  --popover-foreground: oklch(0.985 0 0);
  --primary: oklch(0.985 0 0);
  --primary-foreground: oklch(0.205 0 0);
  --secondary: oklch(0.269 0 0);
  --secondary-foreground: oklch(0.985 0 0);
  --muted: oklch(0.269 0 0);
  --muted-foreground: oklch(0.708 0 0);
  --accent: oklch(0.269 0 0);
  --accent-foreground: oklch(0.985 0 0);
  --destructive: oklch(0.396 0.141 25.723);
  --destructive-foreground: oklch(0.637 0.237 25.331);
  --border: oklch(0.269 0 0);
  --input: oklch(0.269 0 0);
  --ring: oklch(0.439 0 0);
  --chart-1: oklch(0.488 0.243 264.376);
  --chart-2: oklch(0.696 0.17 162.48);
  --chart-3: oklch(0.769 0.188 70.08);
  --chart-4: oklch(0.627 0.265 303.9);
  --chart-5: oklch(0.645 0.246 16.439);
  --sidebar: oklch(0.205 0 0);
  --sidebar-foreground: oklch(0.985 0 0);
  --sidebar-primary: oklch(0.488 0.243 264.376);
  --sidebar-primary-foreground: oklch(0.985 0 0);
  --sidebar-accent: oklch(0.269 0 0);
  --sidebar-accent-foreground: oklch(0.985 0 0);
  --sidebar-border: oklch(0.269 0 0);
  --sidebar-ring: oklch(0.439 0 0);
}

@theme inline {
  --color-background: var(--background);
  --color-foreground: var(--foreground);
  --color-card: var(--card);
  --color-card-foreground: var(--card-foreground);
  --color-popover: var(--popover);
  --color-popover-foreground: var(--popover-foreground);
  --color-primary: var(--primary);
  --color-primary-foreground: var(--primary-foreground);
  --color-secondary: var(--secondary);
  --color-secondary-foreground: var(--secondary-foreground);
  --color-muted: var(--muted);
  --color-muted-foreground: var(--muted-foreground);
  --color-accent: var(--accent);
  --color-accent-foreground: var(--accent-foreground);
  --color-destructive: var(--destructive);
  --color-destructive-foreground: var(--destructive-foreground);
  --color-border: var(--border);
  --color-input: var(--input);
  --color-ring: var(--ring);
  --color-chart-1: var(--chart-1);
  --color-chart-2: var(--chart-2);
  --color-chart-3: var(--chart-3);
  --color-chart-4: var(--chart-4);
  --color-chart-5: var(--chart-5);
  --radius-sm: calc(var(--radius) - 4px);
  --radius-md: calc(var(--radius) - 2px);
  --radius-lg: var(--radius);
  --radius-xl: calc(var(--radius) + 4px);
  --color-sidebar: var(--sidebar);
  --color-sidebar-foreground: var(--sidebar-foreground);
  --color-sidebar-primary: var(--sidebar-primary);
  --color-sidebar-primary-foreground: var(--sidebar-primary-foreground);
  --color-sidebar-accent: var(--sidebar-accent);
  --color-sidebar-accent-foreground: var(--sidebar-accent-foreground);
  --color-sidebar-border: var(--sidebar-border);
  --color-sidebar-ring: var(--sidebar-ring);
}

@layer base {
  * {
    @apply border-border outline-ring/50;
  }
  body {
    @apply bg-background text-foreground;
  }
}

Créez un fichier assets/lib/utils.ts tel que:

import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

Et enfin un dernier fichier components.json à la racine du projet:

{
    "$schema": "https://ui.shadcn.com/schema.json",
    "style": "new-york",
    "rsc": false,
    "tsx": true,
    "tailwind": {
        "config": "",
        "css": "assets/styles/app.css",
        "baseColor": "neutral",
        "cssVariables": true,
        "prefix": ""
    },
    "aliases": {
        "components": "@/components",
        "utils": "@/lib/utils",
        "ui": "@/components/ui",
        "lib": "@/lib",
        "hooks": "@/hooks"
    },
    "iconLibrary": "lucide"
}

Normalement c'est tout en terme de configuration.

On va faire un test dans App.jsx pour voir si on peut ajouter un composant Alert de ShadCN.

Installation du composant Alert:

npx shadcn@latest add alert

Puis, modifiez votre App.jsx tel que:

import { useState } from 'react'
import { Alert, AlertDescription, AlertTitle } from "@/components/ui/alert"
import { Terminal } from "lucide-react";

export default function App() {
    const [count, setCount] = useState(0)
    return (
        <div className="relative isolate overflow-hidden bg-white px-6 py-24 sm:py-32 lg:overflow-visible lg:px-6">
            <h1 className="mb-3">Vite + React + Shadcn</h1>

            <Alert variant="default | destructive">
                <Terminal/>
                <AlertTitle>Heads up!</AlertTitle>
                <AlertDescription>
                    You can add components and dependencies to your app using the cli.
                </AlertDescription>
            </Alert>
        </div>
    )
}

Et voilà !

Notez qu'à chaque modification de votre code, Vite recompile et met à jour la page dans votre navigateur.

Amusez-vous bien !

DaisyUI 5 avec Symfony 6/7

Guillaume — Tue, 13 May 2025 19:36:48 +0000

Aujourd'hui, c'est mardi et c'est surtout ...DaisyUI.

Dans les dernières versions de Symfony (6 et 7) on a un nouveau composant pour gérer nos assets : AssetMapper.

Le mini défi du jour : installer DaisyUI pour un nouveau projet.

Création du projet Symfony

Rien de bien compliqué à ce niveau, surtout avec la CLI Symfony (ici mon projet s'appelle FormerK):

symfony new FormerK --webapp

Installation du bundle Tailwind

Encore une fois la doc de Symfony est bien utile :

cd FormerK
composer require symfonycasts/tailwind-bundle

Configuration du bundle Tailwind

Si vous faites tout de suite les commandes indiquées en fin d'installation, vous allez (avec la commande bin/console tailwind:init) installer la version 3 de Tailwind.

Ce n'est pas ce que l'on veut, puisque la dernière version de DaisyUI utilise Tailwind 4.

Pour modifier la version de Tailwind utilisée, éditez le fichier config/packages/symfonycasts_tailwind.yaml et modifiez le comme suit:

symfonycasts_tailwind:
    # Specify the EXACT version of Tailwind CSS you want to use
    binary_version: 'v4.1.6'

Lancez maintenant les commandes suivantes et observez le résultat:

bin/console tailwind:init
bin/console tailwind:build

Installation de DaisyUI

Pour installer DaisyUI, là aussi, rien de compliqué : on va utiliser la commande de gestion des dépendances d'AssetMapper:

bin/console importmap:require daisyui@latest

et voilà le résultat:

Configuration de Tailwind pour utiliser DaisyUI

Dans la version 4 de Tailwind, on utilise maintenant le "@plugin".
Nous n'avions pas configuré Tailwind dans notre projet, donc on va faire les 2 en même temps.
Editez le fichier assets/styles/app.css comme suit:

@import "tailwindcss";
@plugin "../vendor/daisyui/daisyui.index.js";

Puis relancez un build Tailwind avec la même commande :

bin/console tailwind:build

et admirez le résultat:

Un exemple !

Créez un controleur dans votre application et dans votre template, ça doit donner ça avec l'exemple d'alert de DaisyUI :

{% extends 'base.html.twig' %}

{% block body %}
    <div role="alert" class="alert alert-success">
        <svg xmlns="http://www.w3.org/2000/svg" class="h-6 w-6 shrink-0 stroke-current" fill="none" viewBox="0 0 24 24">
            <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M9 12l2 2 4-4m6 2a9 9 0 11-18 0 9 9 0 0118 0z" />
        </svg>
        <span>Your purchase has been confirmed!</span>
    </div>
{% endblock %}

Evidemment, il faut relancer la commande de compilation de tailwind:

bin/console tailwind:build

Si vous ne voulez pas relancer la build à la main en permanence et que ça recompile à chaque changement sur vos templates, laissez tourner la commande suivante dans un terminal:

bin/console tailwind:build --watch

Et voilà le résultat :

Enjoy !

React dans Symfony avec Vite

Guillaume — Sat, 11 Feb 2023 21:19:36 +0000

Problème du jour : je veux me mettre à React, mais avec un backend Symfony.

Alors OK, vous allez me dire d'utiliser Webpack Encore et vous avez raison.... sauf que webpack est lent, surtout dans la phase de dev.

Donc l'idée est de trouver comment intégrer Vite à notre projet et comment configurer Vite pour faire marcher React.

Créons notre projet Symfony (6)

Rien de bien compliqué ici avec la CLI Symfony:

symfony new --webapp reactSymfonyProject

Intégrer Vite à mon projet Symfony

Heureusement, quelqu'un s'est penché sur le problème pour nous (même si le faire à la main n'aurait pas non plus été infaisable). Il y a donc un bundle pour ça !

Entrez dans le répertoire du projet et installez le bundle:

composer require pentatrion/vite-bundle

Voici le résultat de l'installation :

On va donc faire comme indiqué, en sautant la première étape - en bref on laisse les paramètres par défaut.
Si la deuxième vaut quand même le coup d'oeil (allez jeter un oeil au fichier vite.config.js comme indiqué), le fichier ne requiert aucune modification.

Suivez l'étape 3 et installez les dépendances Javascripts

yarn install (ou npm install)

Enfin, on va aller modifier notre template Twig de base pour aller chercher le résultat de la compilation de Vite.

Dans le fichier templates/base.html.twig, remplacez la ligne :
{{ encore_entry_link_tags('app') }}
par
{{ vite_entry_link_tags('app') }}

puis la ligne:
{{ encore_entry_script_tags('app') }}
par
{{ vite_entry_script_tags('app', { dependency: 'react' }) }}

Création d'un contrôleur de test

A la racine du projet :

symfony console make:controller Test

On a maintenant une URL /test de disponible

Premier test

On va démarrer tout ça et voir le résultat

D'abord on va démarrer le serveur PHP interne:
symfony serve -d

Puis on va compiler nos assets:
yarn dev

Rendez-vous maintenant dans votre navigateur à l'adresse :
https://127.0.0.1:8000/test

Note : le port 8000 peut différer sur votre installation. L'adresse est indiquée quand vous démarrez le serveur PHP.

Maintenant constatez le résultat en ouvrant la console Javascript (F12):

On voit ici qu'on retrouve bien le résultat de notre script assets/app.js et que Vite est bien démarré en mode dev.

Vous pouvez faire un test pour voir la puissance de Vite au regard de Webpack.

Ajouter à la fin du fichier assets/app.js n'importe quel console.log('plop'), et regardez le résultat apparaître dans la console instantanément, sans recharger la page du navigateur !

OK pour Vite, mais pour React ?

Pour l'instant on est d'accord, Vite marche mais pas de React en vue (notez la blague React - Vue).

Il nous manque 2 choses : du code certes, mais aussi des dépendances.

Installons-les:

yarn add -D @vitejs/plugin-react @types/react @types/react-dom
yarn add react react-dom

On va maintenant transformer notre Javascript et faire un peu de React.

Ouvrez le fichier assets/app.js et transformez-le comme suit:

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'

import "./app.css";

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

Comme vous le voyez, on va "rendre" notre application dans un element avec un ID "root".

On ne l'a pas pour le moment. Pour cela, on va modifier notre page de test (fichier templates/test/index.html.twig) comme suit:

{% extends 'base.html.twig' %}

{% block title %}Hello TestController!{% endblock %}

{% block body %}
<div id="root"></div>
{% endblock %}

On va relancer Vite, et voir ce que ça donne....
A la racine du projet, relancez Vite;
yarn dev

Ouch, une grosse erreur apparaît et c'est bien normal :

On a mis du JSX dans un fichier avec l'extension ".js".
Pour des raisons pratiques, on va renommer notre app.js en main.jsx

N'oublions pas non plus de modifier notre vite.config.js en pointant aussi vers le fichier main.jsx au lieu de app.js. On va aussi en profiter pour dire à Vite qu'on utilise son plugin React. Votre fichier vite.config.js doit donc ressembler à ça:

import { defineConfig } from "vite";
import symfonyPlugin from "vite-plugin-symfony";
import react from '@vitejs/plugin-react'


export default defineConfig({
    plugins: [
        react(),
        symfonyPlugin(),
    ],
    build: {
        rollupOptions: {
            input: {
                app: "./assets/main.jsx"
            },
        }
    },
});

Relancez Vite, et constatez que vous avez une nouvelle erreur....normal, on a pas fini notre code ;)
On dit dans notre fichier main.jsx de rendre le composant "App" mais on ne l'a pas créé ! C'est aussi pour des raisons de conflit qu'on a renommé notre app.js en main.jsx et non en app.jsx.

Créez maintenant au même niveau que main.jsx un fichier App.jsx avec ce contenu :

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from './images/vite.svg'

function App() {
  const [count, setCount] = useState(0)

  return (
    <div className="App">
      <div>
        <a href="https://vitejs.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://reactjs.org" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          count is {count}
        </button>
        <p>
          Edit <code>assets/App.jsx</code> and save to test HMR
        </p>
      </div>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </div>
  )
}

export default App

Note: vous trouverez les logos de React et Vite en SVG sur Internet ;)

Modifiez aussi le CSS de l'application (fichier assets/app.css) comme suit:

#root {
  max-width: 1280px;
  margin: 0 auto;
  padding: 2rem;
  text-align: center;
}

.logo {
  height: 6em;
  padding: 1.5em;
  will-change: filter;
  transition: filter 300ms;
}
.logo:hover {
  filter: drop-shadow(0 0 2em #646cffaa);
}
.logo.react:hover {
  filter: drop-shadow(0 0 2em #61dafbaa);
}

@keyframes logo-spin {
  from {
    transform: rotate(0deg);
  }
  to {
    transform: rotate(360deg);
  }
}

@media (prefers-reduced-motion: no-preference) {
  a:nth-of-type(2) .logo {
    animation: logo-spin infinite 20s linear;
  }
}

.card {
  padding: 2em;
}

.read-the-docs {
  color: #888;
}

Et voilà, normalement, vous devriez avoir cette page qui apparait dans votre navigateur :

Créer un blog avec Strapi et Angular

Guillaume — Sun, 08 May 2022 21:07:40 +0000

Suite à la vidéo de Yoandev (https://youtu.be/KGHJYoxlGRE), voici le petit (grand !) défit du jour : créer un blog avec Strapi et Angular.

Quelques explications:

Alors avant de commencer à coder, on va regarder pourquoi Strapi et pourquoi Angular.

Strapi est ce qu'on appelle un "headless CMS".
En bref, vous pouvez créer vos propres "type de contenu" (comme dans Drupal par exemple) et les exposer via une API.
C'est vraiment pratique, et ça a beaucoup d'avantages:

on s'évite la customisation de la partie "front" qui est souvent un enfer avec les CMS traditionnels
on découple la partie backend (Strapi) et la partie "front" (ici Angular).
on va disposer d'une API, donc potentiellement, vous pouvez aller la consommer avec une appli mobile ou un autre front.
si jamais vous n'êtes pas satisfait d'Angular, rien ne vous empêche de la refactorer avec du VueJS, du React, ou ... du Symfony comme Yoan ;)

Heu c'est quoi un "type de contenu"

Hé ben c'est un objet, une "Entity" en Symfony, ou un Model dans une version plus générique.

Dans notre exemple, notre type de contenu va être "Article".
Il va contenir:

un titre
un contenu
une image
une date de publication

Vous avez tout compris ?
Alors on y va pour le code !

Note : cet article est basé sur un article du blog de Strapi : Build a blog with Angular, Strapi and Apollo

Pré-requis

Pas grand chose si ce n'est node et npm (et yarn ici)

Personnellement, j'utilise NVM (https://github.com/nvm-sh/nvm) pour éviter les conflits de version de Node suivant les projets.
Je vous donnerai les commandes à faire tout au long du tutoriel.

Backend

Installation de Strapi

On va créer un répertoire pour la totalité du projet (backend + frontend) et rentrer à l'intérieur.

mkdir blog-strapi && cd blog-strapi

Puis on va créer notre application Strapi:

yarn create strapi-app backend --quickstart --no-run

Le flag "--no-run" va éviter de la démarrer tout de suite après l'installation.

Premier problème soulevé ici avec la version de node de ma distribution Linux.

Ma solution: entrer dans le répertoire de l'application Strapi, supprimer le répertoire node_modules, puis créer un fichier .nvmrc pour "statifier" la version de Node utilisée pour le projet (ici 16+) et enfin réinstaller les dépendances (un simple yarn suffit).

En bref:

cd backend
rm -rf node_modules/
echo "16" > .nvmrc
yarn

Toujours dans le même répertoire "backend" (notre application Strapi), installons le plugin graphql avec

yarn strapi install graphql

Quand l'installation du plugin est finie, lançons notre application:
yarn strapi dev

Normalement, la fenêtre de navigateur va s'ouvrir sur l'interface d'administration de Strapi, et vous demander de créer un compte admin.

Création de notre type de contenu "Article".

Dans le menu de gauche, sélectionnez "Content-type Builder" puis le lien "Create new collection type".

Donnez lui le nom "Article", tel que:

Puis ajoutez (bouton "Add another field") les champs suivants:

title de type "Text" (required)
content with type Rich Text (required)
image with type Media (Single image) and (required)

Note 1 : pour mettre un champ "required", allez dans l'autre onglet "advanced settings"

Note 2 : le champ "published_at" est automatique, donc n'est pas à créer.

On enregistre avec "Save" et puis on se lâche, on va créer nos premiers articles dans le backend, via le "Content Manager".

Après la rédaction de quelques articles, on se dit que ça serait bien de tester si l'API nous les renvoie !

Aucun problème, tout est prévu !

Ah oui, sauf qu'avant, il faut régler la partie "permissions".
L'API n'est pas accessible par défaut. Il faut, pour chaque type de contenu, déterminer qui a droit de quoi faire.

Allez dans le menu de gauche "Settings", puis dans "USERS & PERMISSIONS PLUGIN" > Roles.

Nous allons modifier le rôle "public" (avec le crayon) et ajouter les droits comme suit:

Maintenant que les permissions sont réglées, on va pouvoir tester notre API.

Rendez-vous sur l'interface de test de GraphQL avec votre navigateur ici.

Je vous laisse regarder ce qu'est graphQL, mais en bref, comparé à REST, cela va vous permettre de "choisir" les champs qui seront renvoyés par l'API. C'est comme REST mais en mieux, même si le langage de requêtage n'est pas forcément trivial.

Note: l'interface de test GraphQL est très bien faite : elle dispose notamment d'une complétion automatique bien pratique !

Sur l'interface, créez une requête telle que:

query Articles {
    articles {
    data {
      id, 
      attributes {
        title, 
        content, 
        image {
          data {
            attributes{
              url
            }
          }
        }
      }
    }
  } 
}

Après execution, vous obtiendrez une réponse telle que :

{
  "data": {
    "articles": {
      "data": [
        {
          "id": "1",
          "attributes": {
            "title": "Premier post",
            "content": "Ah enfin ce premier post !\nLe premier d'une longue série ;)\n\nEt puis je vais rappatrier ici tous les articles produits sur d'autres plateformes ;)\n\nA très bientôt !",
            "image": {
              "data": {
                "attributes": {
                  "url": "/uploads/wanderlabs_T_Ap9_Hue_Sl_KQ_unsplash_1_5e82873dce.jpg"
                }
              }
            }
          }
        },
        {
          "id": "2",
          "attributes": {
            "title": "Créer un blog avec Strapi",
            "content": "D'avoir, allez voir la vidéo de Yoandev ;)",
            "image": {
              "data": {
                "attributes": {
                  "url": "/uploads/photo_1499750310107_5fef28a66643_ixlib_rb_1_2_2f258ec988.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=870&q=80"
                }
              }
            }
          }
        }
      ]
    }
  }
}

Catégories

Chaque Article va disposer d'une "catégorie".

Créez une nouvelle collection nommée "Categorie" avec un seul champ "name" de type "Text" et la sauvegarder.

On va maintenant lier nos 2 types de contenu "Article" et "Categorie" : une catégorie est liée à 1 ou plusieurs articles.

Ainsi, toujours dans le "Content-Type Builder", sélectionnez "Article" puis ajouter un champ de type "Relation" comme suit:

N'oubliez pas de cliquer sur "finish" dans la modale, puis sur "Save" pour enregistrer les modifications de notre type de contenu Article.

Enfin, il faut régler la partie "droits" sur notre nouveau type "Category".
Comme pour Article, on va dans le menu de gauche "Settings", puis dans "USERS & PERMISSIONS PLUGIN" > Roles > public, et modifier l'entrée Categorie comme suit :

Maintenant que vous avez vos catégories, allez dans le Content-Manager, créez des catégories et associez chacun de vos articles à une catégorie.

Vous pouvez de nouveau tester votre API avec le client GraphQL avec une requête telle que:

query Articles {
    articles {
    data {
      id, 
      attributes {
        title, 
        categorie {
          data {
            id, 
            attributes {
              name
            }
          }
        },
        content, 
        image {
          data {
            attributes{
              url
            }
          }
        }
      }
    }
  } 
}

Vous obtiendrez alors un résultat de ce type:

{
  "data": {
    "articles": {
      "data": [
        {
          "id": "1",
          "attributes": {
            "title": "Premier post",
            "categorie": {
              "data": {
                "id": "3",
                "attributes": {
                  "name": "blog"
                }
              }
            },
            "content": "Ah enfin ce premier post !\nLe premier d'une longue série ;)\n\nEt puis je vais rappatrier ici tous les articles produits sur d'autres plateformes ;)\n\nA très bientôt !",
            "image": {
              "data": {
                "attributes": {
                  "url": "/uploads/wanderlabs_T_Ap9_Hue_Sl_KQ_unsplash_1_5e82873dce.jpg"
                }
              }
            }
          }
        },
        {
          "id": "2",
          "attributes": {
            "title": "Créer un blog avec Strapi",
            "categorie": {
              "data": {
                "id": "2",
                "attributes": {
                  "name": "strapi"
                }
              }
            },
            "content": "D'avoir, allez voir la vidéo de Yoandev ;)",
            "image": {
              "data": {
                "attributes": {
                  "url": "/uploads/photo_1499750310107_5fef28a66643_ixlib_rb_1_2_2f258ec988.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=870&q=80"
                }
              }
            }
          }
        }
      ]
    }
  }
}

Résumé du backend

Maintenant, on a un beau backend avec Strapi qui nous fournit une belle API GraphQL pour délivrer des articles avec des catégories.

Frontend

Dans notre console, on va laisser Strapi démarré, et on va revenir dans le répertoire de base du projet

cd blog-strapi

Création de l'application Angular

D'abord, on va installer le CLI Angular :

sudo npm install -g @angular/cli

Puis créons notre application frontend (acceptez l'ajout de "Angular Routing":

ng new frontend

L'application est maintenant créée, on va maintenant la lancer:

cd frontend
ng serve

Ouvrez votre navigateur à l'adresse http://localhost:4200/

Installons maintenant le plugin Apollo / client GraphQL à notre application:

ng add apollo-angular

On va aussi ajouter la bibliothèque de composants CSS "UIKit" :

yarn add uikit jquery

Ajoutons maintenant les dépendances javascript du kit à notre code.
Pour cela, ouvrez le fichier angular.json et trouvez la clé
projects > frontend > architect > build > options > scripts qui doit être un tableau vide et configurez-le tel que:

"scripts": [
    "node_modules/jquery/dist/jquery.min.js",
    "node_modules/uikit/dist/js/uikit.min.js",
    "node_modules/uikit/dist/js/uikit-icons.min.js"
]

On va aussi ajouter la partie CSS à notre projet:
Modifiez le fichier src/style.css qui doit être vide comme suit:

/* You can add global styles to this file, and also import other style files */
@import "../node_modules/uikit/dist/css/uikit.min.css";
@import "../node_modules/uikit/dist/css/uikit.css";
@import "../node_modules/uikit/dist/css/uikit-core.css";
@import url("https://fonts.googleapis.com/css?family=Staatliches");

a {
  text-decoration: none;
}

h1 {
  font-family: Staatliches;
  font-size: 120px;
}

#category {
  font-family: Staatliches;
  font-weight: 500;
}

#title {
  letter-spacing: 0.4px;
  font-size: 22px;
  font-size: 1.375rem;
  line-height: 1.13636;
}

#banner {
  margin: 20px;
  height: 800px;
}

#editor {
  font-size: 16px;
  font-size: 1rem;
  line-height: 1.75;
}

.uk-navbar-container {
  background: #fff !important;
  font-family: Staatliches;
}

img:hover {
  opacity: 1;
  transition: opacity 0.25s cubic-bezier(0.39, 0.575, 0.565, 1);
}

Nav component

On va créer notre premier composant, la barre de navigation :

ng generate c nav --skip-import

4 fichiers sont ainsi créés, mais on va uniquement travailler avec les fichiers .html and .ts .
Les fichiers .html sont vos templates (la partie visible) et les .ts sont le "moteur" de votre composant, ce qu'il fait, comment il se comporte, etc.

Maintenant, on va modifier notre composant "nav" pour aller chercher les catégories et les afficher en haut à droite de notre barre de navigation.

Ouvrez le fichier nav/nav.component.ts et modifiez votre code comme suit:

import { Component, OnInit } from '@angular/core';
import { Apollo } from "apollo-angular";
import gql from "graphql-tag";

@Component({
  selector: 'app-nav',
  templateUrl: './nav.component.html',
  styleUrls: ['./nav.component.css']
})

export class NavComponent implements OnInit {

  data: any = {};
  loading = true;
  errors: any;

  constructor(private apollo: Apollo) {}

  ngOnInit(): void {
    this.apollo.watchQuery({
        query: gql`
          query Categories {
            categories {
              data {
                id, 
                attributes {
                  name
                }
              }
            }
          }
        `
      })
      .valueChanges.subscribe((result: any) => {
        this.data = result?.data?.categories;
        this.loading = result.loading;
        this.errors = result.error;
      });
  }
}

Ici, on va chercher nos catégories avec Apollo lors de l'initialisation du composant avec une requête graphql.

La variable data va contenir nos catégories.

Maintenant, modifions le template pour les afficher !

Ouvrez nav/nav.component.html et modifiez le code comme suit:

<nav class="uk-navbar-container" uk-navbar>
    <div class="uk-navbar-left">
        <ul class="uk-navbar-nav">
        <li class="uk-active"><a href="#">Strapi blog</a></li>
        </ul>
    </div>

    <div class="uk-navbar-right">
        <ul *ngIf="data" class="uk-navbar-nav">
            <li *ngFor="let category of data.data" class="uk-active">
                <a routerLink="/category/{{ category.id }}" routerLinkActive="active" class="uk-link-reset">
                {{ category.attributes.name }}
                </a>
            </li>
        </ul>
    </div>
</nav>

Dans cette vue, on peut bien accéder à notre variable "data" (qui contient les catégories) et sa variable "data" qui contient le tableau des catégories.
On fait une boucle ngFor dessus pour afficher une à une nos catégories et créer un lien avec.

Note : "data.data" n'est pas très lisible, mais cela est dû à la forme du JSON qui est renvoyé de l'API de Strapi.
Voici un exemple de ce que vous renvoie l'API:

{"data":{"categories":{"data":[{"id":"2","attributes":{"name":"strapi","__typename":"Categorie"},"__typename":"CategorieEntity"},{"id":"3","attributes":{"name":"blog","__typename":"Categorie"},"__typename":"CategorieEntity"}],"__typename":"CategorieEntityResponseCollection"}}}

La variable "data" dans notre .ts contient bien "result" (l'ensemble du résultat), ".data" pour accéder au premier élément "data" du résultat (qui contient alors "categories":{"data":[...]}....
Dans la vue, on est donc obligé de prendre "data.data" pour avoir le tableau.

Encore 2 petites modifications et on est bon.

La première, c'est de déclarer notre module "NavComponent" dans la liste des modules.

Pour cela, modifiez app.modules.ts comme suit:

...
import { NavComponent } from "./nav/nav.component";
...

declarations: [
  AppComponent,
  NavComponent
],
...

On importe simplement le module, et on l'ajoute dans le tableau "declarations".

Enfin, on va modifier notre template de base de l'application pour ajouter notre barre de navigation.

Pour cela, ouvrez le fichier app.component.html, supprimez tout son contenu, et ajoutez simplement le code suivant:

<app-nav></app-nav>
<router-outlet></router-outlet>

Ici, on ajoute notre composant "nav" (la balise " et on laisse le router (balise router-outlet) gérer le reste de la page.

Contemplez le résultat dans votre navigateur :

Mes 2 catégories sont bien Strapi et Blog. Victoire !

Articles component

On va appliquer le même raisonnement à notre 2ème composant, "ArticlesComponent", qui va lister tous les articles.

Création du composant
Modification de la logique du composant dans le .ts
Modification de la vue du composant
Référencement du composant dans la liste des modules
Modification du routage de l'application

Création du composant

A la racine du projet, en ligne de commande, créons notre composant:

ng generate c articles/articles --skip-import

Notez ici que j'ai ajouté "articles/" devant le nom du composant. ça a Pour effet de créer un répertoire englobant pour tous nos futurs composants qui traiteront d'articles (comme le prochain qui affichera un article). Je trouve que c'est une bonne pratique, surtout dans les grosses applications, sinon on s'y perd vite....

Comme pour la barre de navigation, modifiez le .ts du composant src/app/articles/articles/articles.components.ts comme suit:

import { Component, OnInit } from '@angular/core';
import { Apollo } from "apollo-angular";
import gql from "graphql-tag";

@Component({
  selector: 'app-articles',
  templateUrl: './articles.component.html',
  styleUrls: ['./articles.component.css']
})
export class ArticlesComponent implements OnInit {

  data: any = {};
  loading = true;
  errors: any;
  leftArticlesCount: any;
  leftArticles?: any[];
  rightArticles?: any[];

  constructor(private apollo: Apollo) { }

  ngOnInit(): void {
    this.apollo.watchQuery({
      query: gql`
        query Articles {
          articles {
            data {
              id, 
              attributes {
                title, 
                categorie {
                  data {
                    id, 
                    attributes {
                      name
                    }
                  }
                },
                content, 
                image {
                  data {
                    attributes{
                      url
                    }
                  }
                }
              }
            }
          }
        }` 
      })
      .valueChanges.subscribe((result: any) => {
        this.data = result?.data?.articles;
        this.leftArticlesCount = Math.ceil(this.data?.data.length / 5);
        this.leftArticles = this.data?.data.slice(0, this.leftArticlesCount);

        this.rightArticles = this.data?.data.slice(
          this.leftArticlesCount,
          this.data?.data.length
        );
        this.loading = result.loading;
        this.errors = result.error;
      });
  }
}

Ici, pas grand chose de nouveau puisqu'on a le même principe que la barre de navigation:

une requête graphql
un traitement des résultats avec la consitution de 2 tableaux : 1 pour la partie gauche (les grandes images) et 1 pour la partie droite

Modifions maintenant le template associé src/app/articles/articles/articles.component.html :

<div class="uk-section">
    <div class="uk-container uk-container-large">
      <h1>Strapi blog</h1>

      <div class="uk-child-width-1-2" uk-grid>
        <div>
          <a
            routerLink="/article/{{ article.id }}"
            routerLinkActive="active"
            *ngFor="let article of leftArticles"
            class="uk-link-reset"
          >
            <div class="uk-card uk-card-muted">
              <div *ngIf="article.attributes.image" class="uk-card-media-top">
                <img
                  src="http://localhost:1337{{ article.attributes.image.data.attributes.url }}"
                  alt=""
                  height="100"
                />
              </div>
              <div class="uk-card-body">
                <p
                  id="category"
                  *ngIf="article.attributes.categorie"
                  class="uk-text-uppercase"
                >
                  {{ article.attributes.categorie.data.attributes.name }}
                </p>
                <p id="title" class="uk-text-large">{{ article.attributes.title }}</p>
              </div>
            </div>
          </a>
        </div>
        <div>
          <div class="uk-child-width-1-2@m uk-grid-match" uk-grid>
            <a
              routerLink="/article/{{ article.id }}"
              routerLinkActive="active"
              *ngFor="let article of rightArticles"
              class="uk-link-reset"
            >
              <div class="uk-card uk-card-muted">
                <div *ngIf="article.attributes.image" class="uk-card-media-top">
                  <img
                    src="http://localhost:1337{{ article.attributes.image.data.attributes.url }}"
                    alt=""
                    height="100"
                  />
                </div>
                <div class="uk-card-body">
                  <p id="category" *ngIf="article.attributes.categorie" class="uk-text-uppercase">
                    {{ article.attributes.categorie.data.attributes.name }}
                  </p>
                  <p id="title" class="uk-text-large">{{ article.attributes.title }}</p>
                </div>
              </div>
            </a>
          </div>
        </div>
      </div>
    </div>
  </div>

Afin de contruire et retrouver les chemins, vous pouvez vous référer au JSON produit par l'API tel que:

{"data":{"articles":{"data":[{"id":"1","attributes":{"title":"Premier post","categorie":{"data":{"id":"3","attributes":{"name":"blog","__typename":"Categorie"},"__typename":"CategorieEntity"},"__typename":"CategorieEntityResponse"},"content":"Ah enfin ce premier post !\nLe premier d'une longue série ;)\n\nEt puis je vais rappatrier ici tous les articles produits sur d'autres plateformes ;)\n\nA très bientôt !","image":{"data":{"attributes":{"url":"/uploads/wanderlabs_T_Ap9_Hue_Sl_KQ_unsplash_1_5e82873dce.jpg","__typename":"UploadFile"},"__typename":"UploadFileEntity"},"__typename":"UploadFileEntityResponse"},"__typename":"Article"},"__typename":"ArticleEntity"},{"id":"2","attributes":{"title":"Créer un blog avec Strapi","categorie":{"data":{"id":"2","attributes":{"name":"strapi","__typename":"Categorie"},"__typename":"CategorieEntity"},"__typename":"CategorieEntityResponse"},"content":"D'avoir, allez voir la vidéo de Yoandev ;)","image":{"data":{"attributes":{"url":"/uploads/photo_1499750310107_5fef28a66643_ixlib_rb_1_2_2f258ec988.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=870&q=80","__typename":"UploadFile"},"__typename":"UploadFileEntity"},"__typename":"UploadFileEntityResponse"},"__typename":"Article"},"__typename":"ArticleEntity"}],"__typename":"ArticleEntityResponseCollection"}}}

Référençons maintenant notre composant dans les modules.
Pour cela, modifiez app.modules.ts comme suit:

...
import { ArticlesComponent } from "./articles/articles/articles.component"
...

declarations: [
  AppComponent,
  NavComponent,
  ArticlesComponent
],
...

Modifions maintenant le "Router" de notre application, dans le fichier app-routing.module.ts :

...
import { ArticlesComponent } from "./articles/articles/articles.component"

const routes: Routes = [
  { path: "", component: ArticlesComponent }
];
...

On importe notre composant, et on déclare une route.
Ici, on dit que notre ArticlesComponent sera la page d'accueil puisque le "path" est vide.

Constatez le résultat dans votre navigateur:

Article component

On a listé nos articles, mais maintenant, que se passe-t-il si je clique que un article ? rien !

Réglons ce problème en créant un "ArticleComponent" pour afficher un article :

ng generate c articles/article --skip-import

Là encore, j'ajoute "articles/" pour mettre notre composant dans le répertoire des composants "articles".

Encore une fois, commençons par modifier notre partie "comportement" du composant avec son fichier src/app/articles/article/article.component.ts :

import { Component, OnInit } from '@angular/core';
import { Apollo } from "apollo-angular";
import gql from "graphql-tag";
import { ActivatedRoute } from "@angular/router";

@Component({
  selector: 'app-article',
  templateUrl: './article.component.html',
  styleUrls: ['./article.component.css']
})
export class ArticleComponent implements OnInit {

  data: any = {};
  image: any;
  title: any;
  content: any;
  loading = true;
  errors: any;

  constructor(private apollo: Apollo, private route: ActivatedRoute) { }

  ngOnInit(): void {
    this.apollo.watchQuery({
      query: gql`
        query Articles($id: ID!) {
          article(id: $id) {
            data {
              id,
              attributes {
                title, 
                content, 
                categorie {
                  data {
                    id, 
                    attributes {
                      name
                    }
                  }
                },
                image {
                  data {
                    attributes{
                      url
                    }
                  }
                }
              }
            }
          }
        }` 
      ,
      variables: {
        id: this.route.snapshot.paramMap.get("id")
      }
    })
    .valueChanges.subscribe(result => {
      this.data = result.data;
      this.image = this.data?.article.data.attributes.image?.data?.attributes?.url
      this.title = this.data?.article.data.attributes.title
      this.content = this.data?.article.data.attributes.content
      this.loading = result.loading;
      this.errors = result.errors;
    });
  }

}

Puis, modifions notre template src/app/articles/article/article.component.html :

<div id="banner"
  class="uk-height-small uk-flex uk-flex-center uk-flex-middle uk-background-cover uk-light uk-padding"
  [style.background-image]="
    'url(http://localhost:1337' + image + ')'
  "
  uk-img
>
  <h1>{{ title }}</h1>
</div>

<div class="uk-section">
  <div class="uk-container uk-container-small">
    <p>
        {{ content }}
    </p>
    <p></p>
  </div>
</div>

Modifiez aussi app.module.ts pour ajouter le module ArticleComponent.
Puis ajoutez la route suivante dans le fichier app-routing.module.ts

{ path: "articles/:id", component: ArticleComponent }

Vous pouvez maintenant cliquer dans la page d'accueil sur un article pour afficher notre nouvelle page.

Si ça marche bien, il y a un petit soucis dans l'affichage.
En effet, le code html saisi dans Strapi est rendu tel quel.
Dans le backoffice de Strapi, vous saisissez votre contenu riche (le champs "content") en markdown.

L'affichage est donc rendu avec les marqueurs Markdown.
Voici un exemple:

Ici, on voit bien que la phrase "essai de texte riche", que j'ai mis en gras dans Strapi, donc encadré avec 2 étoiles de chaque côté, n'est pas rendu en gras mais avec les marqueurs.

Pour "convertir" le code Markdown en code HTML, on va utiliser une librairie Javascript : ngx-markdown.

Installons et configurons cette librairie:

yarn add ngx-markdown

Ajoutez maintenant le module dans app.modules.ts, dans les imports tel que:

...
import { MarkdownModule } from "ngx-markdown";
...

imports: [
  MarkdownModule.forRoot(),
  RouterModule.forRoot(appRoutes, { enableTracing: true }),
  BrowserModule,
  AppRoutingModule,
  GraphQLModule,
  HttpClientModule
],
...

On va utiliser le plugin pour transformer notre variable "content" du markdown vers du HTML.
Dans article.component.ts ajoutez un import:

...
import { MarkdownService } from 'ngx-markdown';
...

puis modifier dans ngOnInit l'affectation de la variable content:

this.content = this.markdownService.compile(this.data?.article.data.attributes.content)

Maintenant c'est bon !

Categorie component

Il nous reste un dernier composant à construire, celui pour afficher les articles d'une catégorie, celui qui affichera les articles liés à une catégorie (les liens du haut de la barre de navigation).

Créons le :

ng generate c category --skip-import

On fait comme d'habitude, on modifier le fichier de classe src/app/category/category.component.ts tel que:

import { Component, OnInit } from '@angular/core';
import { Apollo } from "apollo-angular";
import gql from "graphql-tag";
import { ActivatedRoute, ParamMap } from "@angular/router";

@Component({
  selector: 'app-category',
  templateUrl: './category.component.html',
  styleUrls: ['./category.component.css']
})
export class CategoryComponent implements OnInit {

  data: any = {};
  category: any = {};
  loading = true;
  errors: any;
  leftArticlesCount: any;
  leftArticles?: any[];
  rightArticles?: any[];
  id: any;
  queryCategorie: any;

  constructor(private apollo: Apollo, private route: ActivatedRoute) { }

  ngOnInit(): void {
    this.route.paramMap.subscribe((params: ParamMap) => {
      this.id = params.get("id");
      this.queryCategorie = this.apollo.watchQuery({
        query: gql`
          query Categorie($id: ID!) {
            categorie(id: $id) {
              data {
                id,
                attributes {
                  name,
                  articles {
                    data {
                      id,
                      attributes {
                        title,
                        content,
                        createdAt,
                        image {
                          data {
                            attributes{
                              url
                            }
                          }
                        }

                      }
                    }
                  }
                }
              }
            }
          }
        ` 
        ,
        variables: {
          id: this.id
        }
      })
      .valueChanges.subscribe(result => {
        this.data = result.data;

        this.category = this.data.categorie.data.attributes.name
        this.leftArticlesCount = Math.ceil(this.data?.categorie.data.attributes.articles.data.length / 5);

        this.leftArticles = this.data?.categorie.data.attributes.articles.data.slice(0, this.leftArticlesCount);
        this.rightArticles = this.data?.categorie.data.attributes.articles.data.slice(
          this.leftArticlesCount,
          this.data?.categorie.data.attributes.articles.data.length
        );

        this.loading = result.loading;
        this.errors = result.errors;
      });
    });  
  }

  ngOnDestroy() {
    this.queryCategorie.unsubscribe();
  }

}

Rien d'exceptionnel ici :

on crée une requête graphql
on lance la requête à la création du composant, et on construit les 2 listes (leftArticles, rightArticles)

Puis, modifions la partie HTML:

<div class="uk-section">
    <div class="uk-container uk-container-large">
      <h1>{{ category }}</h1>

      <div class="uk-child-width-1-2" uk-grid>
        <div>
          <a
            routerLink="/articles/{{ article.id }}"
            routerLinkActive="active"
            *ngFor="let article of leftArticles"
            class="uk-link-reset"
          >
            <div class="uk-card uk-card-muted">
              <div *ngIf="article.attributes.image" class="uk-card-media-top">
                <img
                  src="http://localhost:1337{{ article.attributes.image.data.attributes.url }}"
                  alt=""
                  height="100"
                />
              </div>
              <div class="uk-card-body">
                <p
                  id="category"
                  class="uk-text-uppercase"
                >
                  {{ category }}
                </p>
                <p id="title" class="uk-text-large">{{ article.attributes.title }}</p>
              </div>
            </div>
          </a>
        </div>
        <div>
          <div class="uk-child-width-1-2@m uk-grid-match" uk-grid>
            <a
              routerLink="/articles/{{ article.id }}"
              routerLinkActive="active"
              *ngFor="let article of rightArticles"
              class="uk-link-reset"
            >
              <div class="uk-card uk-card-muted">
                <div *ngIf="article.attributes.image" class="uk-card-media-top">
                  <img
                    src="http://localhost:1337{{ article.attributes.image.data.attributes.url }}"
                    alt=""
                    height="100"
                  />
                </div>
                <div class="uk-card-body">
                  <p
                    id="category"
                    *ngIf="article.category"
                    class="uk-text-uppercase"
                  >
                    {{ article.category.name }}
                  </p>
                  <p id="title" class="uk-text-large">{{ article.title }}</p>
                </div>
              </div>
            </a>
          </div>
        </div>
      </div>
    </div>
  </div>

Référençons maintenant notre composant dans les modules.
Pour cela, modifiez app.modules.ts comme suit:

...
import { ArticlesComponent } from "./articles/articles/articles.component"
...

declarations: [
  AppComponent,
  NavComponent,
  ArticlesComponent,
  ArticleComponent,
  CategoryComponent
],
...

Enfin, ajoutez la route suivante dans le fichier app-routing.module.ts (avec son import)

...
import { ArticleComponent } from "./articles/article/article.component"
...
{ path: "category/:id", component: CategoryComponent }
...

Conclusion

Loin d'être un spécialiste d'Angular, et de GraphQL, on arrive néanmoins à créer un client facilement pour notre API Strapi.

La prise en main de Strapi est en revanche vraiment facile !
Réellement impressionné par la dernière version, vite installé.

Merci à Yoandev pour l'inspiration de cet article.
Retrouvez sa chaine et sa vidéo ici : (https://youtu.be/KGHJYoxlGRE)

CMS en Symfony : le routing

Guillaume — Mon, 28 Feb 2022 23:22:59 +0000

Maintenant qu'on a regardé un peu la partie fonctionnelle, on va faire un peu de technique.

L'une des fonctionnalités à laquelle chaque utilisateur de CMS s'attend à trouver, est la gestion du "routing" : "je crée une page "Actualités" et je m'attends à pouvoir l'afficher si je tape "www.monsupersite.com/actualites".

2 choses à gérer :

pouvoir créer des pages
créer un "slug" pour chaque page
faire en sorte que chaque page soit automatiquement enregistrée dans les routes du CMS pour les rendre disponibles.

On va donc commencer par ... la fin (je laisse la structure des pages pour le prochain épisode !).

Evidemment, notre framework préféré nous donne la possibilité de faire ça en ... 5 minutes chrono !

Routing as a Service.

Quand on utilise Symfony, on a l'habitude d'utiliser:

soit le fichier yaml de routing (basique, mais ça sert parfois, valable aussi en XML ou en PHP)
soit les annotations dans les controller (ou les attributs maintenant, hein les dinosaures ! )

Evidemment, que ce soit l'un ou l'autre, ça ne répond pas à notre besoin : on a besoin de quelque chose de dynamique qui va cherche la liste de nos pages en base de données et qui les "charge".

Hé bien c'est exactement ce que Symfony nous propose !

On appelle ça un "route loader". Pour les curieux (et parce que je vous invite à lire la doc !) c'est ici.

Nous, on a une contrainte supplémentaire : certes, on crée un CMS, mais on veut aussi pouvoir faire du Symfony "natif". En bref, si je veux créer une route "hors CMS", je dois pouvoir le faire.

Qu'à cela ne tienne, on a aussi cette possibilité.

Le fichier de définition des routes

Dans Symfony, le fichier de base pour définir les routes est le fichier "config/routes.yaml".

Par défaut, dans une application Symfony (version 6) il doit ressembler à quelque chose du genre :

controllers:
    resource: ../src/Controller/
    type: annotation

kernel:
    resource: ../src/Kernel.php
    type: annotation

On va ajouter quelques lignes en haut du fichier tel que:

cms_routes:
    resource: .
    type: cms

controllers:
    resource: ../src/Controller/
    type: annotation

kernel:
    resource: ../src/Kernel.php
    type: annotation

On ajoute un nouveau "groupe de routes" tel que:

cms_routes : nom arbitraire. Mettez "toto24" si ça vous fait plaisir ;)
resource: . : en fait on ignore ce paramètre, d'où le point
type: cms : heu c'est pas natif ce type ? Non, c'est pas natif ! C'est là où on intervient : on va aller créer notre loader, responsable de ce type de route.

Let's go.

A votre service :-)

Pour cela dans le répertoire "src" à la racine de votre projet, créez un répertoire "Routing", puis créez dans ce dernier une classe "CmsRouteLoader".

Voici le code:


namespace Routing;

use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\Config\Loader\Loader;
use Symfony\Component\Routing\Route;
use Symfony\Component\Routing\RouteCollection

class CmsRouteLoader extends Loader
{
    private $isLoaded = false;

    /**
     * @var EntityManagerInterface
     */
    private EntityManagerInterface $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {

        $this->entityManager = $entityManager;
    }

    public function load($resource, string $type = null): RouteCollection
    {
        if (true === $this->isLoaded) {
            throw new \RuntimeException('Do not add the "CMS" loader twice');
        }

        $routes = new RouteCollection();

        $nodes = $this->entityManager->getRepository(Page::class)->findAll();
        foreach ($nodes as $node) {
            $defaults = [
                '_controller' => 'App\Controller\CmsController::slugs'
            ];
            $route = new Route($node->getPath(), $defaults);
            $routes->add('cms_slugs_' . $node->getId(), $route);
        }

        $this->isLoaded = true;
        return $routes;
    }

    public function supports($resource, string $type = null)
    {
        return 'cms' === $type;
    }

}

Quelques explications (notez que notre classe ressemble beaucoup à la documentation):

notre classe étend Loader, ce qui va nous permettre de définir une méthode "supports". Vous remarquerez qu'on retourne true si le type du groupe est "cms"....ça vous rappelle le fichier de config ?
ici la classe est un peu simplifiée, mais en bref, on charge les pages de la base, et pour chaque page on crée dynamiquement une route qu'on ajoute à son tour dans une collection de routes qu'on retourne.

Enfin, on enregistre notre service dans les services de l'application en modifiant le fichier config/services.yaml comme suit:

# config/services.yaml
services:
    # ...

    App\Routing\CmsRouteLoader:
        tags: [routing.loader]

On fera quelques modifications dans le prochain chapitre pour mettre en place nos structures pour enregistrer nos pages et autres dans la base de données.

Il manque aussi le controller 'App\Controller\CmsController' mais pour l'instant on insiste pas, on s'y intéressera plus tard.

Bientôt la suite !

CMS en Symfony : quelles fonctionnalités ?

Guillaume — Wed, 23 Feb 2022 22:00:05 +0000

Bon maintenant qu'on a bien critiqué les CMS et leur stack super lourde, on fait comment ?
Et si on devait faire un CMS, comment on ferait ?
On a besoin de quoi pour faire un CMS ?

On va essayer de répondre à ce questions dans ce post....

Faire le tri dans les fonctionnalités

Voici ce que j'ai retenu des (macros) fonctionnalités de Drupal :

mise à disposition d'un backoffice de gestion du site
gestion de l'authentification des contributeurs et administrateurs
pouvoir créer des types de contenu (dans le backoffice)
pouvoir créer des contenus (page, article, ...) (dans le backoffice)
pouvoir gérer des "menus"
pouvoir modifier le template de la page (dans le code)
pouvoir créer des blocs de template (dans le code)
pouvoir créer des vues, transformées soit en bloc, soit en page. Les vues sont une liste de contenus filtrés.
pouvoir "étendre" la plateforme avec des plugins

Ce qu'on garde ou pas

Mise à disposition d'un backoffice de gestion du site

Evidemment on garde. Il faut nécessairement ajouter cette fonctionnalité.

Gestion de l'authentification

Idem, on garde, il faut que nos utilisateurs puisse accéder au backoffice et gérer des droits.

Pouvoir créer des types de contenu

Dans Drupal par exemple, tous les contenus héritent de "Node", le type de base.

Sur le principe, on va garder la possibilité, évidemment, de pouvoir créer des types dérivés d'un type de base.
Mais laisser cette possibilité en backoffice, j'avoue que je ne comprends pas...

Quelle est la probabilité de laisser la possibilité à un client final (un contributeur) de créer des types de contenu à la volée ?
C'est complexe pour le modèle en base, nuit donc aux performances, et parfaitement inutile.

C'est justement ce qui va faire la différence, on va avoir une approche différente.

Mais sur le fond, on fera ça dans le code, vous verrez pourquoi.

Pouvoir créer des contenus

Avoir un backoffice sans pouvoir créer de page ou d'article, ça n'a pas vraiment de sens.
Donc on garde (et on fera même mieux que Drupal ;-) )

Pouvoir gérer des "menus"

Pas grand chose à dire, on garde (et on fera plus simple que Drupal)

Pouvoir modifier le template de la page

Comme dans beaucoup de CMS, on va garder cette fonctionnalité. Mais aussi la laisser possible uniquement dans le code.

Pouvoir créer des blocs de template

Les pages à créer, le contenu à créer, est de plus en plus complexe. Donc on est obligé de proposer des mises en pages qui ne sont pas uniquement rigides.

On va offrir cette possibilité, et elle va même devenir centrale !
Pouvoir créer des pages avec des blocs déjà constitués, pouvoir en créer comme on le veut, y attacher des données, des attributs, on va plutôt aller dans ce sens.

Pouvoir créer des vues

On ne garde pas. Trop complexe. On va faire plus simple et plus performant.

Pouvoir "étendre" la plateforme avec des plugins

Cette fonctionnalité est native dans beaucoup de framework.
Donc il ne sert à rien de réinventer la roue !

On garde ! Mais on fait différent !

Dans le prochain épisode, on verra comment on transforme ces fonctionnalités en brique technique.

Bientôt la suite !

CMS or not CMS ?

Guillaume — Mon, 21 Feb 2022 22:45:38 +0000

Cet article est le début d'une série.

Choix cornélien s'il en est !

Vous voulez créer une plateforme, mais votre client vous demande une partie applicative et une partie contenu... et là c'est le drame.

Disclaimer / Parti pris

Oui je suis architecte et développeur Symfony, donc pas beaucoup de mystère. Mais on sera ici loin de la critique.
L'idée n'est pas de critiquer telle ou telle plateforme, mais essayer d'expliquer pourquoi on arrive parfois à se trouver dans des situations complexes, dont il n'y a pas de réponse évidente.
Et puis il faut toujours considérer des paramètres qui peuvent parfois passer au second plan et qui sont pourtant fondamentaux:

la compétence du ou des développeurs. Si celui ne connait que Drupal (au hasard, mais on va en parler) alors clairement cela peut être le bon choix. Si en revanche c'est un pur développeur Java/Spring, l'effort de prise en main d'un CMS est souvent rédhibitoire;
l'appétence de ceux-ci pour telle ou telle techno. "J'aime pas PHP", "Moi je fais tout sans framework", etc....ne négligez pas ces aspects.
les contraintes du client, ou de l'environnement. Environnement 100% Microsoft, ou au contraire 100% Open Source, "PHP, non j'en veux pas !".... et là vos 10 ans d'expérience sur Wordpress s'envolent !

Une p'tite histoire ?

Avant d'entrer dans le vif du sujet, je vais vous compter 2 histoires.

Cas N°1 : client pressé - compétence 0

Un client (interne dans mon cas mais ça ne change rien) vient me voir et me dis : "Guillaume, il faut refaire le site abc.com et tu as 3 mois". Ouch. Le truc est vieux, pas simple et il faut évidemment refaire design et le reste....
C'est 60/70% de contenu mais il y a un gros morceaux autour de la recherche et je n'y connais rien.
Me lancer dans un CMS ? Je n'ai jamais touché ni un Drupal, ni un Wordpress...
Mais bon, en discutant avec le client, on trouve un designer qui me fais des maquettes aux petits oignons et je leur dis que je me charge des modifications de contenu en attendant.
Je code donc des templates Twig en Symfony et la recherche, de la BDD et un ElasticSearch font l'affaire.
On met le tout en prod, tout le monde est content et finalement le contenu n'a pas beaucoup bougé depuis 1 an.....

Cas n°2 : figure imposée !

Client n°2 : "Guillaume, puisque tu as fais le premier, le 2ème est à refaire, mais là le client c'est Drupal ou rien".
Effctivement, on a beau négocier, rien à faire....je dois me mettre à Drupal. J'écume Youtube et la doc (horrible) de Drupal. 2ème coup de massue : j'arrive à faire 2 pages simples (Hello world je te hais) mais pas beaucoup d'autres trucs.... et de là à faire un truc "pro" il y a 1 (2 !) pas.
J'arrive à négocier un presta, ultra compétent, qui m'explique sans faire à ma place, mais que c'est lourd !

Le truc est une usine à gaz !

Je ne retrouve pas mes repères. C'est à la fois une usine à clics et à la fois un truc dégueu où il faut faire des hooks partout, rajouter des plugins à foison sans trop savoir ce qu'ils font..... expérience de développement horrible !

Donc dilemme pour la suite, maintenant que je sais faire un peu de CMS. Stop ou encore ?

Pourquoi choisir un CMS ?

Alors pourquoi choisir un CMS en 2022 ?
Objectivement, quelques éléments relevés, notamment en discutant avec le client:

on connait la pile logicielle
on a déjà ce CMS sur d'autres sites, on maitrise
le backoffice est déjà fait, on a notre usine à clics
on peut créer du contenu nous-mêmes

Toutes ces raisons sont sûrement valables, mais honnêtement de moins en moins:

la pile logicielle est remplie de plugins non maîtrisés
la retro-compatibilité entre les versions n'est souvent pas assurée
oui le backoffice est déjà présent, mais il contient souvent beaucoup de fonctionnalités dont le client n'a pas besoin
créer proprement un contenu dans un CMS, mis à part un blog, je demande à voir sans être un spécialiste.

En résumé, la "promesse" des CMS de permettre à un utilisateur non développeur de mettre en ligne du contenu n'est JAMAIS tenue.

Pourquoi ne pas choisir un CMS ?

La sécurité ! On ne compte plus les CVE sur Wordpress, ou sur Drupal. Que dire quand en plus on lui ajoute 50 plugins contribs ?
Parce que c'est compliqué ! On passe finalement son temps à casser des comportements natifs du CMS, donc finalement on ...code !
Qui a déjà laissé créer un type de contenu à un utilisateur en prod ? Du coup à quoi ça sert ????

On va y revenir, mais cette approche "type de contenu" est assez paradoxale.

Un headless CMS peut-être ?

Ces dernières années, des tentatives, comme Directus ou Strapi, permettent de créer des types de contenu et des contenus dans un backoffice générique. Sympa, mais du coup, on se retrouve à faire un front office "from scratch".
Là aussi, une approche "data" pure : un contenu = une data d'un type particulier.
C'est bien pour une liste d'articles, mais pas pour bien d'autres chose. Pour des éléments constitués oui, mais sur un site web il n'y a pas que ça !
Ce n'est pas un blog !

Et si on le faisait nous-mêmes ?

Un site web aujourd'hui n'est pas juste une liste d'articles et une page "article". ça c'est un blog !
Et c'est bien le problème !

Nous avons aujourd'hui des pages de plus en plus complexe où il faut gérer des blocs de contenu des complexes mais surtout et souvent non reproductibles.

En conclusion, on va essayer une nouvelle approche.
Garder ce qui fait la force de notre framework web préféré tout en offrant des possibilités de création de contenu.

A suivre !

Dans les prochains épisodes:

exposer le problème
comment faire ça dans Symfony ? la théorie
Développement de bundle : BlockMS

La suite ici

Authentification OpenID Connect avec Symfony (3/3)

Guillaume — Fri, 23 Apr 2021 09:31:53 +0000

Cet article fait partie d'une série d'articles :

Introduction
Mettre en place un serveur OpenID Connect avec Keycloak
Symfony et Keycloak (cet article)

D'abord "rendons à César ce qui appartient à César" : merci à Grafikart pour son excellent article/vidéo sur le sujet d'Oauth/OpenID : "Authentification sociale sur Symfony".

Evidemment, si je fais cet article, c'est qu'il y a une différence! Nous n'utiliserons pas ni Github, ni Google ou autre, mais notre Keycloak, et il y a quelques subtilités qui valent bien un article :D

Création du projet

Note : un projet Symfony 5 est utilisé ici, mais Symfony 4.4 est tout à fait utilisable.

Installez la commande symfony comme expliqué ici.

Puis, créez un projet (ici en version full/application web):



symfony new TestKeycloak --full

Pour avoir une route de test dans notre application, on va créer une simple route /dashboard.

Dans le répertoire de notre projet, créons le controller:



bin/console make:controller DashboardController

On va laisser le controller par défaut, ça n'a aucune importance pour notre exemple.

On va aussi laisser le template dans son état initial.

Configuration de la base de données

Il faut configurer la base de données.
Personnellement, s'agissant d'un projet de test, je fais ça avec docker et docker-compose pour démarrer une base PostgreSQL.

Si vous voulez faire comme moi, créez un fichier docker-compose.yaml à la racine de votre projet avec le contenu suivant:



version: '3'

services:
    database:
        image: postgres:13-alpine
        environment:
            POSTGRES_USER: main
            POSTGRES_PASSWORD: main
            POSTGRES_DB: keycloak
        ports:
            - 5432:5432

Démarrez la base avec un simple :



docker-compose up -d

Configurez ensuite la base dans le projet en créant le fichier .env.local à la racine du projet avec le contenu suivant:



DATABASE_URL="postgresql://main:main@127.0.0.1:5432/keycloak?serverVersion=13&charset=utf8"

Démarrez le serveur interne à Symfony:



symfony serve

Puis rendez-vous dans votre navigateur à l'adresse http://localhost:8000/dashboard

Notre projet initial est en place, voyons pour la partie authentification.

Création d'un utilisateur dans Keycloak

Dans notre cas, nous n'avons pas de fournisseur externe d'identité, comme dans une entreprise, avec un annuaire LDAP ou Active Directory, ou une base de données quelconque.

Mais pas de soucis, on va pouvoir créer dans notre Keycloak des utilisateurs de test.

Pour cela, rendez-vous dans l'administration de votre Keycloak : https://votre_domaine/auth/admin.

Dans le menu Manage/Users cliquez sur le bouton "Add user" et créer un utilisateur comme suit:

Dans les détails de l'utilisateur créé, allez dans l'onglet "Credentials" et saisissez un mot de passe (avec confirmation) puis cliquez sur "Set password"

Note: toutes les manipulations seront faites sur le Realm (Domaine) "Master". Keycloak est complexe, et comporte de multiples fonctionnalités. Lisez la doc ;)

Création d'un client Keycloak

Chaque application "cliente" de Keycloak doit être configurée.
Pour créer un client pour notre application Symfony, allez dans le menu "Clients" dans l'interface d'admin de Keycloak puis sur le bouton "Create".

Ajoutez les informations comme suit:

Rien de difficile ici, on donne un nom à notre client, on utilise le protocole OpenID et l'URL de notre projet est bien http://localhost:8000

Cliquez sur "save" pour passer au panneau de contrôle de notre client.

Modifiez les valeurs suivantes :

Consent Required doit être à ON
Toggle Display client on consent screen doit être à ON
Toggle Implicit Flow Enabled doit être à ON
Set Access Type doit être à confidential

Laissez la valeur "Valid redirect URIs" à http://localhost:8000/* pour le moment, même si à terme il faudra sécuriser les URLs de redirection vers notre application Symfony.

Enregistrez la configuration et basculez sur l'onglet "Credentials".

Copiez le "secret", et insérez 3 variables d'environnement dans le fichier .env.local de votre projet Symfony tel que:



DATABASE_URL="postgresql://main:main@127.0.0.1:5432/keycloak?serverVersion=13&charset=utf8"
KEYCLOAK_SECRET=6b008eb2-e4c8-4afe-8016-cd59f3843d93
KEYCLOAK_CLIENTID=symfony
KEYCLOAK_APP_URL=https://votre_domaine/auth

Attention : mettez bien "/auth" à la fin de l'URL de votre Keycloak.

Passons maintenant à Symfony.

Attention: je reprécise mon besoin : disposer d'une authentification 100% via Keycloak. Si vous voulez AUSSI disposer d'un formulaire de login en plus de Keycloak, c'est possible ! Allez voir la doc officielle de Symfony sur la composant Security

Mais nous on va faire simple ;)

Symfony Security

Le composant Security est un des plus complexes à appréhender. Le composant est complexe, mais il nous facilite grandement la vie, n'oubliez jamais ça ! Combien de fois voyons-nous des applications "faites à la main" et mal/pas sécurisées !

Pas de panique, on va y aller pas à pas.

Création d'une classe User

Nous avons besoin d'une classe "User" pour 2 raisons :

pouvoir enregistrer cet objet en base de données
manipuler un objet tout au long de notre processus d'authentification

Encore une fois, Symfony nous facilite la vie avec une simple commande:



bin/console make:user

Notre classe utilisateur est maintenant créée, avec son repository, mais nous avons besoin d'un champs supplémentaire : keycloakId.
Ce champs nous servira à associer l'utilisateur Keycloak à notre utilisateur local.

Rien ne vous empêche d'ajouter d'autre champs, puisque on le verra plus tard, Keycloak nous envoie des champs comme le nom que je ne stocke pas dans mon exemple.

Pour ajouter ce champs faites un simple :



bin/console make:entity User

Comme conseillé à la fin de l’exécution de la commande, on va créer un fichier de migration :



bin/console make:migration

Puis exécuter cette migration:



bin/console doctrine:migrations:migrate

Vérifiez dans votre base de données que la table "user" s'est bien créée :

Ajout des bundles "clients" pour OAuth et Keycloak

Heureusement pour nous, on ne va pas coder toute la partie cliente entre Symfony et keycloak.
Comme d'habitude avec Symfony, il existe des bundles et aujourd'hui 2 vous nous intéresser particulièrement :

le KnpUOAuth2ClientBundle
le Keycloak Provider

Le premier est une sorte de coquille vide : si vous regardez la doc, vous verrez que comme Grafikart, vous pouvez choisir un client Github, mais aussi Discord, Facebook, et plein d'autres !

Le deuxième est donc notre "Provider", l'implémentation spécifique à Keycloak.

Installons-les :



composer require knpuniversity/oauth2-client-bundle
composer require stevenmaguire/oauth2-keycloak

Oui je sais je fais ça en 2 commandes alors qu'on pourrait faire ça en une ! Pourquoi ? Parce que je n'aime pas installer plusieurs bundles dans la même commande : si l'installation d'un bundle plante c'est plus facile à debugger :-D

L'installation du premier bundle va exécuter une "recipe" (recette) pour aller créer un fichier de configuration spécifique : le fichier "config/packages/knpu_oauth2_client.yaml"

C'est lui qui va nous servir à configurer la connexion à notre Keycloak. Comme nous avons créé des variables d'environnement (dans notre .env.local) ça va être simple :



knpu_oauth2_client:
    clients:
        keycloak:
            type: keycloak
            auth_server_url: '%env(KEYCLOAK_APP_URL)%'
            realm: 'master'
            client_id: '%env(KEYCLOAK_CLIENTID)%'
            client_secret: '%env(KEYCLOAK_SECRET)%'
            redirect_route: 'oauth_check'

Détaillons un peu:

le nom de notre "client" (ici keycloak) est arbitraire;
le type en revanche est imposé ;) et c'est pour préciser l'implémentation à utiliser au 1er bundle;
auth_server_url : l'URL de notre Keycloak
realm : comme dit précédemment, j'utilise le Realm/Domaine de base : "master"
client_id : le nom du client qu'on a créé dans Keycloak
client_secret: le secret généré par Keycloak
redirect_route: le nom de la route à appeler sur laquelle Keycloak redirigera après l'authentification. C'est l'URL de "callback" dans la littérature Keycloak (cf explications de la cinématique Keycloak/Oauth dans le chapitre précédent)

Pas de panique, cette URL/route n'existe pas encore, mais on va la créer après.

Cinématique

Il faut maintenant expliquer comment le processus d'authentification va marcher :

L'utilisateur essaie de se connecter sur l'application Symfony
Le firewall de Symfony détecte qu'il n'est pas loggué et le revoit vers l'URL de login de l'application (/oauth/login).
Le contrôleur Symfony derrière cette URL va "démarrer" le client Keycloak et renvoyer une réponse de redirection à l'utilisateur vers le serveur Keycloak (à partir des informations de la configuration)
L'utilisateur s'authentifie dans Keycloak et il est alors redirigé vers l'URL de callback (transmise en paramètre de la réponse du .3)
Le firewall voit la redirection de l'utilisateur après authentification dans Keycloak, vérifie les informations transmises et si elles sont bonnes, authentifie l'utilisateur.

Maintenant qu'on a compris le fonctionnement, il faut l'implémenter:

configurer la sécurité de Symfony pour aller sur "/oauth/login" si on est pas authentifié (en bref, un firewall)
créer un contrôleur pour implémenter la route "/oauth/login" en redirigeant l'utilisateur
implémenter un firewall pour l'URL de callback

Configurer le firewall pour l'URL de login

Symfony et son composant sécurité a déjà beaucoup de mécanismes fournis, dont des "Provider".
On va donc se servir du form_login Authentication Provider pour rediriger automatiquement l'utilisateur s'il n'est pas authentifié vers notre URL personnalisée.

La configuration se fait dans config/packages/security.yaml

Configurez-le comme suit:



security:
    encoders:
        App\Entity\User:
            algorithm: auto

    providers:
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false
        main:
            anonymous: true
            lazy: true
            form_login:
                login_path: oauth_login

    access_control:
        - { path: ^/dashboard, roles: ROLE_USER }

Quelques explications:

la rubrique "encoders" a été normalement déjà configurée, de même que "providers" par l'utilisation de la commande make:user. On sait donc quelle est la classe utilisée pour "provider" nos utilisateurs, et qu'on utilise, si on stocke des mots de passe dans la base (donc hors spectre Keycloak), qu'ils seront sécurisés.
pour les firewalls, dans le main, ajoutez les lignes "form_login" et "login_path: oauth_login". On déclare donc bien une route avec le nom "oauth_login" comme URL de rediection par défaut si on est pas authentifié.
dans la rubrique "access_control", on a déclaré que toutes les URLs commençant par /dashboard ont nécessité à être protégées par une authentification et que l'utilisateur authentifié doit à minima posséder le rôle "ROLE_USER".

Une fois cette configuration sauvegardée, continuons en implémentons notre route de nom "oauth_login" et d'URL "/oauth/login".

Créez un contrôleur:



bin/console make:controller OAuthController --no-template

Puis implémentez la route dite comme suit:



<?php

namespace App\Controller;

use KnpU\OAuth2ClientBundle\Client\ClientRegistry;
use KnpU\OAuth2ClientBundle\Client\Provider\KeycloakClient;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\Routing\Annotation\Route;

class OAuthController extends AbstractController
{
    /**
     * @Route("/oauth/login", name="oauth_login")
     */
    public function index(ClientRegistry $clientRegistry): RedirectResponse
    {
        /** @var KeycloakClient $client */
        $client = $clientRegistry->getClient('keycloak');
        return $client->redirect();
    }

    /**
     * @Route("/oauth/callback", name="oauth_check")
     */
    public function check()
    {

    }
}

Dans la première fonction, comme expliqué dans la cinématique, on récupère le client Keycloak et on redirige l'utilisateur.

La 2ème fonction est là uniquement pour implémenter l'URL de callback.
Elle est en revanche vide, puisque c'est un autre composant qui va implémenter la logique et "prendre la main".

Ce composant, c'est Symfony Guard, et sa classe abstraite AbstractGuardAuthenticator.
Notre bundle KnpUOAuth2ClientBundle implémente justement une surcouche à ce composant : SocialAuthenticator.

On va donc pouvoir se servir de cette classe abstraite pour implémenter notre firewall de "callback".

Dans le projet, créez un répertoire src/Security et une classe KeycloakAuthenticator telle que :



<?php

namespace App\Security;

use App\Entity\User;
use KnpU\OAuth2ClientBundle\Security\Authenticator\SocialAuthenticator;
use KnpU\OAuth2ClientBundle\Client\ClientRegistry;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\RedirectResponse;

/**
 * Class KeycloakAuthenticator
 */
class KeycloakAuthenticator extends SocialAuthenticator
{

    private $clientRegistry;
    private $em;
    private $router;

    public function __construct(ClientRegistry $clientRegistry, EntityManagerInterface $em, RouterInterface $router)
    {
        $this->clientRegistry = $clientRegistry;
        $this->em = $em;
        $this->router = $router;
    }
 .......

Notre classe étends bien le SocialAuthenticator, et on va avoir besoin de:

ClientRegistry: le gestionnaire de clients OAuth
EntityManagerInterface: pour lire/écrire dans la base de données
RouterInterface: lire une route/URL

On les injecte dans le constructeur via l'injection de dépendances. Donc pas de configuration particulière à faire dans services.yaml.

Etendre le SocialAuthenticator nous oblige à implémenter un certain nombre de méthodes que voici:

start: méthode appelée en cas d'erreur si l'authentification n'est pas envoyée dans la requête Pour nous : ```

public function start(Request $request, \Symfony\Component\Security\Core\Exception\AuthenticationException $authException = null)
{
return new RedirectResponse(
'/oauth/login', // might be the site, where users choose their oauth provider
Response::HTTP_TEMPORARY_REDIRECT
);
}


* supports: méthode appelée sur toutes les requêtes pour savoir si on déclenche cet Authenticator ou pas.
Pour nous:

public function supports(Request $request)
{
return $request->attributes->get('_route') === 'oauth_check';
}


* getCredentials: détermine comment on récupère les informations d'authentification dans la requête pour les passer en paramètre de la fonction *getUser*
Pour nous:

public function getCredentials(Request $request)
{
return $this->fetchAccessToken($this->getKeycloakClient());
}


* getUser : c'est LA fonction de l'authenticator : comment récupérer l'utilisateur. Ici, on a 3 possibilités :
    - soit l'utilisateur existe et s'est déjà connecté avec Keycloak
    - soit l'utilisateur existe dans la base mais ne s'est jamais connecté avec Keycloak
    - soit l'utilisateur n'existe pas du tout et on le crée

Ainsi:

public function getUser($credentials, \Symfony\Component\Security\Core\User\UserProviderInterface $userProvider)
{
$keycloakUser = $this->getKeycloakClient()->fetchUserFromToken($credentials);
//existing user ?
$existingUser = $this
->em
->getRepository(User::class)
->findOneBy(['keycloakId' => $keycloakUser->getId()]);
if ($existingUser) {
return $existingUser;
}
// if user exist but never connected with keycloak
$email = $keycloakUser->getEmail();
/** @var User $userInDatabase */
$userInDatabase = $this->em->getRepository(User::class)
->findOneBy(['email' => $email]);
if($userInDatabase) {
$userInDatabase->setKeycloakId($keycloakUser->getId());
$this->em->persist($userInDatabase);
$this->em->flush();
return $userInDatabase;
}
//user not exist in database
$user = new User();
$user->setKeycloakId($keycloakUser->getId());
$user->setEmail($keycloakUser->getEmail());
$user->setRoles(['ROLE_USER']);
$this->em->persist($user);
$this->em->flush();
return $user;
}


* onAuthenticationFailure: message renvoyé quand l'authentification échoue
Pour nous:

public function onAuthenticationFailure(Request $request, \Symfony\Component\Security\Core\Exception\AuthenticationException $exception)
{
$message = strtr($exception->getMessageKey(), $exception->getMessageData());

    return new Response($message, Response::HTTP_FORBIDDEN);
}


* onAuthenticationSuccess: que se passe-t-il après l'authentification ? Ici on redirige vers la page /dashboard
Pour nous:

public function onAuthenticationSuccess(Request $request, \Symfony\Component\Security\Core\Authentication\Token\TokenInterface $token, string $providerKey)
{
// change "app_homepage" to some route in your app
$targetUrl = $this->router->generate('dashboard');

    return new RedirectResponse($targetUrl);
}

Et une fonction de récupération du client à partir du clientRegistry injecté dans le constructeur:

/**
* @return \KnpU\OAuth2ClientBundle\Client\Provider\KeycloakClient
*/
private function getKeycloakClient()
{
return $this->clientRegistry->getClient('keycloak');
}


Voilà ! Notre Authenticator est maintenant créé.
Pour l'utiliser, modifions encore notre fichier de configuration de la sécurité (config/packages/security.yaml):

![utilisation du Guard](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3wkfkkbek34vic5crsx8.png)

Et voilà ! Testons maintenant !

Démarrons notre serveur Symfony:

symfony serve

Puis ouvrez votre navigateur à l'adresse [http://localhost:8000/dashboard](http://localhost:8000/dashboard).

Vous êtes automatique redirigé sur le serveur Keycloak:
![login keycloak](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6w8o5s4fyubdp9thghvz.png)

Puis Keycloak vous demande votre consentement sur les données partagées avec l'application Symfony:
![Consentement](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kg7gku24vf2b6dki9ivv.png)

Après consentement, on revient bien sur notre page dashboard ....AUTHENTIFIE !

![YEEEESSS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eqfy80qlxavpx52by49z.png)

Voilà un petit aperçu des possibilités de Keycloak et de son intégration avec Symfony.

Des questions ? Des remarques ? N'hésitez pas !

Authentification OpenID Connect avec Symfony (2/3)

Guillaume — Tue, 20 Apr 2021 11:03:55 +0000

Cet article fait partie d'une série d'articles :

Introduction

Mettre en place un serveur OpenID Connect avec Keycloak (cet article)

Symfony et Keycloak

Après cette (longue) introduction, on va enfin rentrer dans le vif du sujet.
Aujourd'hui c'est Keycloak!
On va l'installer en mode "standalone", avec une base Mysql (ou MariaDB, suivant votre choix).
On mettra enfin un serveur Apache devant, configuré en SSL et en reverse proxy.

Vous êtes prêts ? C'est parti !

Notes: Comme dit précédemment, Keycloak sera installé sur une VM. On va imaginer un serveur sur le domaine "gbtux.org".

Installation de Keycloak

Connectez-vous à votre VM, en root, et allez dans le répertoire /opt.

Installation de Java

Keycloak nécessite Java pour fonctionner.
On va donc l'installer.
Mettez donc votre liste de paquets à jour :

apt-get update

Puis installez le JDK:

apt install default-jdk -y

Contrôlez la bonne exécution de Java via :

java -version

Téléchargement

Téléchargez le sources de keycloak avec wget :

wget https://github.com/keycloak/keycloak/releases/download/12.0.4/keycloak-12.0.4.tar.gz

Puis, décompressez l'archive avec :

tar zxvf keycloak-12.0.4.tar.gz

Vous avez maintenant un répertoire /opt/keycloak-12.0.4

Création d'un utilisateur

Pour faire ça bien, on va créer un utilisateur et un groupe associé.

groupadd keycloak
useradd -r -g keycloak -d /opt/keycloak -s /sbin/nologin keycloak

Changement des permissions sur le répertoire Keycloak

$ sudo chown -R keycloak: keycloak
$ sudo chmod o+x /opt/keycloak/bin/

Keycloak en tant que service (avec System D)

Fichier de config

D'abord, on va créer un répertoire qui va accueillir notre fichier de configuration

mkdir /etc/keycloak

Puis on va copier le fichier contenu dans la distribution de keycloak.

cp /opt/keycloak-12.0.4/docs/contrib/scripts/systemd/wildfly.conf keycloak.conf

Pas besoin de l'adapter, on va laisser les valeurs par défaut (fichier de configuration XML, mode et adresse d'écoute)

Script de démarrage

De la même façon, on va se servir d'un fichier de la distribution de Keycloak:

cd /opt/keycloak-12.0.4/bin
cp ../docs/contrib/scripts/systemd/launch.sh .

Editez le nouveau fichier pour modifier la variable WILDFLY_HOME comme suit :

Fichier de service

Maintenant qu'on s'est occupé du fichier de configuration et du script de démarrage, mettons tout cela en musique pour pouvoir démarrer Keycloak comme un véritable service.

Pour cela, encore une fois, la distribution de Keycloak nous fournit tout ce qu'il faut.

cp /opt/keycloak-12.0.4/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/keycloak.service

Maintenant, éditez le fichier copié (/etc/systemd/system/keycloak.service) et adaptez-le comme suit:

Tout est maintenant en place pour prendre les modifications en compte par systemd:

systemctl daemon-reload
systemctl enable keycloak

et lancer notre nouveau service

systemctl start keycloak

Contrôlez son démarrage avec un simple:

systemctl status keycloak

Contrôlez aussi l'accès à l'interface d'admin de Keycloak à l'adresse http://<nom_machine_public_de_la_vm:8080/auth/ (dans notre exemple : http://gbtux.org:8080/auth/)

Keycloak en SSL

Pour mettre notre serveur Keycloak en SSL (httpS ;) ), il nous faut un certificat.
On va utiliser certbot, l'outil de Let's Encrypt qui permet de créer des certificats automatiquement.

Installons-le :

apt install certbot

Puis créons notre certificat :

Attention: certbot a besoin du port 80 pour fonctionner. Or, notre serveur Apache tourne sur ce port. Arrêtez-le temporairement avec un simple systemctl stop apache2

certbot certonly --standalone -d gbtux.org

Vous pouvez constater que certbot a créé toute une arborescence dans /etc/letsencrypt, et notamment un répertoire /etc/letsencrypt/live/.

On va aussi utiliser tous ces fichiers *.pem dans notre configuration Apache.

Maintenant que nous avons notre certificat, on va l'importer dans le keystore (littéralement magasin de clés) de Keycloak.

Allons dans le répertoire de configuration où se trouve notre keystore:

cd /opt/keycloak-12.0.4/standalone/configuration

Dans ce répertoire se trouve un fichier application.keystore.

Importons notre certificat (évidemment, remplacez tous les "gbtux.org" par votre nom de domaine):

openssl pkcs12 -export -inkey /etc/letsencrypt/live/gbtux.org/privkey.pem -in /etc/letsencrypt/live/gbtux.org/fullchain.pem -out application.keystore -name gbtux.org

RETENEZ BIEN LE MOT DE PASSE QUE VOUS ALLEZ CREER !

Vérifions l'import (le mot de passe demandé est évidemment celui que vous venez de créer):

keytool -list -v -keystore application.keystore

Configurons Keycloak pour utiliser ce nouveau certificat ajouté dans le keystore.
Dans le même répertoire, éditez le fichier standalone.xml.

Repérez l'entrée "security-realms" puis celle concernat "ApplicationRealm" (aux alentours de la ligne 46) et modifiez les valeurs de configuration tel que:

Redémarrez Keycloak pour prendre en compte la configuration

systemctl restart keycloak
systemctl status keycloak

Et admirez le résultat ;) : https://votre_domaine:8443/auth/

Créer un utilisateur d'admin

Maintenant qu'on a accès à la console, créez un utilisateur d'admin/

Placez-vous dans le répertoire bin de Keycloak:

cd /opt/keycloak-12.0.4/bin

Puis créez votre utilisateur (et redémarrez Keycloak):

./add-user-keycloak.sh -r master -u <username> -p <password>
systemctl restart keycloak

Cliquez sur le lien "Administration Console" sur la page d'accueil de votre Keycloak, et testez votre login !

Apache

Maintenant que notre Keycloak marche en SSL, on va mettre un serveur Apache devant en reverse proxy. Pourquoi me direz-vous ? ben ...parce que c'est mieux de ne pas directement exposer son serveur d'application.
La bonne pratique c'est bien de mettre un Apache en frontal qui relaie les requêtes externes vers un serveur d'application qui lui n'écoute que sur une adresse "locale". Cela vous permettrais de filtrer l'accès à la partie admin de Keycloak par exemple

Notez qu'ici je vous fais faire les 2 (port 443 via Apache, port 8443 en direct) pour éviter de complexifier la configuration. Pour faire ça bien, il faut modifier le fichier de configuration de Keycloak (/etc/keycloak/keycloak.conf et changer le paramètre WILDFLY_BIND pour 127.0.0.1). Ainsi, le Keycloak n'est plus accessible que via Apache (i.e le port 8443 n'est plus accessible depuis une IP publique).

Installation

Installons Apache HTTPD:

apt install apache2

Activer les modules nécessaires

Pour faire un reverse proxy, Apache a besoin de quelques modules activés

a2enmod proxy proxy_http ssl headers

Pour les prendre en compte, redémarrez Apache:

systemctl restart apache2

Création d'un VirtualHost

On va créer un VirtualHost dédié à notre Keycloak, pour y mettre un reverse proxy.

Créez un fichier de configuration dans la configuration Apache :

/etc/apache2/sites-available/keycloak.conf

Puis déclarons notre configuration à l'intérieur:

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>

        ErrorLog ${APACHE_LOG_DIR}/keycloak-error.log
        CustomLog ${APACHE_LOG_DIR}/keycloak-access.log combined

        SSLEngine on
        SSLCertificateFile  /etc/letsencrypt/live/gbtux.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/gbtux.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/gbtux.org/chain.pem

        ProxyPreserveHost On
            SSLProxyEngine On
            SSLProxyCheckPeerCN on
            SSLProxyCheckPeerExpire on
            RequestHeader set X-Forwarded-Proto "https"
            RequestHeader set X-Forwarded-Port "443"
            ProxyPass / https://127.0.0.1:8443/
            ProxyPassReverse / https://127.0.0.1:8443/
    </VirtualHost>
</IfModule>

Activez maintenant ce nouveau VirtualHost :

systemctl restart apache2

Puis testez si ça marche dans votre navigateur à l'adresse https://votre_domaine/auth/
(https://gbtux.org/auth/ pour mon exemple).

Conclusion

Une grosse étape a été franchie. Notre serveur d'authentification est installé et configuré proprement.

Dans le prochain épisode, on fait du Symfony !

Authentification OpenID Connect avec Symfony (1/3)

Guillaume — Sun, 18 Apr 2021 14:47:52 +0000

Cet article fait partie d'une série d'articles :

Introduction (cet article)

Mettre en place un serveur OpenID Connect avec Keycloak

Symfony et Keycloak

Introduction

Après pas mal de recherches sur le sujet et quelques mises en place avec d'autres framework (Node au hasard), on va aujourd'hui s'attaquer à un sujet à la fois simple fonctionnellement mais plus complexe techniquement : "Comment mettre en place un SSO (Single-Sign-On) dans mes applications Symfony ?".

On ne va pas se mentir. Rentrer 20 mots de passe différents pour chaque application de son SI, c'est acceptable pour des applications "publiques" sur Internet, mais pas en entreprise où on a envie de fluidité, surtout sur un réseau "fermé".

Certains l'ont bien compris, comme Google, avec une authentification unique quelle que soit l'application utilisée dans l'univers Google.

Pourquoi OpenID Connect et pas une autre méthode ?
Parce que c'est celle utilisée par de nombreux acteurs (Github, Twitter, Google, ....), et qu'en quelques années c'est devenu le standard de fait.

Elle offre beaucoup d'avantages, dont celui d'être exclusivement basée sur le protocole HTTP.

Quelles briques techniques ?

On a seulement 2 briques ici:

une brique Symfony, notre application à sécuriser ("fournisseur de service" pour OpenID)
une brique "serveur SSO". On va voir que cette brique est en fait 3 briques fonctionnelles, résumées souvent à une seule brique technique.

Je vous recommande l'excellent guide de l'ANSSI. LISEZ-LE !

Mais voici en gros comment ça marche ;)

Comme expliqué précédemment, nos 2 briques vont discuter ensemble pour authentifier un utilisateur.

Mais en fait la brique "d'authentification" a 3 rôles :

fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, etc.....
Authentification: Demander à l'utilisateur de s'authentifier par un moyen X (login/mot de passe dans une base de données, un LDAP/AD, mais aussi via son token Kerberos, etc....)
Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ?

Nous allons utiliser Keycloak, de Redhat (open source).
C'est là-aussi un des standards du marché. Il réunit bien les 3 rôles de la brique SSO, et peut marcher dans différentes configurations.

S'agissant d'une brique centrale d'un système d'information, il ne faut pas faire n'importe quoi. Certes la redonder, mais aussi la mettre dans 2 datacenter différents. Keycloak vous offre ainsi plusieurs "Operating Mode" (cf la doc).

Pas de panique, nous on va faire simple :

une VM qui hébergera Keycloak (avec un Apache devant, on y reviendra), en mode "standalone"
une machine de développement pour l'application Symfony.

Et c'est tout !

Heu, rappelle-moi déjà comment ça marche OpenID Connect ?

C'est simple ! (ou pas)

L'utilisateur ouvre son navigateur et appelle l'URL de l'application.
L'application regarde la requête et constate qu'elle n'est pas une requête authentifiée.
Pas de panique, l'application renvoie une requête de redirection (HTTP 302) vers le serveur SSO (avec quelques informations en plus, dont l'URL de redirection, un "client_id", etc...)
le navigateur de l'utilisateur, voyant la réponse de l'application (redirection), ouvre l'URL renvoyée, celle du serveur SSO.
Le serveur SSO (Keycloak) présente alors une fenêtre de login à l'utilisateur (cas le plus commun)
Après la saisie du login/mot de passe par l'utilisateur, le SSO va vérifier si l'utilisateur existe, si les login/mdp sont bons, si l'utilisateur a les droits d'appeler l'application, et enfin renvoyer à son tour une requête de redirection (HTTP 302), agrémentée évidemment des informations de l'utilisateur demandées (le "scope").
Après cette 2ème requête de redirection, le navigateur appelle une 2ème fois l'application, mais cette fois-ci avec un "token" lui permettant de s'authentifer.

Et voilà, c'est aussi "simple" que cela :-D

L'aventure vous tente, alors rendez-vous dans les prochains épisodes ! On va parler technique !