RESTful resetowanie hasła

Jaki jest właściwy sposób zorganizowania zasobu RESTful do resetowania hasła?

Ten zasób ma służyć do resetowania hasła dla kogoś, kto zgubił lub zapomniał hasła. Unieważnia ich stare hasło i wysyła je e-mailem.

Dwie opcje, które mam, to:

POST /reset_password/{user_name}

lub...

POST /reset_password
   -Username passed through request body

Jestem prawie pewien, że żądanie powinno być POST. Jestem mniej przekonany, że wybrałem odpowiednią nazwę. I nie jestem pewien, czy nazwa_użytkownika powinna być przekazywana za pośrednictwem adresu URL, czy treści żądania.

AKTUALIZACJA: (dodatkowo komentarz poniżej)

Poszedłbym na coś takiego:

POST /users/:user_id/reset_password

Masz kolekcję użytkowników, w której pojedynczy użytkownik jest określony przez {user_name}. Następnie określasz akcję, na której chcesz wykonać operację, co w tym przypadku jest reset_password. To tak, jakby powiedzieć „Utwórz ( POST) nową reset_passwordakcję dla {user_name}”.

Poprzednia odpowiedź:

Poszedłbym na coś takiego:

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

Będziesz mieć dwie kolekcje, kolekcję użytkowników i kolekcję atrybutów dla każdego użytkownika. Użytkownik jest określony przez, :user_ida atrybut jest określony przez password. PUTOperacja aktualizuje skierowane członka kolekcji.

Nieuwierzytelnieni użytkownicy

Wykonujemy PUTżądanie na api/v1/account/passwordpunkcie końcowym i wymagamy parametru z odpowiednim adresem e-mail konta, aby zidentyfikować konto, dla którego użytkownik chce zresetować (zaktualizować) hasło:

PUT : /api/v1/account/password?email={[email protected]}

Uwaga: Jak wspomniał @DougDomeny w swoim komentarzu, przekazywanie wiadomości e-mail jako ciągu zapytania w adresie URL stanowi zagrożenie bezpieczeństwa. Parametry GET nie są ujawniane podczas używania https(i httpsdo takich żądań należy zawsze używać odpowiedniego połączenia), ale istnieją inne zagrożenia bezpieczeństwa. Możesz przeczytać więcej na ten temat w tym wpisie na blogu tutaj .

Przekazanie e-maila w treści żądania byłoby bezpieczniejszą alternatywą dla przekazania go jako parametru GET:

PUT : /api/v1/account/password

Treść żądania:

{
    "email": "[email protected]"
}

Odpowiedź ma 202zaakceptowaną odpowiedź, co oznacza:

Żądanie zostało przyjęte do realizacji, ale przetwarzanie nie zostało zakończone. Żądanie może ostatecznie zostać zrealizowane lub nie, ponieważ może zostać odrzucone, gdy faktycznie ma miejsce przetwarzanie. Nie ma możliwości ponownego wysłania kodu stanu z operacji asynchronicznej, takiej jak ta.

Użytkownik otrzyma wiadomość e-mail na adres, [email protected]a przetwarzanie żądania aktualizacji zależy od działań podjętych za pomocą łącza z wiadomości e-mail.

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

Otwarcie linku z tego e-maila spowoduje przekierowanie do formularza resetowania hasła w aplikacji frontonu, który używa tokena resetowania hasła z linku jako danych wejściowych dla ukrytego pola wejściowego (token jest częścią łącza jako ciąg zapytania). Kolejne pole wejściowe umożliwia użytkownikowi ustawienie nowego hasła. Drugie wejście w celu potwierdzenia nowego hasła zostanie użyte do weryfikacji na interfejsie użytkownika (aby zapobiec literówkom).

Uwaga: w e-mailu możemy również wspomnieć, że jeśli użytkownik nie zainicjował żadnego resetowania hasła, może zignorować wiadomość e-mail i normalnie korzystać z aplikacji z obecnym hasłem

Po przesłaniu formularza z nowym hasłem i tokenem jako danymi wejściowymi nastąpi proces resetowania hasła. Dane formularza zostaną ponownie wysłane z PUTżądaniem, ale tym razem z tokenem i zastąpimy hasło zasobu nową wartością:

PUT : /api/v1/account/password

Treść żądania:

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

Odpowiedź będzie 204brak zawartości odpowiedź

Serwer spełnił żądanie, ale nie musi zwracać treści encji i może chcieć zwrócić zaktualizowane metainformacje. Odpowiedź MOŻE zawierać nowe lub zaktualizowane metainformacje w postaci nagłówków encji, które, jeśli są obecne, POWINNY być skojarzone z żądanym wariantem.

Uwierzytelnieni użytkownicy

W przypadku uwierzytelnionych użytkowników, którzy chcą zmienić swoje hasło, PUTżądanie może zostać zrealizowane natychmiast, bez wiadomości e-mail (konto, dla którego aktualizujemy hasło, jest znane serwerowi). W takim przypadku formularz będzie zawierał dwa pola:

PUT : /api/v1/account/password

Treść żądania:

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

Uzyskajmy Uber-RESTful na sekundę. Dlaczego nie użyć akcji USUŃ dla hasła, aby wywołać reset? To ma sens, prawda? W końcu skutecznie odrzucasz istniejące hasło na rzecz innego.

Oznacza to, że zrobiłbyś:

DELETE /users/{user_name}/password

Teraz dwa duże zastrzeżenia:

