Reimpostazione della password RESTful

Qual è il modo corretto per strutturare una risorsa RESTful per reimpostare una password?

Questa risorsa ha lo scopo di reimpostare la password per qualcuno che ha perso o dimenticato la propria password. Invalida la vecchia password e invia loro una password tramite posta elettronica.

Le due opzioni che ho sono:

POST /reset_password/{user_name}

o...

POST /reset_password
   -Username passed through request body

Sono abbastanza sicuro che la richiesta dovrebbe essere un POST. Sono meno sicuro di aver selezionato un nome appropriato. E non sono sicuro che user_name debba essere passato attraverso l'URL o il corpo della richiesta.

AGGIORNAMENTO: (oltre a commentare sotto)

Vorrei qualcosa del genere:

POST /users/:user_id/reset_password

Hai una raccolta di utenti, in cui il singolo utente è specificato dal {user_name}. Dovresti quindi specificare l'azione su cui operare, che in questo caso è reset_password. È come dire "Crea ( POST) una nuova reset_passwordazione per {user_name}".

Risposta precedente:

Vorrei qualcosa del genere:

PUT /users/:user_id/attributes/password
    -- The "current password" and the "new password" passed through the body

Avresti due raccolte, una raccolta di utenti e una raccolta di attributi per ogni utente. L'utente è specificato da :user_ide l'attributo è specificato da password. L' PUToperazione aggiorna il membro indirizzato della raccolta.

Utenti non autenticati

Facciamo una PUTrichiesta su un api/v1/account/passwordendpoint e richiediamo un parametro con l'e-mail dell'account corrispondente per identificare l'account per il quale l'utente desidera reimpostare (aggiornare) la password:

PUT : /api/v1/account/password?email={email@example.com}

Nota: come @DougDomeny ha menzionato nel suo commento, passare l'e-mail come stringa di query nell'URL è un rischio per la sicurezza. I parametri GET non sono esposti durante l'uso https(e dovresti sempre usare una httpsconnessione appropriata per tali richieste) ma ci sono altri rischi per la sicurezza coinvolti. Puoi leggere di più su questo argomento in questo post del blog qui .

Il passaggio dell'email nel corpo della richiesta sarebbe un'alternativa più sicura al passarlo come parametro GET:

PUT : /api/v1/account/password

Corpo della richiesta:

{
    "email": "email@example.com"
}

La risposta ha un significato di risposta 202accettata :

La richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata. La richiesta potrebbe o meno essere eseguita alla fine, in quanto potrebbe non essere consentita quando l'elaborazione ha effettivamente luogo. Non è possibile inviare nuovamente un codice di stato da un'operazione asincrona come questa.

L'utente riceverà un'e-mail all'indirizzo email@example.come l'elaborazione della richiesta di aggiornamento dipende dalle azioni intraprese con il collegamento dall'e-mail.

https://example.com/password-reset?token=1234567890

L'apertura del collegamento da questa e-mail indirizzerà a un modulo di reimpostazione della password nell'applicazione front-end che utilizza il token di reimpostazione della password dal collegamento come input per un campo di input nascosto (il token fa parte del collegamento come stringa di query). Un altro campo di input consente all'utente di impostare una nuova password. Un secondo input per confermare la nuova password verrà utilizzato per la convalida sul front-end (per evitare errori di battitura).

Nota: nell'email potremmo anche menzionare che nel caso in cui l'utente non abbia inizializzato alcuna reimpostazione della password può ignorare l'email e continuare a utilizzare l'applicazione normalmente con la sua password attuale

Quando il modulo viene inviato con la nuova password e il token come input, avrà luogo il processo di reimpostazione della password. I dati del modulo verranno inviati PUTnuovamente con una richiesta ma questa volta includendo il token e sostituiremo la password della risorsa con un nuovo valore:

PUT : /api/v1/account/password

Corpo della richiesta:

{
    "token":"1234567890",
    "new":"password"
}

La risposta sarà una risposta 204senza contenuto

Il server ha soddisfatto la richiesta ma non ha bisogno di restituire un corpo dell'entità e potrebbe voler restituire le metainformazioni aggiornate. La risposta PU includere metainformazioni nuove o aggiornate sotto forma di intestazioni di entità, che se presenti DOVREBBERO essere associate alla variante richiesta.

Utenti autenticati

Per gli utenti autenticati che vogliono cambiare la propria password la PUTrichiesta può essere eseguita immediatamente senza l'email (l'account di cui stiamo aggiornando la password è noto al server). In tal caso il modulo presenterà due campi:

PUT : /api/v1/account/password

Corpo della richiesta:

{
    "old":"password",
    "new":"password"
}

Diventiamo super-RESTful per un secondo. Perché non utilizzare l'azione DELETE per la password per attivare un ripristino? Ha senso, non è vero? Dopotutto, stai effettivamente scartando la password esistente a favore di un'altra.

Ciò significa che faresti:

DELETE /users/{user_name}/password

Ora, due grandi avvertimenti:

1. HTTP DELETE dovrebbe essere idempotente (una parola di fantasia per dire "non è un grosso problema se lo fai più volte"). Se stai facendo le cose standard come l'invio di un'e-mail di "reimpostazione della password", allora incorrerai in problemi. È possibile aggirare questo problema contrassegnando l'utente / password con un flag booleano "Is Reset". Ad ogni cancellazione, controlli questo flag; se non è impostata , allora si può reimpostare la password e invia la tua email. (Nota che avere questo flag potrebbe avere anche altri usi.)

