Fa schifo per non fornire errori aggraziati a un utente che non utilizza correttamente il sito web?

Question

Recentemente ho ricevuto un feedback da un collega sul mio codice sorgente di un sito web. Dice che è una cattiva pratica non gestire con garbo ciò che l'interfaccia visiva non consente di fare.

Dato che non è molto chiaro, ecco un esempio.

Diciamo che un visitatore può commentare qualcosa.

• Un commento viene salvato in un database, in una colonna nvarchar(500).
• La lunghezza <input /> campo è limitato a 500.

Ma, naturalmente, nulla vieta ad un utente più avanzato per disabilitare il limite di lunghezza e digitare 501 caratteri.

(Altri esempi:. Presentando un'opzione che non esiste anche in una <select />Ma c'è è un errore di grazia quando l'utente viene chiesto di inserire un numero, e lei entra in un non numero invece, dal momento che gli eventi keypress sono controllati tramite JavaScript e JavaScript può essere disabilitato)

Se il visitatore lo fa, ci sarebbe un errore a livello di contratti di codice. La richiesta AJAX fallirebbe con un errore imprevisto (o, a pagina inoltrata, ci sarà un errore imprevisto). In tutti i casi, il visitatore vedrà che è successo qualcosa di sbagliato, ma non avrà alcun messaggio aggraziato che indica che la lunghezza del commento inviato è troppo lunga.

Perché è una cattiva pratica? Perché dovrei preoccuparmi di progettare messaggi di errore chiari ed espliciti per i casi in cui il visitatore che utilizza correttamente il sito Web non avrà mai?

---

Nota: capisco che fa schifo per visualizzare un errore dettagliato .NET Framework e una traccia dello stack quando qualcosa del genere accade. Se lo faccio, si tratta di un serio problema di sicurezza. Ma nel mio caso, c'è solo una risposta AJAX con qualcosa di molto generico o un reindirizzamento a una pagina generica con le scuse su un errore.

Answer 1

Dal momento che ognuno sembra mancare la tua domanda attuale, metterò nel mio 2c (anche se sarò senza dubbio downvoted per rappresaglia)

Finché gli ingressi sono convalidati lato server (il vostro client- il lato maxlength è probabilmente ok, anche se alcuni browser oscuri potrebbero non supportarlo), è possibile restituire un messaggio di errore generico purché non contenga informazioni sulle eccezioni (che non è stato specificato).

Se, tuttavia, è possibile fallire la convalida tramite mancanza di javascript o di immissione errata, è necessario fornire un messaggio di errore personalizzato per motivi di sanità dell'utente.

In breve, quello che stai facendo va bene.

validazione lato

Answer 2

Prima una cosa più importante

Si dovrebbe convalidare tutto le forniture utente sul server! Questo significa non lasciare 501 lettere attraverso

Oltre a questo, se un'eccezione non gestita si verifica si dovrebbe mostrare all'utente un messaggio che dà niente via. Se dovessi restituire informazioni sulle eccezioni, questo è polvere d'oro per un utente malintenzionato.

Il metodo migliore consiste nel visualizzare un errore generale come "Siamo spiacenti, stiamo lavorando al problema immediatamente" e inviare via e-mail le informazioni sulle eccezioni agli sviluppatori affinché possano risolverlo.

Answer 3

Perché dovrei preoccuparmi di progettare messaggi di errore chiari ed espliciti per i casi in cui il visitatore che utilizza correttamente il sito Web non avrà mai?

Se tutti usavano il Web correttamente, non avremmo mai avuto bisogno di convalida.

Come disse una volta Ronald Reagan: "Fidati, ma verifica".

Inserire la convalida sul lato server per la lunghezza dei campi. Metti in convalida per assicurarti che non ci siano attacchi XSS o SQL Injection. Non sono le persone che usano correttamente il tuo sito che devi preoccuparti, sono quelle che lo usano maliziosamente.

Answer 4

Penso che la maggior parte del problema è che si presume che la convalida dovrebbe avvenire solo nell'interfaccia utente. È davvero meglio convalidare nell'interfaccia utente e il backend. Non è necessario restituire una traccia dello stack o informazioni dettagliate sull'eccezione. Su Page_Load(), dovresti sempre convalidare tutti gli input dell'utente e visualizzare le informazioni staticamente, come se l'utente avesse disabilitato JavaScript.

Answer 5

Quello che stai descrivendo non è solo una cattiva pratica, è un cattivo design. Se è possibile anticipare un errore o un'eccezione, è necessario prevedere i metodi per gestirlo, attenuarlo o attenuarlo. Questo vale per qualsiasi progetto di interfaccia sia che si tratti di un sito Web o di un frigorifero. Se un visitatore riceve un errore generico e non viene fornita alcuna spiegazione su come risolverlo, allora perché quella persona dovrebbe preoccuparsi di usare il tuo sito web? Se sono costretti a (forse per ragioni di lavoro), allora tutto ciò che hai fatto è alienare il tuo cliente e darti un brutto nome.

Ti suggerirei di chiederti perché non stai gestendo queste situazioni molto facili da controllare. E 'la pigrizia o ti manca solo l'esperienza come utente?

Answer 6

Server è per due scopi principali:

• come graceful degradation se la convalida del client non funziona per qualche motivo

  • in questo caso, si vuole un bel utente messaggio amichevole

• come misura di sicurezza per garantire che i client dannosi non possano danneggiare il sistema.

  • in questo caso, non si desidera dettagli interni visualizzati

Se si vuole prendere la strada del vero degrado grazioso, sarebbe bello se il server ancora ha restituito all'utente un messaggio amichevole per ogni convalida.

Nel caso di lunghezza max, non è molto probabile che sia necessario. Ma molti tipi di convalida usano Javascript, e ci sono ancora quelle persone o piattaforme che non supportano Javascript. Le vecchie piattaforme mobili sarebbero i principali sospettati qui.

Tuttavia, in questi giorni, la maggior parte di noi presume che Javascript possa essere invocato, quindi un messaggio di errore generico se la convalida del server fallisce va bene.