Quando esponi un sito pubblico, dovresti sempre disattivare DEBUG. Questo renderà il tuo server molto più veloce, e inoltre previene di mostrare a utenti malevoli i dettagli della tua applicazione che possono essere rivelati dalle pagine di errore.
Tuttavia, l’esecuzione con DEBUG impostato a False comporta che non saranno mai visibili gli errori generati dal tuo sito – al loro posto chiunque vedrà solo le pagine pubbliche di errore. Per tenere traccia degli errori che si verificano in un sito pubblicato, Django può essere configurato per creare reports con dettagli su tali errori.
Quando DEBUG è False, Django invierà una mail agli utenti citati nel setting ADMINS ogni volta che il tuo codice lancerà un’eccezione non gestita e che risulterà come un error interno del server ( in poche parole, per ogni risposta con un codice HTTP 500 or maggiore ). Questo comporta un’immediata notifica agli amministratori di qualsiasi errore. Le persone specificate nel setting ADMINS riceveranno un descrizione dell’errore, un traceback Python completo, e i dettagli della richiesta HTTP che ha generato gli errori.
By default, Django will send email from root@localhost. However, some mail\nproviders reject all email from this address. To use a different sender\naddress, modify the SERVER_EMAIL setting.
Per attivare questo comportamento, inserisci l’indirizzo email del destinatario nella configurazione ADMINS .
Django può essere configurato per inviare via email errori relativi ai link non funzionanti (errore 404 «pagina non trovata»). Django invia email relative ad errori 404 quando:
\nDEBUG è False;
La tua impostazione MIDDLEWARE include django.middleware.common.BrokenLinkEmailsMiddleware.
Se queste condizioni sono soddisfatte, Django invierà un’e-mail agli utenti elencati nell’impostazione MANAGERS ogni volta che il tuo codice genera un 404 e la richiesta ha un referer. Non si preoccupa di inviare e-mail per i 404 che non hanno un referer: di solito si tratta di persone che digitano URL non funzionanti o bot Web non funzionanti. Ignora anche i 404 quando il referer è uguale all’URL richiesto, poiché questo comportamento è dovuto anche a bot web rotti.
Puoi dire a Django di smettere di segnalare particolari 404 modificando l’impostazione IGNORABLE_404_URLS. Dovrebbe essere un elenco di oggetti di espressioni regolari compilati. Per esempio:
import re\n\nIGNORABLE_404_URLS = [\n re.compile(r"\\.(php|cgi)$"),\n re.compile(r"^/phpmyadmin/"),\n]\nIn questo esempio, un 404 a qualsiasi URL che finisce con .php oppure .cgi non verrà riportato.Inoltre nessuna URL inizierà con /phpmyadmin/`.
Gli esempi seguenti mostrano come escludere alcune URLs standard che i browser ed i crawler richiedono con frequenza:
\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(Nota bene che queste sono espressioni regolari, quindi mettiamo un backslash prima del punto per assicurarci l’interpretazione come carattere)
\nSe desideri personalizzare ulteriormente il comportamento di django.middleware.common.BrokenLinkEmailsMiddleware (ad esempio per ignorare le richieste provenienti dai web crawler), dovresti ereditare la classe e sovrascrivere i suoi metodi.
I report sugli errori sono davvero utili per il loro debug, quindi è generalmente utile registrare quante più informazioni possibili a riguardo. Ad esempio, per impostazione predefinita Django registra il full traceback per l’eccezione sollevata, le variabili locali di ogni traceback frame e i attributes di HttpRequest.
Comunque, a volte alcuni tipi di informazioni possono essere troppo sensibili e quindi non può essere appropriato tenere traccia ad esempio, della password o del numero di carta di credito di un utente. Quindi oltre a filtrare le impostazioni che sono sensibili come descritto nella documentazione DEBUG, Django offre una serie di decoratori di funzioni che ti aiutano a controllare quali informazioni debbano essere filtrate sul report degli errori in ambiente di produzione (cioè con DEBUG impostato a False): sensitive_variables() e sensitive_post_parameters().
Se una funzione (sia essa una view o una callback regolare) nel tuo codice usa variabili locali suscettibili di contenere infomazioni sensibili, puoi evitare che i valori di quelle variabili vengano inclusi nei report degli errori usando il decoratore 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 ...\nNell’esempio sopra, i valori delle variabili user, pw e cc verranno nascosti e sostituiti con asterischi (**********) nei report di errore, mentre verrà mostrato il valore della variabile name.
Per nascondere sistematicamente tutte e variabili locali di una funzione dal sistema di gestione degli errori nei log, non indicare alcun argomento al decoratore sensitive_variables:
@sensitive_variables()\ndef my_function(): ...\nIf one of your views receives an HttpRequest object\nwith POST parameters susceptible to\ncontain sensitive information, you may prevent the values of those\nparameters from being included in the error reports using the\nsensitive_post_parameters decorator:
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 ...\nNell’esempio di cui sopra, i valori dei parametri di POST per pass_word e credit_card_number saranno nascosti e rimpiazzati con degli asterischi (**********) nella rappresentazione della request nel report degli errori, dove invece il valore del parametro name sarà mostrato.
Per nascondere sistematicamente tutti i parametri di una richiesta POST nel report degli errori, non inserire alcun parametro al decoratore sensitive_post_parameters
@sensitive_post_parameters()\ndef my_view(request): ...\nTutti i parametri in POST sono sistematicamente filtrati dai report degli errori per alcune view django.contrib.auth.views (login, password_reset_confirm, password_change, add_view e user_change_password nell’amministrazione auth) per prevenire la fuoriuscita di informazioni sensibili come ad esempio le password utente.
Tutto ciò che fanno sensitive_variables() e sensitive_post_parameters() è, rispettivamente, annotare la funzione decorata con i nomi delle variabili sensibili e annotare l’oggetto HttpRequest con i nomi dei parametri POST sensibili, in modo che le informazioni possona essere successivamente filtrate dai report quando si verifica un errore. Il vero filtro viene eseguito dal filtro di report degli errori predefinito di Django: django.views.debug.SafeExceptionReporterFilter. Questo filtro utilizza le annotazioni dei decoratori per sostituire i valori corrispondenti con gli sterischi (**********) quando vengono prodotti i report di errore. Se desideri sovrascrivere o personalizzare questo comportamento predefinito per l’intero sito, devi definire la tua classe di filtro e dire a Django di usarla tramite l’impostazione DEFAULT_EXCEPTION_REPORTER_FILTER:
DEFAULT_EXCEPTION_REPORTER_FILTER = "path.to.your.CustomExceptionReporterFilter"\nPuoi controllare in modo più granulare quale filtro utilizzare all’interno di una vista configurando il parametro exception_reporter_filter della HttpRequest:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nLa tua classe del filtro personalizzato ha bisogno di ereditare da django.views.debug.SafeExceptionReporterFilter e può sovrascrivere i seguenti attributi e metodi:
Il carattere da utilizzare per rimpiazzare valori sensibili. Di default viene rimpiazzato il valore di stringhe sensibili con l’asterisco (**********).
Un oggetto di espressione regolare compilato per trovare le impostazioni ed i valori request.META considerati sensibili. In modo predefinito è equivalente a:
import re\n\nre.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)\nRestituisce True per attivare il filtro in get_post_parameters() e get_traceback_frame_variables(). Di default, il filtro è attivo se DEBUG is False. Nota che i valori sensibili request.META sono sempre filtrati così come i valori di impostazioni sensibili, come descritto nella documentazione di DEBUG.
Restituisce un dizionario filtrato di parametri POST. I valori sensibili sono rimpiazzati con cleansed_substitute.
Restituisce un dizionario filtrato di variabili locali per una data finestra di traceback. I valori sensibili sono rimpiazzati con cleansed_substitute.
Se necessiti di personalizzare i report degli errori oltre ai filtri, potresti specificare una classe personalizzata per il report degli errori definendo l’impostazione DEFAULT_EXCEPTION_REPORTER:
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"\nIl reporter delle eccezioni è resposabile di compilare i dati per il report delle eccezioni e di formattarli come HTML in modo appropriato. (Il reporter delle eccezioni usa DEFAULT_EXCEPTION_REPORTER_FILTER quando prepara i dati di report delle eccezioni).
La tua classe report personalizzata deve ereditare da django.views.debug.ExceptionReporter.
Proprietà che restituisce un pathlib.Path che rappresenta il percorso assoluto sul filesystem di un template per fare render della rappresentazione HTML dell’eccezione. E” predefinito il template che offre Django.
Proprietà che restituisce un pathlib.Path che rappresenta il percorso assoluto sul filesystem di un template per fare render della rappresentazione in plain-text dell’eccezione. E” predefinito il template che offre Django.
Restituisce un dizionario che contiene le informazioni utili per l’analisi
\nQuesta è il punto principale dell’estensione per personalizzare i report delle eccezioni, per esempio:
\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\nRestituisce la versione HTML del report dell’eccezione
\nUsato per la versione HTML del debug della pagina di errore 500 HTTP.
\nRestituisce una versione testuale del resoconto dell’eccezione
\nUsato per la versione testuale del debug della pagina di errore 500 HTTP e report email.
\nCosì come con la classe filtro, puoi controllare quale classe per il report di eccezioni usare dentro ad ogni view impostando l’attributo exception_reporter_class di HttpRequest:
def my_view(request):\n if request.user.is_authenticated:\n request.exception_reporter_class = CustomExceptionReporter()\n ...\n