fabmob / mob Goto Github PK

Il serait probablement utile de préciser les valeurs par défaut des variables d'env, pour guider un utilisateur dans la configuration.

En particulier sur les variables qui portent un nom différent, mais qui contiennent la même valeur.
Par exemple: CLIENT_SECRET_KEY_KEYCLOAK_API et IDP_API_CLIENT_SECRET
Ou: API_FQDN et PATH_API
Ou: IDP_DB_SERVICE_USER et DB_USER
Ou: IDP_DB_SERVICE_PASSWORD et DB_PASSWORD
(de même pour mongo user & password ?)

De même sur les variables qui dépendent les unes des autres, ou sont exclusives
Par exemple: IDP_FQDN et IDP_URL

De même sur les variables ou il n'est pas suggéré de changer la configuration.
Par exemple, la variable MONGO_AUTH_SOURCE doit rester à "admin"

Lorsqu'un utilisateur est connecté, les aides sont triées en fonction de son code postal.

Le code postal et le nom de la ville sont modifiables par l'utilisateur dans son profil. Ces deux informations sont utilisées pour récupérer le code INSEE de la commune, du département et de la région. L'api geo.api.gouv.fr est utilisée.

Première remarque: Si le nom de la ville contient une erreur, le code postal n'est pas suffisant pour résoudre le code INSEE, les aides de l'utilisateur ne seront donc pas triés. Par exemple: curl 'https://geo.api.gouv.fr/communes?nom=Paaris&codePostal=75005' ne retourne pas de réponse.

Seconde remarque: on dirait que pour certaines communes, le processus échoue, et les aides pertinentes ne sont pas triées: elles sont affichées dans le même ordre que si l'utilisateur n'était pas connecté. Et ce alors que l'api geo.api.gouv.fr donne une réponse satisfaisante.

Pour reproduire, voici des cas fonctionnels, les données de ville et code postal sont éditables dans le profil utilisateur:
Ville: Paris, Code postal: 75018, Réponse api: correcte, Tri des aides: correct
Ville: Montpellier, Code postal: 34172, Réponse api: correcte, Tri des aides: correct

Et des cas non fonctionnels:
Ville: La Rochelle, Code postal: 17000, Réponse api: En fonction de la gestion de l'espace, Tri des aides: pas de tri
Ville: Rochelle, Code postal: 17000, Réponse api: correcte, Tri des aides: pas de tri
Ville: Lille, Code postal: 59000, Réponse api: correcte, Tri des aides: pas de tri
Ville: Verlinghem, Code postal: 59237, Réponse api: correcte, Tri des aides: pas de tri

Tous ces cas ont des aides dans le système en production qui devraient correspondre.

Je me suis demandé s'il y avait un problème de conflit entre commune et département. Mais le cas de Montpellier affiche bien les différents types d'aides (agglomération, de commune, département).

Pour référence, voici le code qui appelle l'api geo.api.gouv.fr:

Sans debug, difficile d'identifier la source du problème. Mais il est probable que cela touche une partie importante du territoire.

Lors de l'appel du point d'API /timestamps, l'ensemble des horodatages d'une souscription est retourné.

Dans le parcours CEE, cette réponse contient un minium de 3 horodatages, mais peut en contenir plus en fonction du nombre de patch.

Lorsque le nombre devient grand, il devient complexe d'identifier à quelle étape un horodatage correspond, et lequel est le plus récent (même si la date d'horodatage et son contenu sont accessibles dans la réponse).

Une proposition simple consiste à ajouter un champ "Type de patch" à l'incentive via react admin, en le laissant optionnel.

S'il est rempli, il est ajouté à la souscription de la même manière que l'identifiant du trajet ou l'ah, et de fait horodaté.

Par exemple, pour une souscription

{
    "incentiveTitle":"OPERATOR - Coup de pouce CEE Covoiturage longue distance",
    [...]
    "status":"BROUILLON",
    "specificFields":{
        "Numéro de permis de conduire":"960891200957",
        "Type de trajet":["Court"]
    }
}

Un patch pourrait contenir

