<h4>Learn how to sign and unsigned content in few lines of Django code</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*PDex7-kDSvyQP-u7"><figcaption>Photo by <a href="https://unsplash.com/@cdr6934?utm_source=medium&amp;utm_medium=referral">Chris Ried</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Initially published on my <a href="http://tomisin.dev/blog">blog</a>.
In today’s digital landscape, data security has become a crucial aspect of any application.
With the increasing need to protect sensitive information, encryption has emerged as a vital tool for ensuring the safety and privacy of data. This data can include a wide range of sensitive information, such as invite codes, email addresses, usernames, and other personal information that should not be shared with users in plain text.
The use of encryption allows us to scramble this data, making it unreadable to anyone without the appropriate encryption key. This added layer of security is essential for maintaining the trust and confidence of our users, as well as for complying with various legal and regulatory requirements for data protection. As a result, encryption has become an integral part of modern application development, and its use is only expected to continue growing in the future.
Luckily, Django provides a range of utility functions to enable us encrypt and decrypt data of several types — str, int, list, dictionary.
<h3>How to generate a secret key in Django</h3>
Django provides a utility for generating secret keys. It
<pre>from django.core.management.utils import get_random_secret_key print(get_random_secret_key())</pre>
<h3>How to Encrypt and Decrypt Data in Django</h3>
<h4>A. Signer Class</h4>
A module in Django called signing has a Signer utility class. The class gives us the chance to supply any encryption key we want, and then use it to encrypt supported datatypes.
<pre>from django.core import signing def encrypt(raw_str: str, encryption_key: str) -&gt; str: # takes in any encryption key (i.e. salt), and uses it to encrypt some object signer = signing.Signer(salt=encryption_key) return signer.sign_object(raw_str) def decrypt(encoded_str: str, encryption_key: str) -&gt; str: # takes in any encryption key (i.e. salt), and uses it to decrypt a token signer = signing.Signer(salt=encryption_key) try: return signer.unsign_object(encoded_str) except signing.BadSignature: raise ValueError(f"Unable to decode hash {encoded_str}")</pre>
<h4>B. singing.dumps() and signing.loads()</h4>
Django further abstracts encryption by providing two methods dumps and loads, which internally pick the SECRET_KEY supplied in the settings.py file, and then perform encryption operations with the specified encryption key.
<pre>from django.core import signing def encrypt(raw_str: str): # Picks the `SECRET_KEY` provided in settings.py return signing.dumps(raw_str) def decrypt(raw_str: str): # Picks the `SECRET_KEY` provided in settings.py return signing.loads(raw_str)</pre>
There we have it, signing and unsigning in Django simplified.
Till next time, my guy!
Don’t forget to clap, share and subscribe, if you found this article helpful.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=e86fe7026096" width="1" height="1" alt="">

Learn how to sign and unsigned content in few lines of Django code

Simple Signing and Unsigning in Django

<h4>Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*0jvWLbXENhbH5Q2b"><figcaption>Photo by <a href="https://unsplash.com/fr/@markuswinkler?utm_source=medium&amp;utm_medium=referral">Markus Winkler</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Originally published on my <a href="https://tomisin.dev/blog">blog</a>.
In contemporary architecture, or by design requirements, we often have the need to keep certain records even after they’ve been “deleted” by the user — that’s where soft deletion comes in.
In this article, we would learn how to implement soft delete, while our application maintains its Django-ness (for lack of a better word), and we can still maintain the same interface with our model objects in the same way as we would, if we had hard deletion in place.
<h3>What is Soft Delete</h3>
Soft delete is the process of deleting records in such a way that it is still present in the database while made unavailable to the user. It involves using a flag to mark the record as unavailable, rather than deleting the record from the database.
<h3>Benefits of Soft Delete</h3>
<ol>
<li>Records are easier to restore.</li>
<li>Soft delete operations are faster because we run an UPDATE command in the database. For hard delete, we will run a DELETE command which is generally slower, especially when there are related records across tables.</li>
<li>It keeps are related records in-place.</li>
<li>It is the safer option, in cases where users may need to retrieve deleted information.</li>
</ol>
<h3>Cons of Soft Delete</h3>
<ol>
<li>Added complexity of filtering out records that have been flagged as deleted.</li>
<li>Unique constraints need to be refactored to include the column representing the delete flag, so records which have been soft deleted could be recreated.</li>
<li>In some cases, records might need some unique implementations when soft deleted. For example, when soft deleting card information or payment methods, we might need to clear some sensitive fields like PAN or CVV.</li>
</ol>
Some of these fetch queries will start to look like
<pre>SELECT * FROM users WHERE is_deleted=false;</pre>
Unique constraints would also start to look this, with soft deletion in place:
<pre>CREATE UNIQUE INDEX "users_unique" ON users(is_deleted, email) WHERE is_deleted=false;</pre>
<h3>Implementing Soft Delete in Django</h3>
When implementing soft delete in Django, the first thing that’s required is a base model. This would reduce the complexity and help eliminate the aforementioned cons, as we wouldn’t need to duplicate the soft delete logic in all our models. All we would need to do, is to extend from this BaseModel.
<pre>class BaseModel(models.Model): class Meta: abstract = True # common fields go here</pre>
The first thing we want to add to our base model, is the delete flag. The is_deleted field will inform us about the availability of the record.
<pre>class BaseModel(models.Model): # ...omitted for brevity... is_deleted = models.BooleanField(default=False)</pre>
Next, we override the delete method of the model. So, we can change the default behaviour of our model’s delete from hard deletion to soft deletion.
<pre>class BaseModel(models.Model): # ...omitted for brevity... def delete(self): """Mark the record as deleted instead of deleting it""" self.is_deleted = True self.save()</pre>
With this piece of code in place, we could soft delete records as we would normally hard delete records, and maintain a Django-ic codebase.
<pre>class User(BaseModel): class Meta: unique_together = ['email', 'is_deleted'] name = models.CharField(max_length=24) email = models.EmailField() new_user = User(name="Bolaji", email="user.test@example.com") new_user.save() new_user.delete() print(new_user.is_deleted) # True</pre>
Now that we can soft delete easily, we have to make sure that our query results never actually include any deleted record. We do so by creating a custom manager which filters out the deleted.
<pre>from django.db.models import Manager, QuerySet class AppManager(Manager): def get_queryset(self): return QuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(model.Model): # ...omitted for brevity... objects = AppManager()</pre>
With this in place, we can replace the default objects field of our Model with our AppManager. This would ensure that when we query using the familiar syntax, we are getting expected
<pre>class User(BaseModel): # ...omitted for brevity... user.objects.filter(...) user.objects.all() # excludes records flagged as deleted.</pre>
Wowza! Now, you can soft delete records while maintaining Django-ic code. Or, maybe there’s one more thing.
It’s possible to invoke delete on a queryset, instead of invoking it on an object. We have already catered for the latter my having a custom delete method in our BaseModel. To cater for the former scenario, we can make a custom queryset class.
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True)</pre>
Putting this altogether, we have:
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(models.Model): class Meta: abstract = True is_deleted = models.BooleanField(default=False) def delete(self): self.status = DELETED self.save() # Sample model class Post(BaseModel): content = models.CharField(max_length=140)</pre>
Finally, you have soft delete implemented, and you didn’t have to change your contract. Thanks for reading, buddy!
Leave a clap, share this article and do subscribe, if you found this article helpful.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5c0f95da7f0d" width="1" height="1" alt="">

Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.

Implementing Soft Delete in Django: An Intuitive Guide

So… you want to show the world what you’ve built with Django ?. I’ve got you covered! Continue reading on The Startup »

Deploying Django Apps for Production on Ubuntu Server 18.04 (Using Gunicorn + Supervisor + Nginx)

Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design.

django

Simple Signing and Unsigning in Django

database

Implementing Soft Delete in Django: An Intuitive Guide

Get one coding trick and an article delivered every week at no extra cost

django

Deploying Django Apps for Production on Ubuntu Server 18.04 (Using Gunicorn + Supervisor + Nginx)