Devo restituire un codice di stato http 401 su un modulo di accesso basato su HTML?

Devo restituire un codice di stato http 401 su un modulo di accesso basato su HTML? La pagina è un modulo di accesso dedicato e non ha altri contenuti significativi, ma solo la struttura del sito. L'URL tuttavia può essere per una pagina che ha contenuti significativi, ma richiede l'accesso. Questa impostazione restituisce solo il codice di stato 401 e non richiede all'utente l'autenticazione di base.

Guardando gli standard sembra che 401 sia un codice di stato inappropriato per i moduli di accesso basati su HTML. Tuttavia, non ho mai sperimentato o sentito parlare di conseguenze negative nel farlo.

Quando si invia 401, "La risposta DEVE includere un campo di intestazione WWW-Authenticate (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta."

requisito menzionato qui:

http://tools.ietf.org/html/rfc2616#section-10.4.2

dettagliato qui:

http://tools.ietf.org/html/rfc2617#section-3.2.1

So che ci sono modi in cui posso aggirare i motori di ricerca nel convincerli a indicizzare o meno le pagine in base alla presenza di un modulo di accesso, ma preferirei usare i codici di stato http, in particolare 401 poiché la sua definizione sembra un corrispondenza perfetta se non per il requisito di intestazione WWW-Authenticate.

C'è qualche motivo per cui non dovrei usare 401 in questo caso? Semanticamente c'è qualche differenza tra non essere autorizzato a livello http rispetto a essere autorizzato a livello di applicazione? Ovviamente puoi avere entrambi, ma l'autenticazione a livello http non è solo per non implementarla a livello di applicazione?

Come noterete, RFC 2616 richiede che una risposta 401 sia accompagnata da un'intestazione WWC 2617 con autenticazione WWW. Suppongo che potresti tecnicamente soddisfare tale requisito inviando un'intestazione fasulla come:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

ma non ho idea di cosa faranno i browser se presenteranno una risposta 401 che non contiene sfide che capiscono. Vorrei pensare che la maggior parte se non tutti di loro sarebbe presentare il corpo della richiesta per l'utente (come RFC 2616 dice che dovrebbero fare se l'autenticazione non riesce), ma nessuno dei due RFC sembra dire in modo esplicito, in modo che possa legittimamente solo mostrare un messaggio di errore generico anziché.

Una possibile alternativa (se non si desidera utilizzare solo una risposta 200 come tutti gli altri sembrano fare) sarebbe utilizzare un codice di stato proibito 403 . Questo è un codice di risposta ampiamente utilizzato e, per quanto ne so, quasi tutti gli user agent interattivi (ovvero i browser, al contrario, per esempio, i motori di ricerca o i gestori di download) dovrebbero reagire presentando il contenuto all'utente, almeno se è abbastanza lungo .

Sebbene la descrizione del codice di stato 403 indichi che "[a] l'autorizzazione non aiuterà", ciò dovrebbe essere inteso nel contesto dell'IMO come riferimento all'autenticazione RFC 2617 o meccanismi di autorizzazione simili a livello di protocollo; per quanto riguarda il browser, non ha idea se l'invio di un modulo e la ricezione di un cookie in risposta contano come "autorizzazione" o qualcos'altro.

Un meccanismo più comunemente usato sarebbe quello di rispondere a richieste non autenticate con un reindirizzamento temporaneo a una pagina di accesso separata, con l'URL originale passato come parametro in modo che l'utente possa essere reindirizzato ad esso dopo una corretta autenticazione. Tuttavia, si noti che un'implementazione ingenua potrebbe consentire a una persona malintenzionata di creare un collegamento di accesso che reindirizzerebbe l'utente a un URL arbitrario dopo l'accesso. Se questo potrebbe essere un problema di sicurezza, è necessario adottare misure per impedirlo, ad esempio solo accettando restituire gli URL corrispondenti a un modello sicuro noto o proteggendo l'URL di ritorno con un codice di autenticazione dei messaggi per impedire modifiche.

In ogni caso, se si utilizzano i cookie HTTP per memorizzare i token di autenticazione dopo l'accesso, è necessario includere un'intestazione Vary nelle risposte (sia prima che dopo l'autenticazione) per impedire la memorizzazione nella cache inappropriata, come in Vary: Cookie.

Innanzitutto, se la pagina necessita di accesso, probabilmente dovresti bloccarla da robots.txt

In secondo luogo, se i robot raggiungono la pagina, un errore 401 è corretto.

probabilmente, i codici di stato possono essere utili per i non umani [e per alcuni browser? ]

indipendentemente dal metodo di accesso, è necessario inviare l'intestazione corretta

ad esempio in futuro potresti dover scrivere un client wrapper (non un browser web) che si autenticherà semplicemente richiedendo le intestazioni di pagina, non la totalità del codice html

è possibile implementare l'applicazione di accesso con entrambi i metodi utilizzando lo stesso database dell'elenco utenti