{
    "Identifiant du trajet": "/7nr2er63y1iybnn7zu",
    "Date de départ du trajet": "2023-01-30",
    "Type de patch": "id trajet" // <- Nouvelle ligne
}

La souscription mise à jour

{
    "incentiveTitle":"OPERATOR - Coup de pouce CEE Covoiturage longue distance",
    [...]
    "status":"BROUILLON",
    "specificFields":{
        "Numéro de permis de conduire":"960891200957",
        "Type de trajet":["Court"],
        "Identifiant du trajet": "/7nr2er63y1iybnn7zu",
        "Date de départ du trajet": "2023-01-30",
        "Type de patch": "id trajet"
    }
}

Le même contenu est horodatée.

Le patch suivant contient aussi une maj avec "Type de patch": "ah" par exemple. Le contenu est écrasé, mais l'horodatage précédent n'est pas affecté.

Cette solution pose cependant des problèmes:

• Lors du /verify, ou le champ "Type de patch" n'est pas mis à jour, donc sa valeur sera la même dans les deux derniers horodatages, empêchant la différenciation
• Un partenaire qui retente un patch sur l'attestation sur l'honneur, par exemple, continuera à priori de remplir "ah" dans le champ "Type de patch", empêchant la différenciation entre deux patchs sur la même étape.

Une solution plus complète est donc à envisager.

Contexte, suggéré par un partenaire opérateur

Pour certains dossiers, on reçoit des statuts REJETEE alors que le problème vient d'un problème technique côté RPC.
On reçoit ce genre de messages d'erreur de MOB :

• RPCCEEDemandeInvalide: Client network socket disconnected before secure TLS connection was established

• RPC - create proof call failed. Details: feign.RetryableException: Remote host terminated the handshake executing POST https://api.covoiturage.beta.gouv.fr/v3/journeys

Ce sont des problèmes technique lors des appels RPC que l'on commence à bien connaître parce qu'il revienne souvent en ce moment.
Le souci c'est qu'on reçoive un statut REJETEE. Pourquoi rejeter le dossier et plutôt ne pas renvoyer un statut PENDING.

Ce genre de problème pourrait être prévenu en renvoyant le status PENDING pour indiquer que le cas du dossier est toujours en cours d'analyse.

Opérations d'implémentation

• Vérifier l'usage actuel du status PENDING (validation manuelle?), et l'effet de l'utiliser ici
• Vérifier si les cas d'erreur "réseau" peuvent être groupés via un élément clé, comme un status HTTP
• Lister l'ensemble des messages d'erreur des souscriptions REJETEE passées, afin de créer un filtre

Voici une méthode pour configurer le fichier overlays/realms/mcm-realm.json avant ajout à Keycloack.

Cette méthode suppose que l'ensemble des variables d'environnement nécessaires sont alloués dans un fichier .env

set -a
. .env
set +a
envsubst < mcm-realm.json >> mcm-realm-configured.json

De plus, pour les installations n'utilisant pas le connecteur France Connect, un certain nombre de lignes sont à retirer.

• Retirer franceconnect-particulier dans identityProviders
• Retirer les configurations correspondantes dans identityProviderMappers

Le retrait de ces configurations permet l'utilisation du fichier mcm-realm.json sans l'installation de la librairie Keycloak-FranceConnect

Ce fichier est utilisé pour faire le lien entre l'interface d'administration et Keycloak.

Il est indispensable au bon fonctionnement, mais la commande yarn build ne l'inclut pas par défaut dans le dossier build.

La documentation ne contient pas d'informations sur l'installation du thème Keycloak fourni dans ce dossier.

Deux fichiers nécessitent une configuration: email/theme.properties et login/theme.properties
Attention, il est important de s'assurer du contenu de ces fichiers avant l’ajout dans l’interface Keycloak. Le chargement de ces fichiers ayant un impact profond dans le système, les modifications futures nécessitent de récréer les conteneurs Keycloak et Postgre.

Une fois les fichiers theme.properties modifiés, l'installation se fait via la commande suivante:

