Appendix E. Guidance for Clients Desiring to Authenticate (Guida per i client che desiderano autenticarsi)

Appendice E. Guidance for Clients Desiring to Authenticate (Guida per i client che desiderano autenticarsi)

Molti client WebDAV che sono già stati implementati hanno impostazioni dell'account (simili al modo in cui i client di posta elettronica memorizzano le impostazioni dell'account IMAP). Pertanto, il client WebDAV sarebbe in grado di autenticarsi con le sue prime richieste al server, a condizione che abbia un modo per ottenere la sfida di autenticazione dal server con nome del realm, nonce e altre informazioni di sfida. Si noti che i risultati di alcune richieste potrebbero variare a seconda che il client sia autenticato o meno -- un PROPFIND potrebbe restituire più risorse visibili se il client è autenticato, ma non fallire se il client è anonimo.

Ci sono diversi modi in cui il client potrebbe essere in grado di attivare il server per fornire una sfida di autenticazione. Questa appendice descrive un paio di approcci che sembrano particolarmente probabili di funzionare.

Il primo approccio consiste nell'eseguire una richiesta che dovrebbe richiedere l'autenticazione. Tuttavia, è possibile che un server possa gestire qualsiasi richiesta anche senza autenticazione, quindi per essere completamente sicuro, il client potrebbe aggiungere un'intestazione condizionale per assicurarsi che anche se la richiesta supera i controlli dei permessi, non venga effettivamente gestita dal server. Un esempio di questo approccio sarebbe utilizzare una richiesta PUT con un'intestazione "If-Match" con un valore ETag inventato. Questo approccio potrebbe non portare a una sfida di autenticazione se il server non testa l'autorizzazione prima di testare i condizionali come richiesto (vedere Sezione 8.5), o se il server non ha bisogno di testare l'autorizzazione.

Esempio - forzare la sfida di autenticazione con richiesta di scrittura

>>Request

  PUT /forceauth.txt HTTP/1.1
  Host: www.example.com
  If-Match: "xxx"
  Content-Type: text/plain
  Content-Length: 0

Il secondo approccio consiste nell'utilizzare un'intestazione Authorization (definita in [RFC2617]), che probabilmente verrà rifiutata dal server ma che attiverà quindi una sfida di autenticazione appropriata. Ad esempio, il client potrebbe iniziare con una richiesta PROPFIND contenente un'intestazione Authorization contenente una stringa userid:password Basic inventata o con credenziali effettive plausibili. Questo approccio si basa sul server che risponde con un "401 Unauthorized" insieme a una sfida se riceve un'intestazione Authorization con un nome utente non riconosciuto, una password non valida, o se non gestisce nemmeno l'autenticazione Basic. Questo sembra probabile che funzioni a causa dei requisiti di RFC 2617:

"Se il server di origine non desidera accettare le credenziali inviate con una richiesta, DOVREBBE restituire una risposta 401 (Unauthorized). La risposta DEVE includere un campo di intestazione WWW-Authenticate contenente almeno una sfida (possibilmente nuova) applicabile alla risorsa richiesta."

C'è un leggero problema nell'implementare quella raccomandazione in alcuni casi, perché alcuni server non hanno nemmeno informazioni di sfida per determinate risorse. Pertanto, quando non c'è modo di autenticarsi a una risorsa o la risorsa è completamente disponibile pubblicamente su tutti i metodi accettati, il server PUÒ ignorare l'intestazione Authorization, e il client presumibilmente riproverà più tardi.

Esempio - forzare la sfida di autenticazione con intestazione Authorization

>>Request

  PROPFIND /docs/ HTTP/1.1
  Host: www.example.com
  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  Content-type: application/xml; charset="utf-8"
  Content-Length: xxxx

  [body omitted]