Serve the EAJE attestation proof via the X-Generate-Proof header - #296
Open
Un3x wants to merge 6 commits into
Open
Serve the EAJE attestation proof via the X-Generate-Proof header#296Un3x wants to merge 6 commits into
Un3x wants to merge 6 commits into
Conversation
Un3x
force-pushed
the
feature/api-6792-ajout-dun-pdf-signe
branch
3 times, most recently
from
July 24, 2026 13:59
2212cb8 to
68df22d
Compare
Contributor
Author
|
Itération 3 : rendu PDF conforme à la maquette (retour de test sandbox du 27/07, détail sur API-6792). |
Un3x
force-pushed
the
feature/api-6792-ajout-dun-pdf-signe
branch
from
July 27, 2026 14:51
813c7f9 to
5e6c16a
Compare
Un3x
force-pushed
the
feature/api-6792-ajout-dun-pdf-signe
branch
from
July 28, 2026 06:38
dff89f5 to
20d62d0
Compare
Contributor
Author
|
Historique replié pour la review : les 8 commits itératifs d'hier tiennent en 2 (arbre final inchangé, diff strictement identique). |
Contributor
Author
|
Il y a probablement des choses à redire, c'est néanmonis testé et validé en fonctionnement en sandbox. L'app y est déployé actuellement, vous pouvez faire des requêtes curl récup l'attestation et scanner le QR code pour récup la vérification. A priori, besoin d'aucune modification en staging ni de fake data on génère un vrai pdf sur de la fausse données et c'est ok, facile à tracé parce que ca ne répond à nos mocks qui sont tracable. |
Member
|
Est-ce que tu peux upload un pdf directement ici, ainsi que le curl ? |
Member
|
La description fonctionnelle de cette PR est incompréhensible, peux-tu clarifier ? |
skelz0r
requested changes
Jul 28, 2026
skelz0r
left a comment
skelz0r
left a comment
Member
There was a problem hiding this comment.
J'ai plusieurs gros points:
- C'est beaucoup trop couplé entre le type de données et le pdf (2 coms) tout en étant très générique ;
- La spec a complètement divergé (ajout d'un header qui permet d'avoir un lien de vérif et/ou un pdf, dans la même réponse sans ajouter de nouvel endpoint) : pourquoi ? Le design me semble plus pauvre que la spec initiale, d'autant plus qu'on complexifie pas mal de choses en procédant de cette manière. Le but n'est pas de produire un nouveau type de réponse mais de la preuve, je trouve ça très étrange de l'exposer dans un endpoint de données (à la limite via une extension aurait été plus logique mais bon..)
- Les commits messages sont cryptiques, cela devrait être autoportant
Le 2. m'a excessivement brainfuck, pourquoi ? Cela devrait être dans le commentaire initial de la PR.
Member
|
Btw j'ai lu commit / commit, et je me suis arrêté quand j'ai constaté le point 2. |
Contributor
Author
pour le moment je n'ai testé que en sandbox avec des données réelles donc non, mais je peux générer un fake en local pour illustrer |
Un3x
changed the title
Contributor
Author
|
Deploy prerequisite: provision |
Un3x
force-pushed
the
feature/api-6792-ajout-dun-pdf-signe
branch
from
July 29, 2026 13:06
ca5f327 to
ec56f71
Compare
Two purposes on one dedicated key pair (attestation_encryptor_*) provisioned in both siade and the site app: a 5-year verification token holding the RSSI §4.4 minimum — allocataires truncated, children reduced to a count so the payload stays QR-sized whatever the family — and a 5-minute PDF-link token carrying the full payload, whose in-payload expiry distinguishes a stale link (410) from a forged one (404). Sharing a dedicated key rather than the general-purpose encryptor lets the web app verify documents without calling siade and without widening the blast radius of the existing secret; that encryptor now memoizes its derived key (PBKDF2 ran on every INPI link before).
DSFR-styled document (hexapdf): label/value grid with French labels, Marianne header, keep-together sections, test-data banner, and a footer carrying the vector QR code, the visual code and the provenance line (SIRET + habilitation, RSSI traceability). The footer is also a link annotation to the same verification URL with the domain spelled out, so digital readers can click instead of scanning their own screen. Field labels load from commons/data/attestation_eaje_labels.yml, shared with the site app's verification page: a fraud check compares these exact strings across the two documents, so they must not drift.
X-Generate-Proof on the standard identite call replaces the idea of a dedicated attestation endpoint: proof-only enriches meta with the verification link and visual code, pdf adds a short-lived unauthenticated download link in links — one provider call serves the data and its proof, no extra scope, data block unchanged. The link is honored on mocked responses too (staging is where FQF integrators test), which required treating empty identity params like absent ones when matching mock payloads. Following the link hits a bare public controller that decrypts the self-contained token and renders the PDF — re-downloadable until expiry, 410 once stale, 404 when forged — throttled per IP alongside the verification page. The endpoint sheet and OpenAPI spec document the header.
The page lives where humans and DSFR live: site serves it at the clean /attestations/verification/:token URL the QR encodes — no /api prefix, no nginx exception — with the design system, the Rails-native rate limit, no-store/noindex and a tracker-free dedicated layout (RSSI: no cookies, no external resource). The shared attestation key lets site decrypt tokens on its own, so verification works even with siade down; a valid token shows the truncated subset and the visual code, anything else is a data-free 404.
Response envelopes now hand meta and links through on every call and tolerate binary bodies (a followed attestation link returns raw PDF bytes), and both scaffolds emit in:header OpenAPI parameters as optional kwargs wired to real request headers — X-Generate-Proof becomes generate_proof: on the EAJE identite method. Cache-Control stays unscaffolded as transport-level. SPECS.md makes both rules normative for future language ports; minor release for each package after merge.
Un3x
force-pushed
the
feature/api-6792-ajout-dun-pdf-signe
branch
from
July 29, 2026 15:27
ec56f71 to
5d6f180
Compare
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
2 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.
Replace the dedicated attestation endpoint with the
X-Generate-Proof: proof-only|pdfheader on the EAJE identite call: proof link + visual code inmeta, short-lived self-contained PDF link inlinks— one provider call, no extra scope.site/at/attestations/verification/:token(native DSFR, Rails-native rate limit, tracker-free layout), decrypting with a dedicatedattestation_encryptor_*key shared by both apps/api/attestations/:token.pdfrenders the PDF from its self-contained token — 410 stale, 404 forged; footer QR is now also a clickable linkgenerate_proof:in both clients (scaffolds now emitin: headerparams)Closes API-6792 → https://linear.app/pole-api/issue/API-6792/ajout-dun-pdf-signe
Avant de deploy il faut merge : https://github.com/etalab/very_ansible/pull/828 et apply