Ontwerpen van een Modulair Authenticatie Systeem met het Fabrieks Methode Patroon in Django

Uitvoering van het patroon in Django

We beginnen met het bouwen van een minimale maar productie-ready authenticatie module. De projectstructuur zou er zo kunnen uitzien:

myproject/
 authfactory/
 __init__.py
 base_auth.py
 backends.py
 factory.py
 views.py
 templates/
 settings.py

Abstract Authenticatieklasse

Maak een abstracte basisklasse aan die de interface definieert die elke betonnen backend moet implementeren. Deze interface zal ten minste een methode bevatten, maar je kunt ook optionele haken toevoegen zoals of methoden voor het verwerken van post-authenticatie.

# authfactory/base_auth.py
from abc import ABC, abstractmethod

class BaseAuthMethod(ABC):
 """Common interface for all authentication strategies."""

 @abstractmethod
 def authenticate(self, request):
 """
 Authenticate the user from the given request.
 Must return a User instance on success, or None on failure.
 """
 pass

 def get_user(self, user_id):
 """
 Optional method to retrieve a user object by ID.
 Can be used by backends that support session restoration.
 """
 return None

Met zorgt het gebruik ervan ervoor dat elke subklasse moet implementeren of Python zal een verhogen tijdens de instantitatietijd. Dit maakt het contract expliciet en helpt bij het debuggen.

Concrete authenticatiebackends

Voer nu concrete klassen uit voor de meest voorkomende authenticatiemethoden. We zullen onder andere:

