django.core.signing.BadSignature: Signature "b'k2eKksHUgI7NOp8dMFc6VxSfTlKs4UftAIhFXgV9DOw=\n'" does not match

[marquicus]

Hello maybe I'm doing something wrong but I'm getting the following error:

django.core.signing.BadSignature: Signature "b'ISgLribFeoptkfKApq1Fh083Ze/kwxvWv/NXnvs/wf8=\n'" does not match

I followed the example:

class Employee(models.Model):
    nombres = encrypt(models.CharField(max_length=40))
...

I've tried changing the CRYPTOGRAPHY_KEY and SIGNING_BACKEND without success

[georgemarshall]

Are you attempting to encrypt an existing field?

https://django-cryptography.readthedocs.io/en/latest/migrating.html

[mnelson4]

I think I had the same error. I would get it during the 3rd migration mentioned in https://django-cryptography.readthedocs.io/en/latest/migrating.html, and even when adding a new field. In my case, the problem came up because I wasn't allowing the new encrypted field to be null in the DB. Ie, the field didn't specify null=True,default=None. That meant that when I looked in the DB, the new column's values were all '', which, I agree with the code, doesn't look like a very encrypted value to me... Once I added null=True,default=None to the new encrypted field, the error went away and the migrations worked fine, and everything was great.

[dahlinPL]

Hi,

I faced same issue, and resolved it by changing SECRET_KEY to be urlsafe by generating new one using python -c "import secrets; print(secrets.token_urlsafe())" So my question is: This is by design that used key should be urlsafe? Or this is still kind of workaround, because I have some other setting which causing BadSignature issue? I'm asking since I didn't found this kind of limitation anywhere. However here: https://docs.djangoproject.com/en/3.2/topics/signing/#django.core.signing.Signer we can find information that sed can't be url safe, which suggest that key should be url safe?

Regards Marcin

[siddiknavadhiti]

I think I had the same error. I would get it during the 3rd migration mentioned in https://django-cryptography.readthedocs.io/en/latest/migrating.html, and even when adding a new field. In my case, the problem came up because I wasn't allowing the new encrypted field to be null in the DB. Ie, the field didn't specify null=True,default=None. That meant that when I looked in the DB, the new column's values were all '', which, I agree with the code, doesn't look like a very encrypted value to me... Once I added null=True,default=None to the new encrypted field, the error went away and the migrations worked fine, and everything was great.

Great solution, fixed my issue

[parad0x96]

If anyone still facing this issue you could simply do this:

• Delete the encrypted field.
• Do a migration.
• Add the encrypted field again.
• Do a migration. Worked for me

[Amanb1145]

I got this error on one of my servers so I moved to this - https://django-q2.readthedocs.io/en/master/index.html

[ThierryDeruyttere]

If someone faces this error, we have a django secret key for development and one for production. This is what messed things up for us. Still looking for a way to solve this elegantly.