Exemple
ecto 3.14.1: Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database.
Échantillon vérifié pour hex ecto 3.14.1: Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time…
sha256:1e2a19ac37ba6adfa3f491b086bfc7d9a193727d9a750b88d8379b12a21249fb
Ce réseau offre une seule chose : un échantillon qui compile. Il l'a exécuté dans un bac à sable et conservé le reçu signé. Il ne note rien et ne garantit rien : si le même code compile chez vous, il ne l'a pas mesuré.
Combien de clés de signature distinctes ont déposé un reçu de contrat réussi. Une seule, c'est l'auteur ; plus d'une signifie que quelqu'un d'autre l'a compilé aussi. Une clé est auto-générée sans identité enregistrée derrière, donc on compte des clés, pas des personnes.
MIT-0
Preuves d'exécution
L'environnement déclaré et les exécutions signées sont séparés, pour que vous voyiez exactement ce que cet échantillon a exécuté et où.
- Base de preuve
- Contrat signé réussi
- Reçus de vérification
- 2
- Clés de signature qui l’ont compilé
- 2
Environnement déclaré
elixir linux x64 elixir elixir mix
Environnements des exécutions de vérification
| Environnement | Contrat | Étapes | Exécution |
|---|---|---|---|
| elixir 1 · linux alpine/x64 · docker ed25519:d91480838ac982c9 | PASS | compile:PASS · contract:PASS · load:PASS · resolve:PASS CONTAINER_RUN · hex@1 |
2026-08-17 |
| elixir 1 · linux alpine/x64 · docker ed25519:2175b912ea1c23b1 | PASS | compile:PASS · contract:PASS · load:PASS · resolve:PASS CONTAINER_RUN · hex@1 |
2026-08-18 |
Cas
HOW- Objectif
- Show that casting user-supplied `:lock_version` can redefine the optimistic-lock filter before `Repo` write-time checks, even without a database.
- Paquets
- Symboles
-
- Ecto.Changeset.cast
- Ecto.Changeset.optimistic_lock
- Ecto.Changeset.apply_changes
- Ecto.Changeset.get_change
- Environnement
- elixir
- Créé
- 2026-08-17T04:43:50Z
Contrat
- When `:lock_version` is not cast, `optimistic_lock/2` keeps the filter at the struct value, but once `:lock_version` is allowed in `cast/3`, `optimistic_lock/2` switches the filter to that user-supplied value, so checks can run against a client-controlled token.
- After `optimistic_lock/2`, a casted `:lock_version` value is still bumped in place, so `get_change/3` and `apply_changes/1` reflect an incremented counter even though no Repo is involved.
Fichiers
- NOTES.md
- csx.json
- mix.exs
- mix.lock
- test/contract.exs