2. Non puoi utilizzare HTTP DELETE tramite un modulo , quindi dovrai effettuare una chiamata AJAX e / o eseguire il tunneling DELETE attraverso il POST.

Spesso non si desidera eliminare o distruggere la password esistente dell'utente nella richiesta iniziale, poiché ciò potrebbe essere stato attivato (involontariamente o intenzionalmente) da un utente che non ha accesso all'email. Invece, aggiorna un token di reimpostazione della password sul record utente e invialo in un collegamento incluso in un'e-mail. Fare clic sul collegamento confermerebbe che l'utente ha ricevuto il token e desidera aggiornare la propria password. Idealmente, anche questo sarebbe sensibile al tempo.

L'azione RESTful in questo caso sarebbe un POST: l'attivazione dell'azione di creazione sul controller PasswordResets. L'azione stessa aggiorna il token e invia un'e-mail.

In realtà sto cercando una risposta, non intendo fornirne una, ma "reset_password" mi sembra sbagliato in un contesto REST perché è un verbo, non un sostantivo. Anche se dici che stai facendo un nome di "azione di ripristino" - usando questa giustificazione, tutti i verbi sono nomi.

Inoltre, a qualcuno che cerca la stessa risposta potrebbe non essere venuto in mente che potresti essere in grado di ottenere il nome utente attraverso il contesto di sicurezza e non doverlo inviare tramite l'URL o il corpo, il che mi rende nervoso.

Penso che un'idea migliore sarebbe:

DELETE /api/v1/account/password    - To reset the current password (in case user forget the password)
POST   /api/v1/account/password    - To create new password (if user has reset the password)
PUT    /api/v1/account/{userId}/password    - To update the password (if user knows is old password and new password)

Per quanto riguarda la fornitura dei dati:

• Per ripristinare la password corrente

  • l'email dovrebbe essere inserita nel corpo.

• Per creare una nuova password (dopo il ripristino)

  • la nuova password, il codice di attivazione e l'ID e-mail devono essere inseriti nel corpo.

• Per aggiornare la password (per utente connesso)

  • vecchia password, la nuova password dovrebbe essere menzionata nel corpo.
  • UserId in Params.
  • Token di autenticazione nelle intestazioni.

Ci sono alcune considerazioni da fare:

Le reimpostazioni della password non sono idempotenti

Una modifica della password influisce sui dati utilizzati come credenziali per eseguirla, che di conseguenza potrebbe invalidare i tentativi futuri se la richiesta viene semplicemente ripetuta alla lettera mentre le credenziali memorizzate sono cambiate. Ad esempio, se un token di ripristino temporaneo viene utilizzato per consentire la modifica, come è consuetudine in una situazione di password dimenticata, tale token dovrebbe scadere in caso di modifica della password riuscita, il che annulla nuovamente ulteriori tentativi di replica della richiesta. Quindi un approccio RESTful alla modifica della password sembra essere un lavoro più adatto POSTdiPUT .

L'ID o l'e-mail nel caricamento dei dati è probabilmente ridondante

Sebbene non sia contro REST e possa avere uno scopo speciale, spesso non è necessario specificare un ID o un indirizzo e-mail per reimpostare la password. Pensaci, perché dovresti fornire l'indirizzo email come parte dei dati a una richiesta che dovrebbe passare attraverso l'autenticazione in un modo o nell'altro? Se l'utente sta semplicemente cambiando la propria password, deve autenticarsi per farlo (tramite nome utente: password, email: password o token di accesso fornito tramite intestazioni). Quindi, abbiamo accesso al loro account da quel passaggio. Se avessero dimenticato la password, gli sarebbe stato fornito un token di ripristino temporaneo (tramite e-mail) che possono utilizzare specificamente come credenziali per eseguire la modifica. E in questo caso l'autenticazione tramite token dovrebbe essere sufficiente per identificare il proprio account.

Prendendo in considerazione tutto quanto sopra, ecco quello che credo sia lo schema corretto per una modifica della password RESTful:

Method: POST
url: /v1/account/password
Access Token (via headers): pwd_rst_token_b3xSw4hR8nKWE1d4iE2s7JawT8bCMsT1EvUQ94aI
data load: {"password": "This 1s My very New Passw0rd"}

Non avrei qualcosa che modifichi la password e ne invii una nuova se decidi di utilizzare il metodo / users / {id} / password e ti attieni alla tua idea che la richiesta è una risorsa a sé stante. cioè / user-password-request / è la risorsa, ed è use PUT, le informazioni utente dovrebbero essere nel corpo. Tuttavia, non cambierei la password, mando un'e-mail all'utente che contiene un collegamento a una pagina che contiene un request_guid, che potrebbe essere passato insieme a una richiesta a POST / user / {id} / password /? Request_guid = xxxxx

Ciò cambierebbe la password e non consente a qualcuno di ingannare un utente richiedendo una modifica della password.

Inoltre, il PUT iniziale potrebbe non riuscire se c'è una richiesta in sospeso.

Aggiorniamo la password dell'utente registrato PUT / v1 / users / password: identifica l'ID utente utilizzando AccessToken.

Non è sicuro scambiare l'ID utente. L'API Restful deve identificare l'utente utilizzando AccessToken ricevuto nell'intestazione HTTP.

Esempio in spring-boot

@putMapping(value="/v1/users/password")
public ResponseEntity<String> updatePassword(@RequestHeader(value="Authorization") String token){
/* find User Using token */
/* Update Password*?
/* Return 200 */
}