django-anon icon indicating copy to clipboard operation
django-anon copied to clipboard

Support @anonymize decorater to be added to Django ORM model fields

Open anujbhatt opened this issue 5 years ago • 5 comments

I'd like to be able to add a decorator/attribute to a model field so django-anon knows to anonymize it. Hypothetical usage:

@anonymize
sensitive_info = models.CharField(
        max_length=255, blank=True, default="", db_index=True
    )

Why do we want this added:

  • Reduce developer overhead to designate a field as sensitive
  • Easily determine which fields are anonymized or not

anujbhatt avatar Nov 11 '20 19:11 anujbhatt

@caioariede have you been developing any functionality for this, out of interest? I'm exploring a prototype decorator to attach django-anon generators to fields at the moment; I'm not sure how far the work will progress but I'd be glad to compare notes.

ghost avatar Jun 24 '21 12:06 ghost

@jayaddison-collabora there's no work in progress related to this. We can discuss the approach here if you want, I'd be happy to help :)

caioariede avatar Jun 24 '21 12:06 caioariede

Hi @caioariede :wave:

The investigation into decorators hasn't gone too far, because I now realize that it's not possible to apply @-decorators to class variables, even although - if it were possible - that would provide for nice readable code.

The remaining options seem to be:

  • Custom field types -- possible, although for most codebases I think it is preferable to stick to vanilla Django model types
  • Creating a separate meta-class (perhaps even literally a class Meta) somewhere to hold the additional field anonymization metadata
  • Applying a method decorator inline - i.e. field = anonymized(CharField(...))

The third option seems nice in that it keeps the number of code lines (and therefore code navigation) to a minimum. It could make for a slightly noisy codebase though, if it has to be applied to a large number of fields.

What are your thoughts and can you share any stories of successful (or challenging!) Django db anonymizations?

ghost avatar Jun 24 '21 16:06 ghost

@jayaddison-collabora the third option for me seems to be the better but there are some concerns around single responsibility... something else I would suggest is a class decorator where you can pass in an anonymization class, for example:

@anonymize(PersonAnonymizer)
class Person(models.Model):
    ...

It all comes to what you are trying to solve, in the end. Another thing to note is that anonymization requires some rules to be declared as well, when your want a fake text, a fake number, a fake email, a fake phone number, a fake address, etc... In some situations you can infer that (for numbers, emails) but in some you can't (phone number, address)

caioariede avatar Jun 24 '21 16:06 caioariede

Thanks @caioariede - class decorators look like a good area for exploration. I'll experiment with a few things over here and report back with findings when I have them :)

ghost avatar Jun 24 '21 16:06 ghost