search

orcasgit / django-fernet-fields

Fernet symmetric encryption for Django model fields
BSD 3-Clause "New" or "Revised" License
193 stars 78 forks source link

TypeError: string argument without an encoding #16

Open brandontksmith opened 5 years ago

brandontksmith commented 5 years ago

I am experiencing the error indicated in the title. I am running Python 3.6.5 and am using the EncryptedCharField. Django 2.0

/venv/lib/python3.6/site-packages/fernet_fields/fields.py", line 76, in from_db_value value = bytes(value) TypeError: string argument without an encoding

Likely related to this? https://stackoverflow.com/a/37601966/5331935

ironyinabox commented 5 years ago

EDIT: Figured it out, I'm a dope and never ran migrations

9mido commented 4 years ago

Also getting the same error. I was able to get it to properly encrypt the field in my database but in my admin it is giving me the same error.

I also ran makemigrations and migrate but still no luck. After importing into my models.py file -> import fernet_fields as fields, as soon as I add fields.EncryptedCharField to my model class's field it gives me a problem in my admin for that model.

marcus-campos commented 4 years ago

Has anyone found a solution for this?

brno32 commented 3 years ago

I'm also getting this issue in Django 3.0 and Python 3.8

jpmateo022 commented 3 years ago

Im also getting this in fernet. Is this a python bug though its very random

jmg commented 3 years ago

For me the issue was that I had some values for the same column that were non encrypted. The error was fixed after dropping the column and re-creating it with empty values. Luckly the project wasn't in production.

contoneo commented 5 months ago

I have the same problem. djfernet 0.8.1 django 4.2.11 Python 3.9.18

Has anyone found a solution for this?

stefan6419846 commented 5 months ago

It seems like this randomly affects systems without a clear pattern, although systems setup cleanly from scratch did not yet show this behavior (in this case, the clean setup happens with djfernet, while the existing ones are being migrated from django-fernet-fields to djfernet, while switching from Django 3 to Django 4, but only showing this issue in some cases). For some reasons, the broken systems had a text type for the column definition, while the working ones where byte arrays as expected.

The only factor for confusion might be https://github.com/orcasgit/django-fernet-fields/blob/8f8cadb8a9637e3f5777c98b9a9dd7db1b044374/fernet_fields/fields.py#L79-L90 introduced in https://github.com/orcasgit/django-fernet-fields/commit/167c67a89142a77e8c20c0ba15696e0fbae8292f - this commit should in theory only affect validators. For EncryptedTextField definitions, this will temporarily switch the internal field type to the actually breaking TextField we observed; this seems to indicate that under some circumstances, Django and its migration process access the validators and get confused, thus wrongly creating a TextField instead of a BinaryField. Commenting this method/property seems to still let the tests pass, thus I am not sure whether this is still required at all anymore.