Site vitrine / backoffice de API Entreprise et API Particulier

Requirements

• ruby 3.3.6
• redis-server >= 6
• postgresql >= 9
• Node.js >= 6 pour mjml

Install

Sans Docker

Il suffit de lancer la commande suivante pour configurer la base de données, installer les paquets et importer les tables de la base de données :

./bin/install.sh

Avec Docker

Installer Docker et docker-compose (sur Mac tout est ici)

Pour installer l'application :

make install

Pour lancer l'application :

make start

L'application doit être lancée pour exécuter les autres commandes.

Pour arrêter:

make stop

En cas de problème, pour réinstaller la base de données:

make reinstall_database

Tests

Pour faire tourner les tests, un navigateur headless est necessaire (au moins sous linux).

sudo apt install chromium-browser

Il faut lancer:

bin/rspec

Guard est aussi installé:

guard

Prévisualisation des mails

Une fois le serveur local lancé, vous pouvez prévisualiser les mails à cette adresse

Static security

brakeman est installé. Vous pouvez l'utiliser en lançant la commande suivante:

./bin/brakeman

Développement

Vous pouvez importer des données afin d'avoir un site qui ne soit pas vide:

rails db:seed:replant

En local et sandbox, la connexion s'effectue sur auth-test.api.gouv.fr qui est remplie de données de fixtures (disponible ici)

Les comptes suivants sont disponibles :

• user@yopmail.com / user@yopmail.com -> utilisateur normal

Sans Docker

Pour lancer le server:

./bin/local.sh

# Pour load le fichier OpenAPI local:
LOAD_LOCAL_OPEN_API_DEFINITIONS=true ./bin/local.sh

Vous pouvez accéder ensuite accéder au site via les adresses suivantes:

# Pour visualiser le site d'API Entreprise
http://entreprise.api.localtest.me:5000/
# Pour visualiser le site d'API Particulier
http://particulier.api.localtest.me:5000/

Avec Docker

Pour lancer le server:

docker-compose up

Vous pouvez accéder ensuite accéder au site via le'adresse suivante:

# Pour visualiser le site d'API Entreprise
http://entreprise.api.localtest.me:5000/
# Pour visualiser le site d'API Particulier
http://particulier.api.localtest.me:5000/

(API Entreprise) Stub des requêtes SIADE en developpement

Pour la page /profile/attestations, en développement on appelle le staging de SIADE avec un stub du token de test, ceci pour simplifier les démos / intervenir sur l'interface plus facilement.

Le résultat de la recherche est donc toujours le même (et constitué des fausses données renvoyées par le staging).

Déploiements

./bin/deploy [env] [branch]

env est par défaut à production, et accepte uniquement sandbox, staging et production branch est pris en compte uniquement si env est sandbox

Ajout de credentials via rails:credentials

Avant toute chose, lisez la partie sur la gestion des credentials chiffré dans la doc officielle de Rails

Chaque environnement possède son propre fichier de credentials.

Pour les environments de tests et developments, le fichier de développment est un lien symbolique sur le fichier de test : modifier l'un modifie l'autre, et la clé est présente dans le dépôt. Il ne faut mettre aucune donnée sensible dans ce fichier.

Pour les fichiers de production (i.e. sandbox, staging et production), il y a aussi plusieurs fichiers. Les clés ne sont pas versionnées, il faut les importer depuis le vault d'ansible du dépôt stockant l'ensemble des secrets.

Vous pouvez executer le script scripts/import_master_keys.sh pour effectuer l'import.

Pour rappel, la commande d'édition:

rails credentials:edit

Premier déploiement

Après le premier déploiement sur une machine : la BDD est vide, les administrateurs n'existent pas, aucun rôle, etc

RAILS_ENV=staging bundle exec rake db_seed:scopes

Paramètres d'environnements

Les fichiers suivants ne sont pas déployés par mina. Ils contiennent des variables d'environnements qui doivent être déployées au préalable par Ansible sur les machines de production.

• config/database.yml
• config/credentials/sandbox.key
• config/credentials/staging.key
• config/credentials/production.key
• config/environments/rails_env.rb
• config/initializers/cors.rb

Documentation métier

Ci-dessous les diverses rubriques principalement à destination des métiers / produits pour itérer sur le site (que ce soit en terme de contenu ou fonctionnel)

• Gestion des webhooks DataPass
• Blog posts
• Design (CSS and stuff)
• Technique
  • Utilisation des modals avec Turbo
  • Utilisation d'Algolia
• Contenu
  • Gestion des wordings (layouts, templates, FAQ)
  • Ajout d'un nouvel endpoint dans le catalogue
  • Proposer des modifications de la doc

Les mails transactionnels

Les templates de mails transactionnels sont disponibles ici :

API Entreprise :

• Mails de demande d'accès : ./api_entreprise/authorization_request_mailer
• Mail de prolongement des jetons : ./api_entreprise/token_mailer
• Mails de transfert d'habilitation : ./api_entreprise/user_mailer

API Particulier :

• Mails de demande d'accès : ./api_particulier/authorization_request_mailer
• Mail de prolongement des jetons : ./api_particulier/token_mailer
• Mails de transfert d'habilitation : En attente

Une grande partie des contenus écrits est ici : ./config/locales/mailers.fr.yml

Outils de production

Il y a plusieurs scripts utiles pour faire des manipulations en production pour des usages bien précis.

Ils sont rangés dans lib/tasks/. À ce jour il y en a 2 :

• user:transfer_account : afin de transférer un compte entre deux emails
• token:blacklist : afin de blacklister un jeton qui aurait été envoyé par email et en créer un nouveau

Les tâches ont des descriptions visible avec bundle exec rake -D user:transfer_account par exemple.

Exemple de commande :

# les backslash '\' sont malheureusement nécessaire sinon ils sont interprété par ZSH
# il ne faut pas mettre d'espace après la virgule entre les variables qui sont entre crochets
bundle exec rake user:transfer_account\['current@user.com','new@user.com'\]

Génération des sitemaps

On utilise 2 sitemaps différents pour le site d'API Entreprise et le site d'API Particulier. Pour générer les sitemaps il suffit d'executer la commande :

rake sitemap:refresh

Lors de l'éxecution de la commande, un ping auto sera envoyé à google afin d'indiquer que le sitemaps a changé. En local, afin de ne pas solliciter google inutilement il est préférable de ne pas déclencher le ping

rake sitemap:refresh:no_ping