Fondamentaux du module d'identification

Dès le démarrage d'une application web basée sur Django, l'accès à l'interface d'administration est protégé par défaut. La validation repose sur une table spécifique stockant les informations d'identité, nécessitant impérativement des droits privilégiés pour pénétrer dans l'espace de gestion.

Création initiale de l'administrateur

Pour définir un compte avec privilèges totaux, il convient d'utiliser la commande de gestion incluse dans le framework :

python manage.py createsuperuser

Une forme abrégée existe également en ligne de commande :

./manage.py createsuperuser

Lors de cette opération, le champ adressage électronique reste optionnel selon la méthode employée, bien qu'une suite de caractères sécurisée de huit signes minimum soit recommandée pour la clé d'accès.

Mécanismes de vérification et de session

Validation des identifiants

La fonction authenticate du module contribue à vérifier la légitimité des coordonnées fournies. Il est indispensable de transmettre à la fois le pseudo et le mot de passe :

from django.contrib.auth import authenticate

# Extraction des données depuis le formulaire
pseudo_saisi = context_requete.POST.get('identifiant')
secret_fourni = context_requete.POST.get('mot_de_passe')

# Vérification cryptographique
entite_utilisateur = authenticate(context_requete, username=pseudo_saisi, password=secret_fourni)

if entite_utilisateur:
    print(entite_utilisateur) # Retourne l'objet instancié si succès
    print(entite_utilisateur.username) # Affiche le nom
else:
    print("Identifiants invalides")

En cas d'échec de correspondance, la valeur retournée sera None. Notez que le mot de passe stocké est haché et non plaintext.

Établissement de la connexion active

Une fois l'identité confirmée, il faut lier l'utilisateur à la session courante via la fonction login. Cela permet d'accéder au profil connecté n'importe où dans l'application via l'attribut user de l'objet requête :

from django.contrib.auth import login

# Simulation de l'écriture dans la session HTTP
login(context_requete, entite_utilisateur)

Vérification du statut de connexion

Pour savoir si une personne est déjà authentifiée sans procéder à un nouvel appel d'API :

# Propriété booléenne intégrée
est_connecte = context_requete.user.is_authenticated

Récupération du profil courant

Le point d'accès principal se situe directement sur l'objet requête :

profil_actuel = context_requete.user

Sécurisation des vues applicatives

Django propose un mécanisme décorateur pour contraindre l'accès aux ressources protégées :

from django.contrib.auth.decorators import login_required

Niveaux de configuration

• Cible spécifique (Décorateur) : Appliqué au-dessus d'une fonction vue précise.
• Cible globale (Réglages) : Définie dans le fichier central de configuration (settings.py).

@login_required(login_url='/zone_identification/')
def page_protgee(requete):
    pass

# Dans settings.py
LOGIN_URL = '/acces_requis/'

La priorité s'applique localement : le paramètre défini sur la vue l'emporte sur celui du fichier global. L'avantage du scope global réside dans la réduction du code duplicatif, tandis que le scope local offre une flexibilité pour rediriger vers des pages d'erreur spécifiques selon le contexte.

Gestion des clés d'accès

Vérification d'une ancienne clé

Pour comparer un secret saisi avec celui cryptographié en base :

securite_confirmee = context_requete.user.check_password(cle_antérieure)

Mise à jour du secret

La modification implique deux étapes distinctes : le hachage en mémoire puis la persistance dans le stockage de données.

context_requete.user.set_password(nouveau_secret) # Génération du hash
context_requete.user.save() # Écriture effective en BDD

Désengagement

Pour vider la session et déconnecter l'acteur :

from django.contrib.auth import logout
logout(context_requete)

Inscription standard

Pour créer un compte classique, la méthode de création native doit être utilisée afin d'assurer le cryptage :

from django.contrib.auth.models import User

# Méthode sécurisée recommandé
User.objects.create_user(identifiant=new_name, password=new_secret_hashed)

# Attention : create() brut ne hache pas le mot de passe
# User.objects.create(username='test', password='test')

La création d'un administrateur via le code nécessite explicitement une adresse électronique valide :

User.objects.create_superuser(name=new_admin, email='admin@exemple.fr', password=pass_complex)

Personnalisation du modèle Utilisateur

Il est possible d'étendre la structure de données par défaut via l'héritage orienté objet. On utilise alors la classe abstraite fournie :

from django.db import models
from django.contrib.auth.models import AbstractUser

class ProfilComplexe(AbstractUser):
    numero_portable = models.BigIntegerField(null=True)
    date_inscription = models.DateTimeField(auto_now_add=True)

Conséquences sur la base de données

Lors de la première migration après ce changement :

• La table par défaut auth_user ne sera pas générée.
• Une nouvelle table reprendra toutes les colonnes de la base plus les extensions personnalisées.

Cette approche optimise les requêtes futures en évitant les jointures complexes.

Conditions préalables critiques

1. Timing : La déclaration doit précéder toute migration. Si auth_user existe déjà, une nouvelle base de données est recommandée ou une refonte complexe de schéma.
2. Intégrité : Ne pas redéfinir les champs existants d'AbstractUser, mais seulement ajouter des attributs complémentaires.
3. Référencement : Informer le framework du nouveau modèle via la variable de configuration :

AUTH_USER_MODEL = 'gestion_comptes.ProfilComplexe'

Une fois configuré, tout l'écosystème d'authentification utilisera automatiquement le nouveau schéma de données sans intervention manuelle sur les fonctions métiers.