-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error accessing the encrypt fields. #53
Comments
Existing data is not encrypted automatically when you wrap an existing field (with existing data) with the Did you do your own migration to get any existing plaintext data into the encrypted field? |
Yes, I wrote the migration. The data is encrypted inside the DB as plain text. |
@thismatters anything you can help with here? |
Could there have been an issue with your token? Are you certain that you're using the same token (and salt) as that you used when doing the encrypting migration? |
No, I have generated a token with |
To be sure, you have generated a string literal and set that as |
Yup I have generated a value from my python shell and was using it. |
Values in my settings look like this, The data migration looks like this, this is third migration. The first two migrations are auto generated for renaming the field and creating encrypt field.
|
My python version is 3.7.5 along with these pip packages. |
I would try again with a different key. I've only ever used an alphanumeric key. You've confirmed that the migration works and that the data does appear encrypted in the database? |
Alphanumeric keys did not work for me actually. Can you tell me how you have created an alphanumeric key that worked? I was Yes and the data did encrypt, and example value for encrypted last_name looks like this, |
@thismatters could you find anything? |
I had misremembered the details about my key. It has punctuation as well, but no unicode characters or |
I just noticed the bit about your backend:
I've only ever used the default backend. Is there some motivating factor for using the openssl backend? |
This is something where I was confused. The docs said CRYPTOGRAPHY_BACKEND is not compulsory but whereas as the migrations were not working without this being provided. |
This is the extent of configuration I had to do:
Try that while using an ascii only key (and salt)! |
Okay let me try with them. However the backend I was using is the very backend that comes as a response from the default_backend function. |
The docs does not seem to suggest that app needs to be added in the installed apps. Also going with these settings I am getting |
Can you post the full traceback for this error |
|
and can you paste the full text of the migration called |
when you got that last traceback had you put |
Got the same traceback with and without adding django_cryptography to installed apps. 0012 is auto generated migration for encrypt field that is created by django itself. |
I would like to see the text of that migration since that is where the exception is being raised. |
Can you use this traceback, as the same error is getting returned even when I am retrying to generate the very 0012 migration. Initially when I was testing, I changed this setting after this creating this migration.
THis is the field I was trying to add here, |
it looks to me like |
This package no longer requires being added to
So I'm very confused about why you're getting the error you're seeing. I did just notice that you're using a fairly old version of Django. Can you try using a more recent version (3.2.x) to see if this problem persists? |
Before upgrading version, just as a sanity check can you open a django shell (within your project) and run the following three lines:
And see if the |
Yes, the error is raised. Sadly migrating to django 3.2.x at this time is not possible because of backwards incompatible changes in django 3.1 on JSONField. |
Upgrading to django-3.2.x and running this on the shell still causes and issue. I think I might have got the issue partially, I use django-configurations to achieve class based settings rather than the classic django settings(file based settings). AppConf class might be something that is only compatible with classic settings and not with django-configurations. |
I don't see how that could be possible. I've just re-created your environment in a docker container and the commands executed as expected:
Have you altered any files the |
I realized that I was using a newer version of python (3.7.10) while you're using 3.7.5. I was unable to get my test to run in 3.7.5. I recommend upgrading your python. At a minimum I would say you should be using the most recent minor version (3.7.10), but you should consider getting to the most recent major version as well. |
The problem does not seem to be with these versions. I have run the same version of django-cryptography with this python version in another setup without django-configurations and it is working fine. The issue seems to be the compatibility between django-configurations based settings and django-appconf. |
Oh, I hadn't seen that you were using |
Data got encrypted when I created a field wrapping with encrypt method. But when I access any obj.field a Value Error is raised.
ValueError: Invalid padding bytes
Which in turn raises
django_cryptography.utils.crypto.InvalidToken
Django==3.0.7
djangorestframework==3.11.0
cryptography==3.1
django-cryptography==1.0
The text was updated successfully, but these errors were encountered: