Django Slugs and UUIDs

Why We have to Use UUID or SlugFlied:

The django default id or primary_key( pk ) is currently auto-incrementing id. Among other concerns, it tells a potential hacker exactly how many records you have in your database; it tells them exactly what the id is which can be used in a potential attack; and there can be synchronization issues if you have multiple front-ends.

There are two alternative approaches. UUID and SlugFiled

UUIDField:

A field for storing universally unique identifiers. Uses Python’s UUID class. When used on PostgreSQL and MariaDB 10.7+, this stores in a uuid datatype, otherwise in a char(32).

Example Code:

class UserProfile(models.Model):
    id = models.UUIDField(primary_key=True,default=uuid.uuid4,editable=False)
    name = models.CharField(max_length=500)
    email = models.EmailField()
    
    def __str__(self):
        return self.name
    
    def get_absolute_url(self):
        return reverse("user_details", args=[str(self.id)])

SlugField:

Slug is a newspaper term. A slug is a short label for something, containing only letters, numbers, underscores or hyphens. They’re generally used in URLs. Like a CharField, you can specify max_length. If max_length is not specified, Django will use a default length of 50.

Example Code:

class Post(models.Model):
    slug = models.CharField(max_length=250)

For example, in our example of “Django for Professionals” its slug could be django-for-professionals. There’s even a SlugField model field that can be used and either added when creating the title field by hand or auto-populated upon save.

The main challenge with slugs is handling duplicates though this can be solved by adding random strings or numbers to a given slug field. The synchronization issue remains though. A better approach is to use a UUID (Universally Unique IDentifier) which Django now supports via a dedicated UUIDField

Comments

WSGI vs ASGI: What Every Django Developer Should Know !

If you've been developing with Django, you've probably come across WSGI (Web Server Gateway Interface), the trusted friend of all traditional, synchronous web apps. But in this fast-moving, real-time world, you may have also heard about its dynamic, asynchronous cousin ASGI (Asynchronous Server Gateway Interface). WSGI (Web Server Gateway Interface): 1. The OG (original) Django interface, designed for synchronous HTTP requests. 2. Perfect for blogs, CMS, e-commerce, and standard web apps. 3. Uses servers like Gunicorn or uWSGI. 4. Limited to handling one request at a time. ASGI (Asynchronous Server Gateway Interface): 1. The modern, scalable interface designed for asynchronous web apps. 2. Ideal for handling WebSockets, HTTP/2, and real-time features like chat apps. 3. Built for high concurrency; uses Uvicorn, Daphne, or similar ASGI servers. 4. Allows you to leverage Python’s async and await for non-blocking code. When to Choose What: WSGI: Traditional apps where synchronou...

How Django stores passwords

Django Password Django provides a flexible password storage system and uses PBKDF2 by default. Django saves the password as below. <algorithm>$<iterations>$<salt>$<hash> example of a Hashed password stored in database: pbkdf2_sha256$390000$LCm33kvO7rbjbZhwJA90Sf$xfuGOzl/MJyUxqWNhsNdSThaQUvn1EjEfxZ48HA8HF4= Those are the components used for storing a User’s password,separated by the dollar-sign character and consist of: 1. The hashing algorithm 2. The number of algorithm iterations (work factor) 3. The random salt 4. The resulting password hash. Most password hashes include a salt along with their password hash in order to protect against rainbow table attacks. Example of Making Hashed password: Here’s a simplified overview of how Django handles password storage: 1. Password Creation or Change : # When someone creates a new account or decides to change their password, Django takes their chosen password and performs a process called hashing. Has...

Django pk vs id

Django pk VS id If you don’t specify primary_key=True for any fields in your model, Django will automatically add an IntegerField to hold the primary key, so you don’t need to set primary_key=True on any of your fields unless you want to override the default primary-key behavior. The primary key field is read-only. If you change the value of the primary key on an existing object and then save it, a new object will be created alongside the old one Example: class UserProfile ( models . Model ): name = models . CharField ( max_length = 500 ) email = models . EmailField ( primary_key = True ) def __str__ ( self ): return self . name suppose we have this model. In this model we have make email field as primary key. now django default primary key id field will be gone. It'll remove from database. we can not query as UserProfile.objects.get(id=1) after make email as primary key this query will throw an error. Now we have to use pk Us...

Django Interview Preparation

Search This Blog