• Gebruikersnaam/wachtwoordauthenticatie (met behulp van Django
• OAuth2-authenticatie (voorbeeld weergeven)
• JSON Web Token (JWT) authenticatie voor API-clients
• Sociale aanmelding via django-allouth

Gebruikersnaam/wachtwoord-backend

Deze backend gedelegeerden aan Django... eigen authenticatiesysteem, dat is getest... en bevat wachtwoord hashing, whottling en andere beveiligingsfuncties.

# authfactory/backends.py
from django.contrib.auth import authenticate
from .base_auth import BaseAuthMethod

class UsernamePasswordAuth(BaseAuthMethod):
 def authenticate(self, request):
 username = request.POST.get('username')
 password = request.POST.get('password')
 return authenticate(request, username=username, password=password)

 def get_user(self, user_id):
 from django.contrib.auth import get_user_model
 User = get_user_model()
 try:
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None

OAuth2 Backend

OAuth2 stromen zijn complexer. Dit voorbeeld laat zien hoe u een toegangs token kunt valideren ontvangen van een derde partij provider.

# authfactory/backends.py (continued)
import requests
from django.contrib.auth import get_user_model
from .base_auth import BaseAuthMethod

class OAuth2Auth(BaseAuthMethod):
 def __init__(self, provider_token_url, userinfo_url, client_id):
 self.provider_token_url = provider_token_url
 self.userinfo_url = userinfo_url
 self.client_id = client_id

 def authenticate(self, request):
 access_token = request.POST.get('access_token') or \
 request.META.get('HTTP_AUTHORIZATION', '').replace('Bearer ', '')
 if not access_token:
 return None
 # Verify token with the provider's introspection endpoint (simplified)
 response = requests.get(
 self.userinfo_url,
 headers={'Authorization': f'Bearer {access_token}'}
 )
 if response.status_code != 200:
 return None
 user_info = response.json()
 email = user_info.get('email')
 if not email:
 return None
 User = get_user_model()
 user, _ = User.objects.get_or_create(
 email=email,
 defaults={'username': email.split('@')[0]}
 )
 return user

 def get_user(self, user_id):
 User = get_user_model()
 try:
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None

Merk op dat productie OAuth2 backends ook de handtekening van de token moeten valideren, het verstrijken van de overeenkomst moeten controleren en eventueel de claim moeten verifiëren. Een robuuste implementatie zou een bibliotheek als of gebruiken.

JWT-backend (voor REST-API)

Bij het bouwen van een API met Django REST Framework (DRF) moet je vaak gebruikers via JSON Web Tokens authenticeren. De volgende backend valideert een JWT en haalt de gebruiker op uit de lading.

# authfactory/backends.py (continued)
import jwt
from django.conf import settings
from django.contrib.auth import get_user_model
from .base_auth import BaseAuthMethod

class JWTAuth(BaseAuthMethod):
 def __init__(self, secret_key=None, algorithm='HS256'):
 self.secret_key = secret_key or settings.SECRET_KEY
 self.algorithm = algorithm

 def authenticate(self, request):
 token = request.META.get('HTTP_AUTHORIZATION', '').replace('Bearer ', '')
 if not token:
 return None
 try:
 payload = jwt.decode(
 token,
 self.secret_key,
 algorithms=[self.algorithm]
 )
 except (jwt.ExpiredSignatureError, jwt.InvalidTokenError):
 return None
 user_id = payload.get('user_id')
 if not user_id:
 return None
 User = get_user_model()
 try:
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None

 def get_user(self, user_id):
 User = get_user_model()
 try:
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None

Sociale aanmelding via django-allouth

Als u gebruikt voor sociale authenticatie, kunt u het in een fabrieksbackend inpakken. Dit voorbeeld gaat ervan uit dat de sociale loginstroom wordt afgehandeld door allauth. De fabrieksbackend wordt na de OAuth callback aangeroepen om de login te voltooien.

# authfactory/backends.py (continued)
from allauth.socialaccount.models import SocialLogin, SocialAccount
from django.contrib.auth import get_user_model
from .base_auth import BaseAuthMethod

class SocialAuthBackend(BaseAuthMethod):
 def __init__(self, provider):
 self.provider = provider

 def authenticate(self, request):
 # This is called after allauth's social login process.
 # The user object is typically stored in the request by allauth.
 if hasattr(request, 'user') and request.user.is_authenticated:
 return request.user
 # Alternatively, you could inspect the session for a social token.
 return None

 def get_user(self, user_id):
 User = get_user_model()
 try:
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None

Deze backend is opzettelijk eenvoudig; een volledige integratie zou de sociale login state machine beheren door allauth. Het belangrijkste punt is dat elke backend voldoet aan dezelfde interface.

De Fabrieksklasse

De fabrieksklasse bepaalt welke betonnen backend instantiate. Het kan een eenvoudige keten of een woordenboek mapping voor uitbreidbaarheid gebruiken. We zullen ook configuratie van Django instellingen toestaan.

# authfactory/factory.py
from django.conf import settings
from .backends import (
 UsernamePasswordAuth,
 OAuth2Auth,
 JWTAuth,
 SocialAuthBackend,
)

class AuthMethodFactory:
 """Factory that returns the appropriate authentication backend."""

 _backends = {
 'username_password': UsernamePasswordAuth,
 'oauth2': lambda: OAuth2Auth(
 provider_token_url=settings.OAUTH2_TOKEN_URL,
 userinfo_url=settings.OAUTH2_USERINFO_URL,
 client_id=settings.OAUTH2_CLIENT_ID,
 ),
 'jwt': lambda: JWTAuth(
 secret_key=settings.JWT_SECRET_KEY,
 algorithm=settings.JWT_ALGORITHM,
 ),
 'social': lambda: SocialAuthBackend(provider='google'),
 }

 @classmethod
 def get_backend(cls, method_type, **kwargs):
 """
 Return an instance of the authentication backend
 identified by `method_type`.
 """
 if method_type not in cls._backends:
 raise ValueError(f"Unknown authentication method: {method_type}")
 backend_creator = cls._backends[method_type]
 if callable(backend_creator):
 return backend_creator()
 return backend_creator()

 @classmethod
 def get_backend_names(cls):
 """Return a list of all registered backend names."""
 return list(cls._backends.keys())

Deze implementatie gebruikt een woordenboek van lambda's om lui instant backends die constructor argumenten vereisen. De methode kan ook aanvullende trefwoord argumenten accepteren als u standaard parameters voor een bepaalde aanvraag moet overschrijven (bijv. een andere provider).

Voor nog meer flexibiliteit kunt u de backend-configuratie in de database opslaan en dynamisch registreren. Een statische mapping is echter vaak voldoende en gemakkelijker te testen.

Gebruik van de Fabriek in weergaven en Middleware

Integreer nu de fabriek in uw Django-weergaven. De client (browser of API-consument) moet de server vertellen welke authenticatiemethode hij wil gebruiken. Dit kan via een query parameter, een POST-veld of een aangepaste HTTP-header.

Traditionele aanmeldweergave

# authfactory/views.py
from django.contrib.auth import login
from django.http import HttpResponse, Http404
from django.views.decorators.csrf import csrf_exempt
import json
from .factory import AuthMethodFactory

@csrf_exempt
def login_view(request):
 """
 Login endpoint that supports multiple authentication methods.
 Expects a JSON body with 'auth_type' and method-specific credentials.
 """
 if request.method != 'POST':
 return HttpResponse(status=405, content='Method not allowed')

 try:
 data = json.loads(request.body)
 except json.JSONDecodeError:
 return HttpResponse(status=400, content='Invalid JSON')

 auth_type = data.get('auth_type', 'username_password')
 try:
 backend = AuthMethodFactory.get_backend(auth_type)
 except ValueError as e:
 return HttpResponse(status=400, content=str(e))

 user = backend.authenticate(request)
 if user is not None:
 login(request, user, backend='django.contrib.auth.backends.ModelBackend')
 return HttpResponse('Login successful')
 else:
 return HttpResponse(status=401, content='Invalid credentials')

Opmerking: De functie vereist een backend tekenreeksparameter. In een echte toepassing zou je ofwel het backend pad in de sessie opslaan ofwel de fabrieksbackendklasse gebruiken om het pad automatisch af te leiden. Voor eenvoud hebben we hier hardcoded; in productie kun je elke fabrieksbackend in kaart brengen naar een Django authenticatie backend string.

API weergaven met Django REST-raamwerk

Als u een API blootlegt, kunt u het fabriekspatroon aanpassen voor gebruik met DRF. In plaats van een aparte weergave te maken, schrijf dan een aangepaste authenticatieklasse die delegeert naar de fabriek.

# authfactory/rest_auth.py
from rest_framework.authentication import BaseAuthentication
from rest_framework.exceptions import AuthenticationFailed
from .factory import AuthMethodFactory

class FactoryBackendAuth(BaseAuthentication):
 """
 DRF authentication class that uses the AuthMethodFactory
 to validate tokens. The 'auth_type' is derived from a custom
 header 'X-Auth-Type'.
 """

 def authenticate(self, request):
 auth_type = request.META.get('HTTP_X_AUTH_TYPE', 'jwt')
 try:
 backend = AuthMethodFactory.get_backend(auth_type)
 except ValueError:
 raise AuthenticationFailed('Unsupported authentication type')

 user = backend.authenticate(request)
 if user is None:
 raise AuthenticationFailed('Invalid token')
 return (user, None)

 def authenticate_header(self, request):
 return 'Bearer' # Generic challenge for any method

Voeg dan deze authenticatieklasse toe aan uw DRF-instellingen of weergave:

# settings.py
REST_FRAMEWORK = {
 'DEFAULT_AUTHENTICATION_CLASSES': [
 'authfactory.rest_auth.FactoryBackendAuth',
 # other classes can be kept as fallback
 ],
}

Middleware voor automatische backendselectie

Soms moet u automatisch een backend selecteren op basis van de kenmerken van uw aanvraag (bijv. user agent, IP, domein). U kunt middleware schrijven die het verzoek inpakt en de juiste backend injecteert in .

# authfactory/middleware.py
from .factory import AuthMethodFactory

class AutoAuthBackendMiddleware:
 """
 Middleware that selects an authentication backend based on
 the request path or host.
 """
 def __init__(self, get_response):
 self.get_response = get_response

 def __call__(self, request):
 # Decide on auth type - example: use 'oauth2' for /api/v2/auth/*
 path = request.path_info
 if path.startswith('/api/v2/auth/'):
 request.auth_type = 'oauth2'
 elif path.startswith('/api/v1/auth/'):
 request.auth_type = 'jwt'
 else:
 request.auth_type = 'username_password'
 return self.get_response(request)

U kunt dan gebruiken in uw meningen zonder dat de cliënt het moet specificeren.

Geavanceerde overwegingen

Loggen en foutafhandeling

Productie-authenticatiesystemen moeten robuuste logging. Voeg gestructureerde logging in elke backend en de fabriek toe om authenticatiepogingen, storingen en potentiële beveiligingsevenementen vast te leggen.

import logging
logger = logging.getLogger(__name__)

class JWTAuth(BaseAuthMethod):
 def authenticate(self, request):
 # ... validation ...
 if not token:
 logger.warning('JWT auth attempted with no token')
 return None
 try:
 payload = jwt.decode(token, self.secret_key, algorithms=[self.algorithm])
 except jwt.ExpiredSignatureError:
 logger.info('Expired JWT token')
 return None
 except jwt.InvalidTokenError:
 logger.warning('Invalid JWT token')
 return None
 # ... user retrieval ...
 if user is None:
 logger.error(f'JWT valid but user {payload.get("user_id")} not found')
 return user

Testen van de fabriek en backends

Elke backend moet in isolatie worden getest. Gebruik Django

# tests/test_auth.py
from django.test import TestCase
from unittest.mock import Mock
from authfactory.factory import AuthMethodFactory
from authfactory.backends import UsernamePasswordAuth, OAuth2Auth

class FactoryTest(TestCase):
 def test_get_username_password_backend(self):
 backend = AuthMethodFactory.get_backend('username_password')
 self.assertIsInstance(backend, UsernamePasswordAuth)

 def test_get_oauth2_backend(self):
 backend = AuthMethodFactory.get_backend('oauth2')
 self.assertIsInstance(backend, OAuth2Auth)

 def test_unknown_method_raises_error(self):
 with self.assertRaises(ValueError):
 AuthMethodFactory.get_backend('unknown')

class UsernamePasswordAuthTest(TestCase):
 def test_authenticate_with_valid_credentials(self):
 # Create a test user
 from django.contrib.auth import get_user_model
 User = get_user_model()
 user = User.objects.create_user(username='test', password='secret')
 # ... mock request ...
 request = Mock()
 request.POST = {'username': 'test', 'password': 'secret'}
 backend = UsernamePasswordAuth()
 result = backend.authenticate(request)
 self.assertEqual(result, user)

Uitbreiding van het systeem

Om een nieuwe authenticatiemethode toe te voegen (bijv. SAML, magische link, WebAuthn), hoeft u alleen maar:

1. Creëer een nieuwe klasse die erft van en implementeert .
2. Registreer het in het woordenboek in .
3. Voeg eventueel een configuratie-item toe in Django-instellingen.

Deze minimale voetafdruk maakt het systeem eenvoudig te onderhouden en te testen. U kunt ook elke backend als een aparte herbruikbare app verpakken.

Voordelen van het gebruik van het Fabrieksmethodepatroon voor de Authenticatie

• Modulariteit: Elke authenticatiemethode is ingekapseld in zijn eigen klasse, waardoor de codebase gemakkelijker te navigeren en te redeneren is.
• Schaalbaarheid: Een nieuwe authenticatiestrategie toevoegen vereist geen wijzigingen in bestaande views, URL's of bedrijfslogica.
• Open/Gesloten principe: De kernauthenticatie-infrastructuur is gesloten voor wijziging maar is open voor uitbreiding via nieuwe backend-klassen.
• Testabiliteit: Backends kunnen onafhankelijk van elkaar worden getest. Door de fabriek te blokkeren kunt u weergaven testen zonder echte authenticatieafhankelijkheden.
• Configureerbaarheid: De fabriek kan worden aangedreven door instellingen, database records of runtime parameters, waardoor verschillende implementatieomgevingen verschillende authenticatiemethoden kunnen gebruiken.
• Separatie van de zorgen: De authenticatielogica wordt uit het zicht verwijderd, waardoor de weergave lichter wordt en meer gericht op de behandeling van verzoeken.

Conclusie

Het ontwerpen van een modulair authenticatiesysteem met het Factory Method patroon in Django transformeert een traditioneel monolithisch stukje infrastructuur in een flexibel, uitbreidbaar onderdeel. Door het definiëren van een abstracte interface en concrete backends voor elke authenticatiestrategie, krijgt u de mogelijkheid om te ruilen of authenticatiemethoden toe te voegen zonder de rest van uw toepassing aan te raken. De fabrieksklasse centraliseert instantiation logica, en het patroon integreert naadloos met Django .

Deze aanpak is niet beperkt tot authenticatie; hetzelfde Factory Method patroon kan worden toegepast op andere gebieden van uw Django project, zoals betaling gateways, notificatie kanalen, of gegevens-importeurs. Naarmate uw toepassing groeit, helpt het patroon u om schone grenzen te behouden en houdt uw codebase aan te passen aan toekomstige eisen.