Personally, I like the simplicity and elegance of a single SECRET_KEYS
setting. It's also a good way to raise awareness that rotation is A Good
Thing to be doing anyways.
In any case, I second all of those who've already endorsed this idea. If I
can help, let me know.
Tobias
On Sun, Nov 18, 2018
Very good point. I'd prefer a second setting though, named like
OLD_SECRET_KEYS or VERIFICATION_SECRET_KEYS. If we're going to add a new
setting, we might as well not force users who aren't rotating their keys to
the new one, especially if they are semantically different.
On Sun, 11 Nov 2018 at 18
Good point, I can think of at least two apps of mine that would break.
Transitioning to a new setting makes more sense.
--
Aymeric.
> On 11 Nov 2018, at 18:58, Tom Forbes wrote:
>
> Is it going to be easy to adjust the semantics of SECRET_KEY to support
> sequences like that? I’d imagine a
Is it going to be easy to adjust the semantics of SECRET_KEY to support
sequences like that? I’d imagine a lot of third party packages that expect
SECRET_KEY to be a string would break in weird ways (thanks to both strings
and tuples of strings being iterables that yield strings).
Here’s a quick s
Hello,
I think this is a great idea.
As suggested by others, an even better default implementation would be:
class SecretKeysBackend:
def get_signing_key(self):
if isinstance(settings.SECRET_KEY, (list, tuple)):
return settings.SECRET_KEY[0]
else:
ret
Maybe a LoFi way to accomplish this is just to make sure that the
SECRET_KEY is cast to bytes() before use. That way, a non-bytes object
placed there during settings will be asked to convert it to bytes before
use. I use the same trick with an internal module that retrieves database
passwords f
On 10 Nov 2018, at 13:29, Adam Johnson wrote:
>
> Hi Andreas
>
> I like your proposal, moving to a backend is an elegant way of solving both
> the immediate problem and opening up the other possibilities you mentioned.
Thanks Adam, I am glad you like the proposal. :)
> I think it would also b
> On 10 Nov 2018, at 13:00, ludovic coues wrote:
>
> I don't see how this would work.
>
> For example the session. You take the user cookie. You try to validate with
> your secret key. That doesn't work because the current key is the new one.
>
> With a custom cookie backend, you could chec
Hi Andreas
I like your proposal, moving to a backend is an elegant way of solving both
the immediate problem and opening up the other possibilities you mentioned.
I think it would also be nice to have an "out of the box" way of rotating
the key, without needing to implement a custom backend. Perh
I don't see how this would work.
For example the session. You take the user cookie. You try to validate with
your secret key. That doesn't work because the current key is the new one.
With a custom cookie backend, you could check if the old secret could
validate the cookie. But you need to change
Hi,
settings.SECRET_KEY can be used for sessions, password resets, form wizards and
other cryptographic signatures via the signing APIs. Changing SECRET_KEY means
that all of those will be invalidated and the users will be affected in weird
ways without really knowing what happened. (Why am I logg
11 matches
Mail list logo
