Va bene restituire il codice di stato HTTP "errato" per mostrare una pagina di errore più user-friendly?

Il protocollo esiste, c'è una risposta chiara su cosa fare. Questo non è niente di super segreto: è una "applicazione web interna per il dipartimento della mia università". Fai ciò che confonde gli utenti e le applicazioni il meno nel modo che consente un'espansione corretta in modo coerente.

Considera il flusso di pagine proposto:

1. L'utente va a /foo/1
   • L'utente non ha accesso a /foo/1 ma ha accesso a /foo/2
2. L'utente viene reindirizzato a /foo/2 (risposta 30X)

e il flusso di pagine di

1. L'utente va a /foo/1
   • L'utente non ha accesso a /foo/1 ma ha accesso a /foo/2 e /foo/3
2. ???

e il flusso di pagine di

1. L'utente va a foo/1
   • L'utente non ha accesso a nessuna risorsa
2. ???

Il problema è che il flusso di pagine per il primo caso non può essere applicato al flusso di pagine del secondo. Ciò significa che dovrai gestire una logica separata per ogni caso, o che avrai qualcosa che sorprende un utente ("ieri sono riuscito ad accedere alla mia pagina tramite /foo/1 , ma oggi non funziona dopo creato un nuovo progetto ").

Il codice "stupido" è più facile da capire sia per l'utente che per il codificatore. Mentre cercare di anticipare le esigenze dei tuoi utenti è una buona cosa, fornire loro qualcosa che in realtà non chiedono è la cosa sbagliata.

Considera la situazione:

1. Il Professore A invia al Professor B un link al progetto che il Professor A ha e chiede un feedback dal Professor B al riguardo.
2. Il Professor B fa clic sul link e viene automaticamente reindirizzato al proprio progetto.
3. Risultati della confusione.

Seguendo le specifiche http è chiaro cosa si dovrebbe fare. Offri una pagina 403.

Quindi servi la pagina 403. Questo non significa che devi renderlo una brutta pagina 403 che il server ha come predefinito. Indica che l'utente sta chiedendo una risorsa a cui non hanno accesso. Mostra loro a quali risorse fanno hanno accesso. Consentire loro di fare clic su tali collegamenti per arrivare dove potrebbero voler andare.

Non cercare di rendere il software troppo intelligente o intelligente. È importante che gli utenti del software siano in grado di entrare nel modello mentale di come funziona. Se ci sono troppi casi di spigoli e angoli per come funziona il software, o funziona in modi sorprendenti a volte - questo non va bene. Clever non è qualcosa a cui aspirare nel codice, e non è nemmeno qualcosa per cui lottare in UX.

Non essere consumato da UX in queste situazioni. Un codice 403 o 404 è un'informazione estremamente utile. Alcuni utenti potrebbero non capirlo, ma tradurlo in qualcos'altro in un tentativo errato di renderlo user friendly è una cattiva idea. È necessario mostrare agli utenti qualsiasi errore di livello 400 o 500 in modo che gli utenti possano segnalarli all'utente.

Se un utente ottiene un 404, è un problema che deve essere risolto. Se sei l'help desk e qualcuno chiama per dire "Ho fatto clic su un link e qualcosa di strano è successo e ho ricevuto questo strano messaggio ...", ora devi perdere tempo a cercare di capire cosa sta succedendo. Se chiamano e dicono "Ho ricevuto un errore 404 ...", ora sai esattamente cosa sta succedendo e puoi rispondere molto più rapidamente e con precisione. Gli utenti non dovrebbero vedere questi errori spesso, quindi non c'è bisogno di ridimensionare la pagina o oscurare il significato.

Dovresti anche registrare 400 e 500 errori. Perché a volte gli utenti non segnalano gli errori. Registrali e controlla spesso i log. Può essere scioccante vedere quanti errori si verificano di cui non hai mai sentito parlare.

Potresti generare la pagina di errore (per 403: Forbidden codice di errore HTTP). Questa pagina di errore potrebbe contenere collegamenti a pagine appropriate (dipendenti dal contesto).

Sto facendo una cosa simile su link usando il mio lev404cgi Programma CGI (software gratuito GPL3 + concesso in licenza). Prova ad aprire link o link ; queste sono pagine di errore 404: Not found , ma all'utente vengono forniti alcuni collegamenti a possibili sostituzioni o suggerimenti.

