När du driver en offentlig webbplats bör du alltid stänga av inställningen DEBUG. Det kommer att göra att din server körs mycket snabbare och kommer också att förhindra att illasinnade användare ser detaljer i din applikation som kan avslöjas av felsidorna.
Men om du kör med DEBUG inställd på False innebär det att du aldrig kommer att se fel som genereras av din webbplats - alla kommer istället att se dina offentliga felsidor. Du måste hålla reda på fel som uppstår på distribuerade webbplatser, så Django kan konfigureras för att skapa rapporter med detaljer om dessa fel.
När DEBUG är False kommer Django att skicka e-post till de användare som anges i ADMINS-inställningen när din kod ger upphov till ett ohanterat undantag och resulterar i ett internt serverfel (strängt taget för alla svar med en HTTP-statuskod på 500 eller högre). Detta ger administratörerna omedelbar information om eventuella fel. Inställningen ADMINS kommer att få en beskrivning av felet, en fullständig Python-spårning och detaljer om HTTP-begäran som orsakade felet.
Som standard kommer Django att skicka e-post från root@localhost. Vissa e-postleverantörer avvisar dock alla e-postmeddelanden från denna adress. Om du vill använda en annan avsändaradress ändrar du inställningen SERVER_EMAIL.
För att aktivera det här beteendet måste du ange mottagarnas e-postadresser i inställningen ADMINS.
Django kan också konfigureras att skicka e-postmeddelanden om fel på brutna länkar (404 ”sidan hittades inte”-fel). Django skickar e-postmeddelanden om 404-fel när:
\nDEBUG är False;
Din MIDDLEWARE inkluderar django.middleware.common.BrokenLinkEmailsMiddleware.
Om dessa villkor är uppfyllda kommer Django att skicka e-post till de användare som anges i inställningen MANAGERS när din kod ger upphov till en 404 och begäran har en referent. Det bryr sig inte om att skicka e-post för 404 som inte har någon referent - det är vanligtvis människor som skriver in trasiga webbadresser eller trasiga webbrobotar. Det ignorerar också 404:or när referensen är lika med den begärda webbadressen, eftersom detta beteende också kommer från trasiga webbrobotar.
Du kan tala om för Django att sluta rapportera vissa 404:or genom att justera inställningen IGNORABLE_404_URLS. Det bör vara en lista med kompilerade objekt för reguljära uttryck. Till exempel:
import re\n\nIGNORABLE_404_URLS = [\n re.compile(r"\\.(php|cgi)$"),\n re.compile(r"^/phpmyadmin/"),\n]\nI det här exemplet kommer en 404 till en URL som slutar med .php eller .cgi inte att rapporteras. Det gör inte heller någon URL som börjar med /phpmyadmin/.
Följande exempel visar hur du utesluter några konventionella webbadresser som webbläsare och sökrobotar ofta begär:
\nimport re\n\nIGNORABLE_404_URLS = [\n re.compile(r"^/apple-touch-icon.*\\.png$"),\n re.compile(r"^/favicon\\.ico$"),\n re.compile(r"^/robots\\.txt$"),\n]\n(Observera att detta är reguljära uttryck, så vi sätter en backslash framför punkterna för att undkomma dem)
\nOm du vill anpassa beteendet hos django.middleware.common.BrokenLinkEmailsMiddleware ytterligare (t.ex. för att ignorera förfrågningar som kommer från webbcrawlers), bör du underordna den och åsidosätta dess metoder.
Felrapporter är till stor hjälp vid felsökning, så det är i allmänhet bra att registrera så mycket relevant information om dessa fel som möjligt. Som standard registrerar Django till exempel den fullständiga spårningen för det undantag som uppstod, varje spårningsram lokala variabler och HttpRequest attributes.
Ibland kan dock vissa typer av information vara för känslig och därmed kanske inte lämplig att hålla reda på, till exempel en användares lösenord eller kreditkortsnummer. Så förutom att filtrera bort inställningar som verkar vara känsliga enligt beskrivningen i DEBUG-dokumentationen, erbjuder Django en uppsättning funktionsdekoratorer som hjälper dig att kontrollera vilken information som ska filtreras bort från felrapporter i en produktionsmiljö (det vill säga där DEBUG är inställd på False): sensitive_variables() och sensitive_post_parameters().
Om en funktion (antingen en vy eller en vanlig callback) i din kod använder lokala variabler som kan innehålla känslig information, kan du förhindra att värdena på dessa variabler inkluderas i felrapporter med hjälp av dekoratorn sensitive_variables:
from django.views.decorators.debug import sensitive_variables\n\n\n@sensitive_variables("user", "pw", "cc")\ndef process_info(user):\n pw = user.pass_word\n cc = user.credit_card_number\n name = user.name\n ...\nI exemplet ovan kommer värdena för variablerna user, pw och cc att döljas och ersättas med stjärnor (**********) i felrapporterna, medan värdet för variabeln name kommer att avslöjas.
För att systematiskt dölja alla lokala variabler i en funktion från felloggar ska du inte ange något argument till dekoratorn sensitive_variables:
@sensitive_variables()\ndef my_function(): ...\nOm en av dina vyer tar emot ett HttpRequest-objekt med POST parameters som kan innehålla känslig information, kan du förhindra att värdena för dessa parametrar inkluderas i felrapporterna med hjälp av dekoratorn sensitive_post_parameters:
from django.views.decorators.debug import sensitive_post_parameters\n\n\n@sensitive_post_parameters("pass_word", "credit_card_number")\ndef record_user_profile(request):\n UserProfile.create(\n user=request.user,\n password=request.POST["pass_word"],\n credit_card=request.POST["credit_card_number"],\n name=request.POST["name"],\n )\n ...\nI exemplet ovan kommer värdena för POST-parametrarna pass_word och credit_card_number att döljas och ersättas med stjärnor (**********) i framställningen av begäran i felrapporterna, medan värdet för parametern name kommer att avslöjas.
För att systematiskt dölja alla POST-parametrar i en begäran i felrapporter, ange inte något argument till dekoratorn sensitive_post_parameters:
@sensitive_post_parameters()\ndef my_view(request): ...\nAlla POST-parametrar filtreras systematiskt bort från felrapporter för vissa django.contrib.auth.views-vyer (login, password_reset_confirm, password_change och add_view och user_change_password i auth-admin) för att förhindra läckage av känslig information som användarlösenord.
Allt sensitive_variables() och sensitive_post_parameters() gör är att annotera den dekorerade funktionen med namnen på känsliga variabler och annotera HttpRequest-objektet med namnen på känsliga POST-parametrar, så att denna känsliga information senare kan filtreras bort från rapporter när ett fel inträffar. Den faktiska filtreringen görs av Djangos standardfilter för felrapporter: django.views.debug.SafeExceptionReporterFilter. Detta filter använder dekoratörernas anteckningar för att ersätta motsvarande värden med stjärnor (**********) när felrapporterna produceras. Om du vill åsidosätta eller anpassa detta standardbeteende för hela din webbplats måste du definiera din egen filterklass och berätta för Django att använda den via inställningen DEFAULT_EXCEPTION_REPORTER_FILTER:
DEFAULT_EXCEPTION_REPORTER_FILTER = "path.to.your.CustomExceptionReporterFilter"\nDu kan också styra på ett mer detaljerat sätt vilket filter som ska användas i en viss vy genom att ställa in HttpRequest’s exception_reporter_filter attribut:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nDin anpassade filterklass måste ärva från django.views.debug.SafeExceptionReporterFilter och kan åsidosätta följande attribut och metoder:
Strängvärdet att ersätta känsligt värde med. Som standard ersätts värdena för känsliga variabler med stjärnor (**********).
Ett kompilerat objekt för reguljära uttryck som används för att matcha inställningar och request.META-värden som anses vara känsliga. Som standard likvärdigt med:
import re\n\nre.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)\nReturnerar True för att aktivera filtreringen i get_post_parameters() och get_traceback_frame_variables(). Som standard är filtret aktivt om DEBUG är False. Observera att känsliga request.META-värden alltid filtreras tillsammans med känsliga inställningsvärden, vilket beskrivs i DEBUG-dokumentationen.
Returnerar den filtrerade ordlistan med POST-parametrar. Känsliga värden ersätts med cleansed_substitute.
Returnerar den filtrerade ordlistan med lokala variabler för den angivna spårningsramen. Känsliga värden ersätts med cleansed_substitute.
Om du behöver anpassa felrapporter utöver filtreringen kan du ange en anpassad felrapportörsklass genom att definiera inställningen DEFAULT_EXCEPTION_REPORTER:
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"\nUndantagsrapportören ansvarar för att sammanställa data för undantagsrapporten och formatera den som text eller HTML på lämpligt sätt. (Undantagsrapportören använder DEFAULT_EXCEPTION_REPORTER_FILTER när han förbereder data för undantagsrapporten)
Din anpassade reporterklass måste ärva från django.views.debug.ExceptionReporter.
Egenskap som returnerar en pathlib.Path som representerar den absoluta filsystemssökvägen till en mall för rendering av HTML-representationen av undantaget. Standard är den mall som tillhandahålls av Django.
Egenskap som returnerar en pathlib.Path som representerar den absoluta filsystemssökvägen till en mall för rendering av klartextrepresentationen av undantaget. Standard är den mall som tillhandahålls av Django.
Returnerar en ordbok som innehåller spårningsinformation.
\nDetta är den huvudsakliga förlängningspunkten för att anpassa undantagsrapporter, till exempel:
\nfrom django.views.debug import ExceptionReporter\n\n\nclass CustomExceptionReporter(ExceptionReporter):\n def get_traceback_data(self):\n data = super().get_traceback_data()\n # ... remove/add something here ...\n return data\nReturnera HTML-versionen av undantagsrapporten.
\nAnvänds för HTML-versionen av debug 500 HTTP-felsida.
\nReturnera klartextversionen av undantagsrapporten.
\nAnvänds för klartextversion av debug 500 HTTP-felsida och e-postrapporter.
\nPrecis som med filterklassen kan du styra vilken klass för undantagsrapportering som ska användas i en viss vy genom att ställa in attributet exception_reporter_class i HttpRequest:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_class = CustomExceptionReporter()\n ...\n