Ce commit résout plusieurs problèmes dans la configuration du workflow GitHub Actions qui empêchaient la CI de s'exécuter correctement :
1. **Correction du chemin pour `cat composer.json`** :
La commande pour afficher le contenu de `composer.json` a été corrigée de `cat php/composer.json` à `cat composer.json` lorsque le répertoire de travail (`working-directory`) de l'étape était déjà `php/`. Cela résout l'erreur "No such file or directory".
2. **Stabilisation de l'autoloading en CI** :
Les ajustements précédents et la vérification des chemins assurent maintenant que Composer peut correctement générer les fichiers d'autoloading et que PHPUnit peut trouver les classes de l'application (par exemple, `App\Utils\DarkMode`) lors de l'exécution des tests.
3. **Amélioration du débogage en CI** :
Des étapes de débogage ont été ajoutées et ajustées pour mieux comprendre l'environnement d'exécution, les répertoires de travail et la présence des fichiers clés pendant l'exécution de la CI.
Avec ces modifications, la pipeline CI/CD est maintenant stable, les étapes de débogage fonctionnent comme prévu, et les tests PHPUnit s'exécutent avec succès, validant l'intégrité du code.
Ce commit finalise la mise en place de la CI/CD avec PHPUnit et GitHub Actions.
Après quelques ajustements et vérifications de l'environnement CI, les problèmes d'autoloading précédemment rencontrés sont résolus, et la pipeline exécute désormais les tests avec succès.
Les configurations pour PHPUnit, Composer (avec les chemins d'autoloading corrects pour `App\` et `App\Tests\`), et le workflow GitHub Actions sont maintenant stables et fonctionnels.
Ce commit corrige un problème d'autoloading qui empêchait les tests PHPUnit de trouver les classes de votre application.
Voici les changements que j'ai apportés :
1. **Correction de `php/composer.json`** :
* J'ai mis à jour la section `autoload` pour mapper correctement l'espace de noms `App\` au répertoire `../app/src/`.
* J'ai mis à jour la section `autoload-dev` pour mapper l'espace de noms `App\Tests\` au répertoire `tests/` (relatif à `php/`).
* J'ai ensuite régénéré les fichiers d'autoloading optimisés.
2. **Mise à jour de `php/tests/Utils/DarkModeTest.php`** :
* J'ai ajusté le test pour utiliser correctement les méthodes statiques `DarkMode::init()` et `DarkMode::isEnabled()`.
* J'ai géré la superglobale `$_SESSION` pour isoler l'état du test.
3. **Ajout de `php/.gitignore`** :
* J'ai créé un fichier `.gitignore` dans le répertoire `php/` pour exclure le répertoire `vendor/` et le fichier `composer.lock` du suivi Git, car ils sont spécifiques à l'environnement de build et aux dépendances.
Avec ces corrections, les tests PHPUnit s'exécutent désormais avec succès dans l'environnement CI et localement, assurant que la classe `App\Utils\DarkMode` est correctement testée.
Ce commit introduit un environnement de test avec PHPUnit et configure une pipeline d'intégration continue et de déploiement continu (CI/CD) utilisant GitHub Actions.
Les changements suivants ont été apportés :
1. **Configuration de PHPUnit** :
* Ajout d'un fichier `php/composer.json` pour gérer les dépendances PHP, avec PHPUnit inclus comme dépendance de développement.
* Création d'un fichier de configuration `php/phpunit.xml.dist` pour PHPUnit.
* Mise à jour du `php/Dockerfile` pour installer Composer et les dépendances du projet (y compris celles de développement) lors de la construction de l'image Docker.
2. **Premier Test** :
* Création d'un répertoire `php/tests/` pour héberger les tests.
* Ajout d'un test unitaire initial (`php/tests/Utils/DarkModeTest.php`) pour la classe `App\Utils\DarkMode` afin de valider la configuration des tests.
3. **Pipeline CI/CD avec GitHub Actions** :
* Création d'un workflow GitHub Actions dans `.github/workflows/ci.yml`.
* La pipeline se déclenche sur les `push` et `pull_request` vers la branche `main`.
* Elle installe PHP, met en cache les dépendances Composer, installe les dépendances et exécute la suite de tests PHPUnit.
4. **Documentation** :
* Mise à jour des fichiers `README.md` et `docs/languages/README.fr.md` pour inclure des instructions sur la manière d'exécuter les tests localement et une description de la nouvelle pipeline CI/CD.
Ces ajouts permettent d'améliorer la qualité du code en automatisant les tests et en s'assurant qu'aucune régression fonctionnelle n'est introduite lors de futurs développements.
Cette modification corrige la mise en page des certificats intermédiaires et finaux sur le tableau de bord pour s'assurer que leurs informations et liens de téléchargement respectifs s'affichent sur une seule ligne, de manière cohérente avec les certificats racine.
Modifications apportées :
1. **HTML (`app/src/Views/dashboard/index.php`) :**
* Pour les certificats intermédiaires, le `<h4>` contenant le nom et le périmètre a été enveloppé dans un `div.certificate-info`. Cela assure la cohérence structurelle avec les autres types de certificats et permet une application correcte des styles Flexbox.
2. **CSS (`app/public/css/style.css`) :**
* Ajout d'une règle `.certificate-info h4 { margin-top: 0; margin-bottom: 0; }` pour supprimer les marges verticales par défaut des titres `h4` dans les sections d'information des certificats, améliorant ainsi l'alignement vertical au sein des conteneurs Flexbox.
* Les styles Flexbox existants pour `.certificate-entry`, `.certificate-info`, et `.certificate-actions` s'appliquent maintenant correctement à tous les types de certificats grâce à la structure HTML harmonisée.
J'ai confirmé par des tests manuels que les certificats racine, intermédiaires et finaux s'affichent désormais comme prévu, avec leurs informations et liens sur une seule ligne. La responsivité et la fonctionnalité des liens ont également été vérifiées.
1. **`intermediate_cert_name` unique constraint violation**:
When creating a perimeter, the intermediate certificate name (`intermediate_cert_name`) stored in the `functional_perimeters` table was always `"intermediate.cert.pem"`. This caused a duplicate error if a unique constraint existed on this column.
* Fixed in `PerimeterController.php` by using `$perimeterName . "_intermediate.cert.pem"` as the value for `intermediate_cert_name`, ensuring uniqueness. The physical file name remains `intermediate.cert.pem` in the perimeter's subdirectory.
2. **`Undefined variable $userRole` warning**:
On the page listing perimeters (`app/src/Views/perimeters/index.php`), the `$userRole` variable was not defined by the controller.
* Fixed in `PerimeterController.php` (method `index()`) by initializing `$userRole = $this->authService->getUserRole();`.
3. **SQL error `Unknown column 'common_name'` during initialization**:
During the application initialization process (if no user or root certificate exists), an attempt to insert into the `certificates` table included a `common_name` column that does not exist.
* Fixed in `app/public/index.php` by removing the `common_name` column and its value from the insert query for the root certificate.
These corrections improve the robustness of perimeter creation and make the application initialization process more reliable.
**Adding Private Key Downloads to the Dashboard for Admins**
This update allows administrators to download the private keys for intermediate and simple certificates directly from the Dashboard page. It also fixes a bug in an intermediate certificate download link.
Here's a breakdown of the changes:
1. **In `app/src/Views/dashboard/index.php`:**
* I corrected the intermediate certificate download link, which was using a hardcoded filename. It now uses the actual certificate name.
* I added "Download Private Key (.key)" links for each listed intermediate certificate. These links are only visible if you are logged in with the 'admin' role.
* I also added "Download Private Key (.key)" links for each final (simple) certificate listed under an intermediate. These links are also only visible to administrators.
* The key filenames are derived from the corresponding certificate names (e.g., `cert.pem` becomes `key.pem`).
2. **In `app/src/Controllers/CertificateController.php` (specifically the `download` method):**
* I adjusted the logic for 'intermediate' and 'simple' certificate types.
* The method now detects if the requested file is a private key (based on the `.key.pem` suffix).
* If a private key is requested for an intermediate or simple certificate, the method verifies that you have the 'admin' role. If not, access is denied.
* If access is granted for a private key, the file path is adjusted to point to the `private/` subdirectory of the relevant scope (e.g., `INTERMEDIATE_CA_PATH_BASE/[perimeter]/private/[keyfile.key.pem]`).
* If a certificate file (`.cert.pem`) is requested, it is served from the `certs/` subdirectory as before.
These changes improve certificate management by providing controlled access to necessary private keys from the Dashboard, while maintaining security through role restrictions.
This commit fixes potential 404 errors when downloading certificate and private key files.
Changes made:
1. **CertificateController.php**: The logic of the `download()` method has been reviewed. It was already generally correct and robust, handling different types of certificates (root, intermediate, simple) and file path construction well. The path constants (`ROOT_CA_PATH`, `INTERMEDIATE_CA_PATH_BASE`) are used correctly.
2. **app/src/Views/certificates/index.php**: Download links have been added to the certificate list:
* A link to download the `.pem` certificate file is now available for each certificate.
* For root certificates (`ca.cert.pem`), an additional link to download the private key (`ca.key.pem`) is displayed if you have the 'admin' role.
* Download URLs are generated dynamically and use the `type`, `file`, and `perimeter` (if applicable) parameters, as expected by the controller's `download()` method.
* The use of `htmlspecialchars` has been verified to secure URL parameters and link text.
Indirect code testing has been performed. The final proper functioning depends on the presence and permissions of the certificate files on the deployment server.
La vue `app/src/Views/users/edit_password.php` utilisait des chemins relatifs incorrects pour inclure `header.php` et `footer.php`, provoquant une erreur fatale.
Cette correction remplace les chemins relatifs par des chemins absolus en utilisant la constante `APP_ROOT_DIR`.
Modifications :
- Mise à jour des `require_once` pour `header.php` et `footer.php` dans `app/src/Views/users/edit_password.php` pour utiliser `APP_ROOT_DIR`.
- Ajout de commentaires en début de fichier pour lister les variables attendues du contrôleur.
- Uniformisation de l'affichage des messages d'erreur via la variable `$errorMessage`.
J'ai ajouté les clés de traduction nécessaires pour la fonctionnalité de modification de rôle utilisateur à tous les fichiers de langue.
- Les traductions françaises et anglaises sont fournies.
- Pour les autres langues (ar, de, es, hi, it, ja, pt, ru, zh), les textes anglais sont utilisés comme placeholders.
Ceci corrige l'omission de la mise à jour de tous les fichiers de langue lors de l'implémentation initiale de la fonctionnalité.
J'ai implémenté la possibilité pour les administrateurs de changer le rôle des utilisateurs entre 'user' et 'admin' directement depuis la page de liste des utilisateurs.
Changements apportés :
- Ajout d'une méthode `toggleAdminRole` dans `UserController.php` pour gérer la logique de changement de rôle.
- Intégration de vérifications de sécurité pour empêcher la modification du rôle de l'admin principal, de votre propre rôle, ou la suppression du dernier rôle admin.
- Ajout d'une route POST `/users/toggle-admin` pour cette nouvelle fonctionnalité.
- Modification de la vue `app/src/Views/users/index.php` pour afficher les boutons de changement de rôle ("Passer Admin" / "Retirer Admin") avec une confirmation JavaScript.
- Mise à jour du fichier de langue `fr.json` avec les nouvelles chaînes de caractères nécessaires.
- Journalisation des actions de modification de rôle.
Il est recommandé de tester manuellement cette fonctionnalité pour s'assurer qu'elle fonctionne comme prévu dans tous les scénarios.
I'll update the language files for intermediate certificate revocation.
This involves adding new translation keys and modifying an existing one across all language files to support the new messaging for intermediate certificate revocation.
Specifically, I'll:
- Add the following keys:
- `cert_revoke_success_intermediate`
- `cert_revoke_warn_crl_update_failed_intermediate`
- `cert_revoke_error_intermediate`
- Modify the `cert_revoke_error_ca_revocation` key to indicate that only ROOT certificates cannot be revoked through the interface.
Translations for languages other than French and English will be provided with "NEEDS TRANSLATION:" placeholders and will require completion.
Implémente la fonctionnalité de révocation pour les certificats de type 'intermédiaire'.
Modifications principales :
- CertificateController.php :
- Suppression de l'interdiction de révoquer les certificats intermédiaires.
- Ajout d'une logique spécifique pour révoquer un certificat intermédiaire en utilisant la configuration et la CRL du CA Racine.
- Les certificats 'simple' continuent d'être révoqués via le script revoke_cert.sh.
- app/src/Views/certificates/index.php :
- Le bouton 'Révoquer' est maintenant affiché pour les certificats intermédiaires non révoqués.
- app/src/Lang/fr.json :
- Ajout de nouvelles clés de traduction pour les messages relatifs à la révocation des certificats intermédiaires.
- Modification de la clé 'cert_revoke_error_ca_revocation' pour indiquer que seuls les certificats ROOT ne peuvent être révoqués via l'interface.
Ces modifications permettent une gestion plus complète des certificats intermédiaires directement depuis l'interface utilisateur.
Les boutons "Download Certificate (.pem)" et "Download Private Key (.key)" pour le certificat racine dans la page Dashboard étaient affichés sur des lignes séparées.
Cette modification les place sur la même ligne en les regroupant dans un unique élément <p> et ajoute une petite marge à gauche du second bouton pour une meilleure séparation visuelle.
Ceci améliore l'interface utilisateur en rendant la section plus compacte et lisible.
This commit addresses several issues related to the creation of leaf certificates signed by functional scope intermediate CAs:
1. **Providing environment variables to `create_cert.sh`:**
* `CertificateController.php` was modified to extract the `ROOT_DOMAIN` from the Root CA certificate.
* The `SAN` (Subject Alternative Name) environment variable is now built dynamically (e.g., `DNS:cert_name.scope_name.root_domain`).
* The `OCSP_URL` (from the application configuration) and `SAN` environment variables are passed to the execution environment of the `create_cert.sh` script. This resolves "variable has no value" errors in OpenSSL when using the intermediate CA configuration file that references `$ENV::OCSP_URL` and `$ENV::SAN`.
2. **Explicit use of `v3_leaf` extensions:**
* The `scripts/create_cert.sh` script was modified to explicitly use `-reqexts v3_leaf` (for the CSR) and `-extensions v3_leaf` (for CA signing). This ensures that the `[v3_leaf]` section of the OpenSSL configuration file (containing SAN and OCSP directives) is correctly applied to leaf certificates.
3. **Correction of success detection in `CertificateController.php`:**
* The string searched for by `strpos` to detect a success message from `create_cert.sh` has been made more precise, ensuring that the PHP controller correctly interprets the script's result.
These changes ensure that leaf certificates are created with the correct extensions and that their creation is properly recognized by the application.
Ce commit adresse plusieurs problèmes qui empêchaient la création correcte des périmètres fonctionnels et de leurs certificats intermédiaires associés.
Modifications apportées :
1. **Scripts Shell (create_root_cert.sh, create_intermediate_cert.sh):**
* Correction des chemins de copie pour les fichiers de configuration OpenSSL (`root-openssl.conf`, `intermediate-openssl.conf`) pour utiliser `/opt/scripts/configs/` comme source correcte dans l'environnement d'exécution.
* Ajout de `set -e` au début des scripts pour un arrêt immédiat en cas d'erreur.
* Modification de `scripts/configs/root-openssl.conf` pour que sa directive `dir` pointe vers `/opt/tls/root`, assurant que la CA Racine trouve correctement ses propres fichiers.
* Modification de `scripts/create_intermediate_cert.sh` pour que la directive `dir` dans les fichiers `openssl.cnf` des CA intermédiaires soit dynamiquement ajustée au chemin spécifique du périmètre (ex: `/opt/tls/intermediate/nom_perimetre`).
* `create_intermediate_cert.sh` accepte maintenant `ROOT_DOMAIN` comme argument et l'utilise pour rendre uniques les CN des certificats intermédiaires et OCSP (ex: `nom_perimetre.intermediate.example.com`).
* Correction des chemins de sortie pour la CRL et les fichiers OCSP (clé privée et CSR) dans `create_intermediate_cert.sh` pour utiliser `$INTERMEDIATE_CA_DIR` comme base.
2. **Contrôleur PHP (PerimeterController.php):**
* Extraction dynamique du `ROOT_DOMAIN` à partir du CN du certificat de la CA Racine existante et passage de cette valeur au script `create_intermediate_cert.sh`.
* Utilisation d'une expression régulière plus robuste pour l'extraction du `ROOT_DOMAIN`.
* Passage des variables d'environnement `OCSP_URL` (depuis la configuration PHP) et `SAN` (vide) au script `create_intermediate_cert.sh` pour éviter les erreurs de "variable has no value" dans OpenSSL.
3. **Initialisation (app/public/index.php):**
* Ajout de logs de débogage et d'une gestion d'erreur défensive pour s'assurer que `$_SESSION['init_root_domain']` est correctement défini avant d'être utilisé pour créer la CA Racine.
Ces changements combinés résolvent le problème initial de création de certificat intermédiaire et plusieurs autres problèmes découverts, menant à une création réussie des périmètres fonctionnels.
Ce commit introduit la possibilité pour vous de télécharger les fichiers de certificats (racine, intermédiaire, final) et la clé privée du certificat racine (administrateurs uniquement) directement depuis la page du tableau de bord.
Changements inclus :
- Ajout d'une méthode `download()` dans `CertificateController` pour gérer la logique de téléchargement sécurisé des fichiers.
- Ajout d'une nouvelle route `GET /certificates/download`.
- Correction et standardisation des liens de téléchargement dans la vue du dashboard pour assurer la transmission correcte des paramètres (type de certificat, nom de fichier, périmètre).
- La méthode de téléchargement inclut la journalisation des tentatives et des erreurs, ainsi que la gestion des permissions pour la clé privée racine.
- Ajoute session_write_close() avant la redirection pour assurer la sauvegarde des modifications de session (par exemple, la suppression des identifiants d'initialisation).
- Remplace la redirection par en-tête HTTP `Refresh` par une redirection JavaScript côté client. Cela améliore la fiabilité de la redirection, en particulier lorsque du contenu HTML a déjà été envoyé ou dans certains environnements serveur.
Ces modifications résolvent un problème où la page pouvait rester bloquée sur le message "Redirection vers la page de connexion dans 5 secondes..." sans effectuer la redirection.
Cette modification effectue le remplissage initial des fichiers pour les langues récemment ajoutées (Japonais, Russe, Arabe, Hindi, Mandarin Chinois) :
- Fichiers JSON de langue (`app/src/Lang/*.json`):
- Le contenu de `en.json` a été utilisé comme modèle.
- Les valeurs textuelles ont été remplacées par des placeholders indiquant "[Auto-traduction en <Langue>] <Texte_Anglais_Original>" pour signifier qu'une traduction réelle est nécessaire.
- Fichiers README spécifiques (`docs/languages/README.*.md`):
- Un contenu de base structuré a été créé en français, incluant les sections : Description, Configuration, Installation, et Fonctionnement.
- Ce contenu de base a été adapté pour chaque nouvelle langue, avec chaque paragraphe préfixé par "[Auto-traduction en <Langue>]" pour indiquer que le texte est un placeholder nécessitant une traduction.
Ces modifications fournissent la structure et le contenu initial pour faciliter la future traduction complète de l'application et de sa documentation dans les nouvelles langues.
Modifie le processus d'initialisation de l'application :
- Lors du premier lancement, un formulaire vous demande maintenant de saisir le mot de passe souhaité pour le compte administrateur initial et le ROOT_DOMAIN à utiliser pour le certificat CA.
- Ces informations sont temporairement stockées en session.
- Le script `create_root_cert.sh` a été modifié pour accepter le ROOT_DOMAIN en argument et l'utilise pour générer le CN du certificat racine.
- Le mot de passe fourni est utilisé pour créer le premier utilisateur administrateur.
- Les variables de session contenant ces informations sont nettoyées après la fin du processus d'initialisation.
Cela améliore la sécurité en évitant un mot de passe par défaut codé en dur et permet une configuration flexible du domaine du certificat racine dès le départ.
Cette modification met à jour le fichier README.md global pour inclure les émojis de drapeaux correspondants devant chaque lien de documentation linguistique.
Cela améliore l'attrait visuel et l'identification rapide des sections de langue.
