Databased-backed component `args`/`kwargs` about reactpy-django HOT 8 CLOSED

Before going with the database-backed approach, I have one more idea. What if users configured a secret in their settings for Django IDOM that we used to symmetrically encrypt the pickled parameters before including them in the rendered templates. This both protects sensitive information and prevents injection attacks without requiring anything to be stored in the database.

from reactpy-django.

We should develop that as an optional feature in an follow-up PR. To do that properly would require additional dependencies.

from reactpy-django.

My impression is that it might take more time to figure out how to properly expire these database entries vs adding a setting for a secret and using it to encrypting the parameters using the cryptography library.

from reactpy-django.

There is added complexity to cryptography though, mostly related to key rotation (handling/upgrading old keys to new keys without breaking). Additionally, a common issue with django DB encryption libraries is determining a way to do it without breaking AlterField migration operations.

from reactpy-django.

It looks like there's an option for key rotation: https://cryptography.io/en/latest/fernet/#cryptography.fernet.MultiFernet

With that said, I'm realizing that implementing an encryption-based solution in a way that's convenient for the user will involve saving these keys in the database and providing utilities to rotate them. This would allow us to make proper key-management and generation our responsibility rather than the user's and doing that would require some care.

Given this, I'm open to going with whatever approach you think will be easiest to complete the fastest.

from reactpy-django.

There's a lot to discuss about approach/compatibility/algorithms/etc. And it will require a non-trivial amount of code to accomplish within Django.

IMO encryption support deserves it's own issue/PR.

from reactpy-django.

It seems like to complete this then, you'll go with approaches 1 & 3 for expiration?

from reactpy-django.

Yeah. Although option 2 is technologically ideal, it does not seem convenient for end-users.

from reactpy-django.