1. HTTP DELETE ma być idempotentne (wymyślne słowo na określenie „nic wielkiego, jeśli robisz to wiele razy”). Jeśli wykonujesz standardowe czynności, takie jak wysyłanie wiadomości e-mail „Resetowanie hasła”, napotkasz problemy. Możesz obejść ten problem, oznaczając użytkownika / hasło logiczną flagą „Czy resetowano”. Przy każdym usunięciu zaznaczasz tę flagę; jeśli nie jest ustawiona , a następnie można zresetować hasło i wysyłać wiadomości e-mail. (Zauważ, że posiadanie tej flagi może mieć również inne zastosowania).

2. Nie możesz użyć HTTP DELETE przez formularz , więc będziesz musiał wykonać wywołanie AJAX i / lub tunelować DELETE przez POST.

Często nie chcesz usuwać ani niszczyć istniejącego hasła użytkownika przy pierwszym żądaniu, ponieważ mogło to zostać uruchomione (nieumyślnie lub celowo) przez użytkownika, który nie ma dostępu do wiadomości e-mail. Zamiast tego zaktualizuj token resetowania hasła w rekordzie użytkownika i wyślij go w łączu zawartym w wiadomości e-mail. Kliknięcie linku potwierdzałoby, że użytkownik otrzymał token i chciał zaktualizować swoje hasło. W idealnym przypadku byłoby to również wrażliwe na czas.

Akcją RESTful w tym przypadku byłoby POST: wyzwalanie akcji tworzenia na kontrolerze PasswordResets. Sama akcja zaktualizowałaby token i wysłała wiadomość e-mail.

Właściwie szukam odpowiedzi, nie mam zamiaru jej udzielić - ale „reset_password” brzmi dla mnie źle w kontekście REST, ponieważ jest to czasownik, a nie rzeczownik. Nawet jeśli powiesz, że wykonujesz rzeczownik „resetuj akcję” - używając tego uzasadnienia, wszystkie czasowniki są rzeczownikami.

Ponadto komuś szukającemu tej samej odpowiedzi mogło nie przyjść do głowy, że możesz uzyskać nazwę użytkownika w kontekście bezpieczeństwa i nie musisz w ogóle przesyłać jej przez adres URL lub treść, co mnie denerwuje.

Myślę, że lepszym pomysłem byłoby:

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)

W zakresie podania danych:

• Aby zresetować aktualne hasło

  • email należy podać w treści.

• Tworzenie nowego hasła (po zresetowaniu)

  • w treści należy podać nowe hasło, kod aktywacyjny oraz emailID.

• Aby zaktualizować hasło (dla zalogowanego użytkownika)

  • stare hasło, w treści należy zamieścić nowe hasło.
  • UserId w Params.
  • Auth Token w nagłówkach.

Należy wziąć pod uwagę kilka kwestii:

Resetowanie haseł nie jest idempotentne

Zmiana hasła wpływa na dane używane jako poświadczenia do jej wykonania, co w rezultacie może unieważnić przyszłe próby, jeśli żądanie zostanie po prostu powtórzone dosłownie, podczas gdy zapisane poświadczenia ulegną zmianie. Na przykład, jeśli tymczasowy token resetowania jest używany w celu umożliwienia zmiany, jak to jest zwykle w sytuacji zapomnienia hasła, ten token powinien wygasnąć po pomyślnej zmianie hasła, co ponownie unieważnia dalsze próby replikacji żądania. Dlatego podejście RESTful do zmiany hasła wydaje się być pracą lepiej dostosowaną POSTniż PUT.

Identyfikator lub e-mail w ładowaniu danych jest prawdopodobnie zbędny

Chociaż nie jest to sprzeczne z REST i może mieć jakiś specjalny cel, często nie jest konieczne określanie identyfikatora lub adresu e-mail w celu zresetowania hasła. Pomyśl o tym, dlaczego miałbyś podawać adres e-mail jako część danych do żądania, które ma przejść przez uwierzytelnienie w taki czy inny sposób? Jeśli użytkownik po prostu zmienia swoje hasło, musi się uwierzytelnić, aby to zrobić (poprzez nazwę użytkownika: hasło, e-mail: hasło lub token dostępu podany w nagłówkach). Dlatego na tym etapie mamy dostęp do ich konta. Gdyby zapomnieli hasła, otrzymaliby tymczasowy token resetowania (za pośrednictwem poczty e-mail), którego mogą użyć w szczególności jako poświadczeń do wykonania zmiany. I w tym przypadku uwierzytelnienie za pomocą tokena powinno wystarczyć do zidentyfikowania konta.

Biorąc pod uwagę wszystkie powyższe kwestie, oto, co uważam za właściwy schemat zmiany hasła RESTful:

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

Nie chciałbym mieć czegoś, co zmienia hasło i wyśle ​​im nowe, jeśli zdecydujesz się użyć metody / users / {id} / password i trzymasz się swojego pomysłu, że żądanie jest własnym zasobem. tj. / user-password-request / jest zasobem i używa PUT, informacje o użytkowniku powinny znajdować się w treści. Nie chciałbym jednak zmieniać hasła, wyślę e-mail do użytkownika, który zawiera link do strony zawierającej request_guid, który można przekazać wraz z żądaniem do POST / user / {id} / password /? Request_guid = xxxxx

To spowodowałoby zmianę hasła i nie pozwala komuś nakłonić użytkownika do żądania zmiany hasła.

Ponadto początkowe PUT może się nie powieść, jeśli istnieje oczekujące żądanie.

Aktualizujemy hasło zalogowanego użytkownika PUT / v1 / users / password - zidentyfikuj identyfikator użytkownika za pomocą AccessToken.

Wymiana identyfikatora użytkownika nie jest bezpieczna. Restful API musi identyfikować użytkownika za pomocą AccessToken otrzymanego w nagłówku HTTP.

Przykład w butach wiosennych

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