-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IDOR] sécurisation des urls de consultation des PASS IAE - part 1 [GEN-2405] #5446
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dans l'idée, il faut que les tests passent sur tous les commits pour faciliter un éventuel git bisect
. Donc la mise à jour des snapshots devraient être squashés avec l'ajout du champs.
name="public_id", | ||
field=uuid_field(default=None), | ||
), | ||
migrations.RunPython(fill_public_id_approval, migrations.RunPython.noop, elidable=True), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Il vaut mieux mettre l'ajout de la colonne dans une migration dédiée, sans atomic=False
. Sinon, si le déploiement est interrompu, ça va être pénible.
field=uuid_field(default=None), | ||
), | ||
migrations.RunPython(fill_public_id_approval, migrations.RunPython.noop, elidable=True), | ||
migrations.AlterField(model_name="approval", name="public_id", field=uuid_field(default=uuid.uuid4)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pourquoi faire un AlterField
? Tu peux directement ajouter le champs avec son default=uuid.uuid4
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
je vérifie, mais lors des premiers essais, avec un default=uuid.uuid4
, la migration appliquait la même valeur d'uuid sur toutes les lignes, et cassait la contrainte d'unicité.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Effectivement, il faut bien faire un AddField(..., default=None, ...)
suivi d'un AlterField(..., default=uuid.uuid4, ...)
😞
0d9a3e5
to
20c311e
Compare
20c311e
to
df34895
Compare
@@ -560,7 +561,7 @@ class Approval(PENotificationMixin, CommonApprovalMixin): | |||
public_id = models.UUIDField( | |||
verbose_name="identifiant public", | |||
help_text="identifiant opaque, pour les API et les URLs publiques", | |||
default=None, | |||
default=uuid.uuid4, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'aurais mis cette modif dans le 1er commit (avec une migration enchaînant AddField & AlterField), mais ça marche aussi comme cela :)
🤔 Pourquoi ?
Catégories changelog
PASS IAE
🍰 Comment ?
🧑🏭 ajout du champ
public_id
, uuid, unique, sur les modèlesApproval
🧑🏭 hydratation du champ, puis passage en default
uuid4
public_id
reste ennull=True
pour éviter un déphasage entre l'état de la base de données et django pendant les migrations.⏭️ PR préparatoire à la #5431
🚨