^{Ovviamente, suggerisco di utilizzare contenuti HTML5 conformi agli standard (in particolare per una pagina web dell'Università, poiché almeno il reparto CS avrebbe molti sistemi Linux) ed evitare i contenuti Adobe Flash (è un proprietario formato, sui miei sistemi Linux, spesso devo avviare un browser non Firefox per loro - cosa che faccio raramente-, quindi non lo avvierò per alcuni contenuti di "segnalazione degli errori".}

Considera che restituire un 403 può essere di per sé fonte di informazioni privilegiate, vale a dire quanti progetti totali esistono e quanto frequentemente vengono aggiunti.

Sono d'accordo con i suggerimenti per reindirizzare l'utente a un elenco utile di ciò che è permesso vedere. Non vorrei rivelare di aver individuato qualcosa a cui non sono autorizzati ad accedere.

Questo può sembrare paranoico, dal momento che le informazioni trapelate potrebbero essere davvero banali. Tuttavia, questo effettivamente peggiora il problema. Le persone tendono a valutare ciò che possono misurare. Se hanno delle metriche scadenti, prenderanno decisioni poco informate.

Considera scenari come:

1. La produttività di un reparto viene misurata in base al numero di progetti esistenti o alla velocità con cui vengono aggiunti.

2. Un membro della facoltà che tenta di valutare la propria posizione nell'ordine gerarchico in base alla percentuale di progetti totali a cui è consentito l'accesso.

3. Un membro della facoltà che sta tentando di determinare se vengono caricati dal resto del dipartimento in base alla proliferazione di nuovi progetti avviati senza il loro coinvolgimento.

Troppo paranoico per un ambiente accademico?

Inoltre, penso che sia opportuno prendere l'abitudine di non permettere mai a un sistema di rivelare informazioni che le persone non hanno bisogno di sapere. Se c'è un modo per abusarne (e di solito c'è), una persona intelligente lo capirà.

Allo stesso modo, sarebbe saggio identificare i progetti con qualcosa di diverso da un numero di incremento prevedibile.

tl; dr - Ho la seconda soluzione di Basile, e non credo che tu abbia pensato alle implicazioni del tuo reindirizzamento 303 preferito.

1.) The server redirects the user to /projects/2 (their previously visited page, which would of course always be a valid one) with a helpful notification at the top such as "Sorry, but you do not have permission to access XXXX"

Che cosa accade quando qualcuno segue un link da un'email o da un messaggio IM? Quindi non esiste una pagina visitata in precedenza, valida o meno.

Che cosa accade quando qualcuno scrive un wget o uno script del crawler per segnalare lo stato di un elenco di progetti? Invece, alcuni progetti riportano silenziosamente e misteriosamente lo stato dell'ultimo progetto consentito.

Cosa succede quando qualcuno non vede la notifica "utile" in alto? Guarderanno dove si aspettano di vedere il contenuto del progetto.

Non vedo come una pagina informativa 403 - che può spiegare cosa è successo, sia carina come vuoi, include un elenco di progetti che l'utente può visualizzare e / o un modo per richiedere l'accesso al progetto negato e ancora essere effettivamente corretto - non vedo come questo sia meno amichevole.

Sembra che il tuo caso d'uso sia:

1. When the user indicates they want to do XYZ, the browser sends a request to the server, which sends back a nice friendly reply page saying the user isn't allowed to do that.

In tal caso, dal punto di vista del server HTTP, la richiesta non è vietata. Puoi fare in modo che il server risponda con lo stato 200 senza sentirti in colpa o pensando che stai scostando da qualsiasi cosa.

Un altro caso d'uso comune è:

2. When the user isn't allowed to do XYZ, the XYZ button in the browser is disabled (or alternatively, not shown at all.)

In tal caso, è ancora necessario controllare i permessi sul server, perché le persone possono utilizzare gli strumenti F12 per abilitare il pulsante o sintetizzare il tipo di richiesta che un utente più privilegiato potrebbe fare. In questa situazione, la risposta con un 403 è comune (sebbene tu voglia limitare la quantità di informazioni che esponi).

Penso che valga la pena ricordare che il modello di permesso assunto dalle specifiche HTTP è abbastanza semplice. Se a volte all'utente è permesso fare XYZ e talvolta no, o se la logica per determinare se XYZ è permesso è complicato, allora il caso d'uso che penso tu stia facendo (numero 1 sopra) è perfettamente ragionevole.

Aggiornamento: (in risposta alla domanda aggiornata)

Quello che stavo cercando di dire sopra era che dovresti distinguere tra (a) utenti che stanno cercando di bypassare i tuoi controlli di accesso e (b) utenti che generalmente hanno il permesso di fare per il genere di cose che stanno cercando di fare, ma è necessario effettuare un adeguamento affinché la richiesta sia consentita nelle circostanze attuali. Non dovresti fare una UX amichevole per il gruppo (a), in effetti meno informazioni darai loro, meglio è. Il gruppo (b) potrebbe richiedere un UX amichevole, se le regole di autorizzazione sono complicate e potrebbe esserci un modo per risolvere la richiesta per renderla consentita.

Nella tua domanda aggiornata dici:

User 1 then types mydomain.com/projects/3 into the URL. User 1 is not the owner of project 3. Therefore, when the request gets to the server, the server denies it.

La domanda che ti invito a porsi è: perché il server lo nega? Se l'esistenza stessa del progetto 3 è un segreto dell'utente 1, allora fai finta che non esista e restituisca un 404. Più probabilmente (specialmente in un contesto accademico) è loro permesso conoscere il nome e il proprietario del progetto, quindi restituire loro una pagina che ha quell'informazione, ma non tutto ciò che ottiene il proprietario del progetto. Se non sono connessi, o il loro ruolo non fornisce l'accesso a nessun progetto, restituire un 403 potrebbe avere senso per qualsiasi URL che inizia con mydomain.com/projects/. Ma è tutto su chi ha il permesso di vedere cosa e perché.

Quando l'utente sceglie di non fare clic su uno dei link che hai fornito, e aleggia su di essi per vedere il formato, quindi digita un URL che assomiglia a quei link per vedere cosa fa, la tua responsabilità nel dare buoni UX è terminato e l'utente si sta allontanando dal gruppo (a).

Il rovescio della medaglia, se è qualcosa che è permesso vedere, dovresti avere una UX migliore per questo che aspettarsi che l'utente indovini l'URL. Ad esempio, se una delle funzionalità del sito è la possibilità di partecipare a un progetto che l'utente non ha creato autonomamente, l'utente ha bisogno di un modo semplice per vedere i progetti a cui potrebbe voler aderire.

Darò una seconda risposta, perché guardando indietro a ciò che hai scritto penso che potresti fare una domanda più semplice di quella che pensavo, una che merita una risposta molto semplice:

Is it okay to return the “wrong” HTTP status code in order to show a more user-friendly error page?

Sì.

Le specifiche HTTP non dicono che le applicazioni web (come il tuo o Stack Exchange) dovrebbero restituire uno stato 403 ogni volta che l'utente esce fuori limite. Piuttosto, dice che 403 esiste e ha un significato e che i client HTTP dovrebbero reagire in certi modi quando lo vedono. (Implica anche che vietare l'accesso è una cosa abbastanza comune da meritare il proprio codice di stato della serie 400.)

Quindi, a meno che tu non stia scrivendo un client o server HTTP (che dovrebbe seguire rigorosamente le specifiche) o fare qualcosa come un'API REST (il client REST è un caso speciale di client HTTP) hai la totale libertà di non restituire mai un 403 stato del tutto. Non stai violando le specifiche non restituendo il 403.

La mia altra risposta fornisce esempi di quando il ritorno 403 ha senso e quando potrebbe non.

403, 404 e 401 che non hai menzionato hanno significati specifici.

403 (proibito) non significa che questo particolare utente non è autorizzato ad accedere alla risorsa, ma che nessuno lo è. Non ha nulla a che fare con quel particolare utente e non c'è nulla che l'utente possa fare per essere autorizzato ad accedere.

401 (non autorizzato) significa che l'utente non è autorizzato ad accedere alla risorsa, ma questo è un problema che potrebbe essere risolto dall'utente ottenendo l'autorizzazione. In genere, questo viene utilizzato quando un utente non ha effettuato l'accesso o se è necessario fornire una password o se utenti diversi hanno diritti diversi e questo utente non dispone di diritti sufficienti.

404 (non trovato) significa che la risorsa non esiste. Qual è una cosa perfettamente normale che accada. Potrebbe accadere se l'utente ha digitato erroneamente un URL, ad esempio. Ma non dovresti mai dare un errore 404 se questo particolare utente non ha il diritto di accedere alla risorsa. 404 è inteso esattamente nel caso in cui una risorsa non esiste.

410 (andato) è qualche volta usato; significa che c'era una risorsa in passato, ma ora non c'è più ed è molto improbabile che ritorni. La differenza con 404 è che questo non è dovuto a qualcosa di sbagliato. La settimana scorsa la richiesta sarebbe potuta andare bene, ma ora la risorsa è sparita.