Restreint local-sign-in derrière des tokens par fournisseur (DP-1855) - #1693
#1693Open
jbfeldis wants to merge 2 commits into
developetalab/data_pass:developfrom
feature/dp-1855-security-restreindre-local-sign-in-sur-stagingetalab/data_pass:feature/dp-1855-security-restreindre-local-sign-in-sur-stagingCopy head branch name to clipboard
Open
Restreint local-sign-in derrière des tokens par fournisseur (DP-1855)#1693jbfeldis wants to merge 2 commits intodevelopetalab/data_pass:developfrom feature/dp-1855-security-restreindre-local-sign-in-sur-stagingetalab/data_pass:feature/dp-1855-security-restreindre-local-sign-in-sur-stagingCopy head branch name to clipboard
jbfeldis wants to merge 2 commits into
developetalab/data_pass:developfrom
feature/dp-1855-security-restreindre-local-sign-in-sur-stagingetalab/data_pass:feature/dp-1855-security-restreindre-local-sign-in-sur-stagingCopy head branch name to clipboard
Conversation
Protège l'endpoint local-sign-in contre les abus (incident DP-1848) sur les environnements où des tokens sont configurés dans les credentials (staging, sandbox) ; production inchangée (route absente), dev/test ouverts par défaut. - Tokens = dictionnaire nommé par fournisseur de données (`local_sign_in_tokens`), révocables individuellement ; n'importe quel token valide déverrouille. - Sans token valide : 404 (mimique la prod). Token validé en temps constant (secure_compare) puis mémorisé dans un cookie signé (30 j). - Journalise le fournisseur utilisé (+ email, IP) sur les envs protégés. - Panneau « Connexion rapide » masqué tant que l'environnement n'est pas déverrouillé. Logique de décision isolée dans LocalSignInPolicy (PORO testé unitairement) ; glue HTTP dans le concern LocalSignInProtection.
…ironnements sensibles (DP-1855)
jbfeldis
force-pushed
the
feature/dp-1855-security-restreindre-local-sign-in-sur-staging
branch
from
July 17, 2026 14:28
6ac316c to
3140be2
Compare
jbfeldis
marked this pull request as ready for review
July 19, 2026 16:10
Member
|
(@JeSuisUnCaillou je t'ai request vu que JB m'avait demandé de repasser dessus imo il devait pensé que j'étais le seul sur le pont) |
JeSuisUnCaillou
left a comment
Collaborator
There was a problem hiding this comment.
Il reste un problème selon moi : Toute personne local-signed-in en tant qu'admin peut aller retirer des droits à des FD qui ont des tokens pour l'API Datapass en staging sur leurs comptes nominatif.
Plus quelques commentaires 👇
Comment on lines
+146
to
+148
| N’importe quel token valide déverrouille l’accès ; le fournisseur utilisé est journalisé | ||
| (`[local-sign-in] accès via le token « <fd> » — email=… ip=…`). Le token est ensuite mémorisé dans un | ||
| cookie signé (30 jours) : une fois fourni une première fois, les liens suivants fonctionnent sans le |
Collaborator
There was a problem hiding this comment.
Je mettrai pas d'expiration pour se faciliter la vie, mais ça se discute
| #### Protection par token (staging & sandbox) | ||
|
|
||
| Sur **staging** et **sandbox**, `local-sign-in` est protégé par un token secret (défense contre les abus, | ||
| cf. DP-1855). Il faut ajouter `&token=<secret>` à l’URL. Les tokens vivent dans les credentials chiffrées de |
Collaborator
There was a problem hiding this comment.
Pour faciliter l'utilisation par les partenaires, faudrait mettre un input pour renseigner le token dans l'UI, plutôt que leur faire faire une manip d'url. Ou une alert avec input, quoi.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte
Réponse à l'incident DP-1848 (abus sur staging : créations en masse et tentatives
d'injection via le compte démo, entrées par
local-sign-in).Ce que fait la PR
local-sign-inest protégé par un token secret sur les environnements où des tokenssont configurés dans les credentials (staging + sandbox).
(
local_sign_in_tokens: { dgfip: …, api_entreprise: … }) : chaque FD a le sien,révocable individuellement. N'importe quel token valide déverrouille.
[local-sign-in] accès via le token « <fd> » — email=… ip=…), uniquement sur les environnements protégés — brique de traçabilitélégère (prépare DP-1857).
404(mimique la production, muet pour un scanner).?token=…, validé en temps constant (secure_compare), puis mémorisédans un cookie signé (30 j) : les accès suivants n'ont plus besoin du token.
tokens aux credentials de l'environnement.
Une seule règle hors-prod : la protection s'active dès qu'au moins un token existe dans les
credentials — aucun code à toucher pour couvrir un nouvel environnement ou ajouter un FD.
Implémentation
LocalSignInPolicy(PORO) : décision pure +matched_provider, testé unitairement.LocalSignInProtection(concern) : lecture params/cookie, pose du cookie, log,head :not_found.Tests
spec/services/local_sign_in_policy_spec.rb— matrice tokens × cookie +matched_provider+ cas prod.spec/requests/local_sign_in_spec.rb— bout-en-bout HTTP + aller-retour cookie + log FD + panneau masqué.