sudo docker cp mcm_template keycloak:/opt/jboss/keycloak/themes/mcm_template

Le template peut ensuite être sélection via l'interface graphique

La documentation ne contient pas de précisions pour ce cas d'usage.

Voici quelques astuces:

• Les certificats générés par let's encrypt doivent être montés en volume lors du lancement du conteneur
• Les droits d'accès des certificats ne sont pas suffisants après génération
• Le conteneur Keycloak utilise le port 8443 comme point d'entrée en HTTPS.

En pratique, après génération des certificats via let's encrypt, les certificats atterissent dans le dossier:
/etc/letsencrypt/live/<DOMAIN>/

Pour la suite des exemples, remplacer <DOMAIN> par le nom de domaine.

Création d'un dossier contenant une copie (obligatoire) des certificats à monter en volume

mkdir certs

Copie et renommage des certificats vers le dossier

sudo cp /etc/letsencrypt/live/<DOMAIN>/privkey.pem certs/tls.key
sudo cp /etc/letsencrypt/live/<DOMAIN>/fullchain.pem certs/tls.crt

Changement des droits d'accès aux certificats

chmod 755 certs/
chmod 604 certs/*

Lancement du conteneur Keycloak avec une configuration adaptée à HTTPS

sudo docker run -d --link postgres-mcm --name keycloak -p 9000:8443 -e KEYCLOAK_USER=${USER} -e KEYCLOAK_PASSWORD=${PASSWORD} -e DB_VENDOR=postgres -e DB_ADDR=postgres-mcm -e DB_PORT=5432 -e DB_DATABASE=idp_db -e DB_SCHEMA=idp_db -e DB_USER=${DB_USER} -e DB_PASSWORD=${DB_PASSWORD} -v certs/tls.crt:/etc/x509/https/tls.crt -v certs/tls.key:/etc/x509/https/tls.key jboss/keycloak:16.1.1

La documentation ne contient pas l'étape de création d'un compte administrateur fonctionnel, utilisé pour se connecter à l'interface d'administration

L'opération de création s'effectue dans l'interface d'administration de Keycloak:

1. Menu Users
2. Add User
3. Préciser username
4. Cocher la case email_verified
5. Ajouter l'utilisateur au groupe /admins
6. Lui affecter un mot de passe

Ce projet github est-il toujours maintenu ? (pas d'activité depuis 3 mois)
Sinon, le code est-il disponible ailleurs ?
Merci de votre aide.

La documentation README.md présente dans le service website contient un certain nombre d'imprécisions:

Netlify-cms

1. La description d'utilisation de netlify-cms est fortement lacunaire
2. Une intégration avec Gitlab est sous entendue mais pas décrite, est-ce obligatoire ?
3. Le fichier config.yml.with-variables est mentionné mais n'existe pas dans le dépot

Installation en local

1. L'installation de nvm ne nécessite pas le passage en root
2. La version v14.17.6 de node est incompatible avec l'un des modules: error [email protected]: The engine "node" is incompatible with this module. Expected version ">=14.18". Got "14.17.6" La version v14.18.3 semble plus pertinente
3. Il n'est pas nécessaire de redémarrer ubuntu après l'utilisation d'nvm
4. Le tutoriel étant aussi valide pour debian, il n'est pas limité à ubuntu
5. Il manque l'étape d'installation: npm install -g yarn
6. L'installation de gatsby nécessite de préciser sa version : npm install [email protected] -g la dernière version de gatsby n'étant pas compatible avec node v14
7. La variable d'environnement PATH_API est nécessaire mais manquante dans la liste des variables
8. Dans le fichier keycloak.json, il n'est pas évident que le champ clientId doit contenir platform (le nom du client configuré automatiquement dans Keycloak)
9. Le fichier src/environnement.ts contient des variables à modifier, ce qui n'est pas précisé dans la documentation.
10. La raison d'installation de la libraire libpng-dev n'est pas clair.

L'ajout de DISABLE_ESLINT_PLUGIN=true dans le fichier d'environnement .env permet d'opt-out de l'utilisation d'eslint, ce qui "résout" le problème.