Django 5.1: pagini private în mod implicit

O pagină nouă de rapoarte nu ar trebui să ajungă publică fiindcă autorul ei a uitat un decorator. Dacă aplicația se adresează în mod obișnuit angajaților sau clienților autentificați, cerința de autentificare merită să fie regula implicită. Django 5.1 a introdus un mecanism opțional pentru această regulă. Aplicația rămâne responsabilă să decidă ce înregistrări poate vedea fiecare utilizator.

Privită din noiembrie 2026, schimbarea utilă din versiunea lansată la 7 august 2024 privește felul în care definiți excepția. Într-o aplicație privată, accesul public putea deveni o alegere explicită. Simpla actualizare nu schimba politica de acces: noua componentă middleware trebuia configurată.

Ce înseamnă o declarație uitată

Când fiecare pagină primește separat cerința de autentificare, omiterea declarației poate permite accesul anonim. Pentru o aplicație internă, acesta este adesea un rezultat nepotrivit. Programatorul adaugă pagina, verifică formula de calcul și afișarea, dar omite cerința ca vizitatorul să intre mai întâi în cont. Aplicația poate afișa corect raportul și totuși să expună date pe care firma le considera private.

Dacă autentificarea este obligatorie implicit, aceeași omisiune lasă pagina în zona privată. Regula reduce riscul unei anumite greșeli. Nu dovedește că raportul este potrivit pentru orice cont și nici că interogarea respectă separarea datelor între clienți. Aceste decizii trebuie implementate și verificate separat.

Notele versiunii Django 5.1 prezintă împreună LoginRequiredMiddleware și decoratorul login_not_required. Tratați-le drept regulă și excepții. La verificarea codului puteți întreba de ce o pagină este publică, fără să depindeți de repetarea aceleiași declarații pe fiecare pagină privată.

Ordinea trebuie să respecte autentificarea

Ordinea componentelor middleware contează. Componenta pentru sesiuni trebuie să apară înainte de AuthenticationMiddleware, iar cerința de autentificare intervine după ce există informația despre utilizator. Codul middleware din versiunea etichetată 5.1 arată comportamentul relevant: utilizatorii autentificați trec mai departe; cererile anonime pot continua dacă pagina are atributul de exceptare; celelalte cereri anonime sunt redirecționate spre autentificare.

Redirecționarea este potrivită în primul rând pentru browser. O integrare care așteaptă o eroare într-un format destinat prelucrării automate poate primi în schimb o pagină de autentificare. Înainte să aplicați regula unei aplicații mixte, identificați adresele folosite de alte sisteme și stabiliți cum se autentifică acestea. Exceptarea de la regula pentru browser trebuie să păstreze verificarea proprie a integrării.

De exemplu, notificarea unui procesator de plăți poate sosi legitim fără sesiunea unui angajat. Este un caz ilustrativ, nu descrierea unui proiect pentru un client. Faptul că adresa poate fi accesată nu face orice mesaj de plată credibil. Verificările separate trebuie să stabilească expeditorul și validitatea evenimentului înainte de modificarea unei comenzi.

Intrarea în cont trebuie să rămână accesibilă

O pagină proprie de autentificare are nevoie de o excepție explicită. Altfel, vizitatorul poate fi trimis din nou spre pagina pe care încerca deja să o deschidă. Recuperarea parolei și celelalte puncte de intrare pentru vizitatori anonimi merită același inventar. Componenta standard LoginView are deja excepția în codul paginilor de autentificare din 5.1. Nu presupuneți că orice înlocuire proprie păstrează acest comportament.

Codul decoratorilor din 5.1 delimitează clar excepția: login_not_required atribuie valoarea false atributului login_required al paginii. Nu emite date de autentificare și nu acordă o permisiune. Marcarea unei pagini drept publică este o decizie despre acces, nu o dovadă că pagina nu prezintă riscuri.

Verificați excepțiile după scop. Un articol public de ajutor și o notificare semnată au motive diferite să accepte cereri fără sesiune. Dacă motivele rămân clare, un viitor responsabil va avea mai puține motive să copieze excepția pe un raport sensibil. Urmăriți să păstrați o zonă publică ușor de înțeles, fără să transformați numărul decoratorilor într-un indicator de siguranță.

Un utilizator autentificat poate aparține altui client

O verificare propusă pentru acceptarea implementării ar trebui să includă un vizitator anonim, un cont autorizat și un cont autentificat al altui client. Primul caz verifică cerința de autentificare. Celelalte verifică regula afacerii. Redirecționarea corectă a vizitatorului anonim nu spune dacă alt client poate schimba un identificator și obține o factură străină.

Examinați descărcările și exporturile împreună cu pagina care trimite spre ele. Ascunderea unui link nu stabilește dreptul de acces la destinația lui. Acestea sunt verificări propuse, nu teste executate pentru articol. O implementare concretă trebuie să demonstreze deciziile importante de acces, fără o suită mare de teste care doar repetă configurația.

Alegerea între sesiuni și un format de token ar răspunde altei întrebări. Aici decideți ce pagini cer implicit un utilizator recunoscut, apoi ce date poate accesa acesta. Identitatea validă rămâne doar una dintre informațiile folosite pentru decizie.

Pentru un site public, costul poate fi inutil

Într-o publicație sau într-un catalog public, majoritatea paginilor sunt intenționat anonime. Excepțiile adăugate peste tot pot îngreuna mentenanța și pot ascunde puținele funcții private. O cerință explicită de autentificare în zona contului poate fi mai clară. Recomandarea privește aplicațiile al căror conținut obișnuit este privat, nu orice site Django.

Pentru o aplicație predominant privată, începeți discuția despre dezvoltarea software la comandă cu inventarul paginilor și punctele de intrare anonime. Verificați apoi separat drepturile asupra înregistrărilor. Adoptați regula dacă se potrivește aplicației, păstrați căile publice justificate și cereți dovada că utilizatorul autentificat întâlnește în continuare limita corectă între datele clienților.