Open erikcw opened 14 years ago
I don't think this issue is resolved. In fact, I just updated to the latest trunk, and now it is happening from the django shell as well.
"DjangoUnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data. You passed in '\xd0;\xb0\x86\xe5\xc1\xf3-\x8f\x7fj' (<type 'str'>)"
here is a traceback:
v='$AES$311ce7d6ca0980a12bce17dee2e2a42c'
DjangoUnicodeDecodeError Traceback (most recent call last)
/home/linx/linx/
/usr/lib/python2.5/site-packages/django_fields/fields.py in to_python(self, value) 59 self.cipher.decrypt( 60 binascii.a2b_hex(value[len(self.prefix):]) ---> 61 ).split('\0')[0] 62 ) 63 return value
/usr/lib/python2.5/site-packages/django/utils/encoding.pyc in force_unicode(s, encoding, strings_only, errors) 90 s = s.decode(encoding, errors) 91 except UnicodeDecodeError, e: ---> 92 raise DjangoUnicodeDecodeError(s, *e.args) 93 return s 94
DjangoUnicodeDecodeError: 'utf8' codec can't decode byte 0xb2 in position 5: unexpected code byte. You passed in '\x02\xcc\xabjY\xb2kt\xe5\x99\xe6\xac\xf8\xcfP\x9c' (<type 'str'>)
Is this issue still actual?
Although this issue is old, I just had a UnicodeDecodeError (decoding a private key passphrase with no unicode chars). Just in case anyone else stumbles upon this: updating django-fields to 0.2.2 solved it for me.
This error still happens for me. My production/staging/development environments have different SECRET_KEY values in their configurations. When we dump data from production to staging/development the encrypted data is no longer usable (which is perfectly fine). However if we want to change this data we are forced to drop into a posgres shell to wipe out the values. If we do not wipe the data out, the app will error our with the traceback listed on this issue. It would be better if it just threw out the values, or raised a better error telling the developer that the data cannot be decrypted.
We're on version 0.2.2.
One more to raise a better error