TypeError: string argument without an encoding

[brandontksmith]

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]

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

[9mido]

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]

Has anyone found a solution for this?

[brno32]

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

[jpmateo022]

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

[jmg]

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]

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]

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

django-fernet-fields/fernet_fields/fields.py

Lines 79 to 90 in 8f8cadb

	@cached_property
	def validators(self):
	# Temporarily pretend to be whatever type of field we're masquerading
	# as, for purposes of constructing validators (needed for
	# IntegerField and subclasses).
	self.__dict__['_internal_type'] = super(
	EncryptedField, self
	).get_internal_type()
	try:
	return super(EncryptedField, self).validators
	finally:
	del self.__dict__['_internal_type']

introduced in 167c67a - 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.