Dogfeeding our signing API

68 views
Skip to first unread message

Florian Apolloner

unread,
Dec 17, 2020, 4:37:38 AM12/17/20
to Django developers (Contributions to Django itself)

Hi there,

Craig Smith is working on making cookie-based messages RFC compliant (https://code.djangoproject.com/ticket/32191). Our prefered approach would be to encode messages via `signing.dumps` and this is (excuse the wording) where the shitshow begins. As it currently stands we cannot use `signing.dumps` because it creates it's own `Signer` instance [1] and the messages framework uses `get_cookie_signer` [2] to get yet another signer instance. This means we would have to replicate that functionality or extract it somehow, which leads to duplication and more complexity. Craig tried to do the latter in [3] which leads to a kind of encoding/decoding mess because (understandably) the serializers used by `dumps/loads` operate on bytes, while many other things in Django use strings.

My way out of this mess would be to move `signing.dumps` & `signing.loads` onto the `Signer` class itself; this way this functionality would become reusable while allowing to switch how signing is performed. My preference would be to call those methods `sign_object` & `unsign_object` which would make it clear that it will have to run some kind of serializer over it. `signing.dumps/loads` could just call those methods then.

Another option would be to extract the serialization & compression part out of `signing.dumps/loads` into another set of functions, but that would (while giving more flexibility) give even more ways on how to do things. I rather have a public & documented way on how to use `Signer` instances to sign an object structure (with optional compression) and say "this is the way [of doing things in Django]" ;) The "raw" string signing methods `sign/unsign` can still be used if people need to do "more".

What do you all think? Does this make any sense?

Thanks,
Florian

1: https://github.com/django/django/blob/8f384505eee8ce95667d77cfc2a07d4abe63557c/django/core/signing.py#L124
2: https://github.com/django/django/blob/8f384505eee8ce95667d77cfc2a07d4abe63557c/django/core/signing.py#L75
3: https://github.com/django/django/pull/13732

Mariusz Felisiak

unread,
Dec 18, 2020, 4:21:36 AM12/18/20
to Django developers (Contributions to Django itself)
My way out of this mess would be to move `signing.dumps` & `signing.loads` onto the `Signer` class itself; this way this functionality would become reusable while allowing to switch how signing is performed. My preference would be to call those methods `sign_object` & `unsign_object` which would make it clear that it will have to run some kind of serializer over it. `signing.dumps/loads` could just call those methods then.

 It makes a lot of sense, IMO. Deprecating signing.dumps()/loads() is probably not necessary, we can leave them as shortcuts (you didn't suggest it, it's just my observation).

Best,
Mariusz
Reply all
Reply to author
Forward
0 new messages