Đặt lại mật khẩu RESTful

Cách thích hợp để cấu trúc tài nguyên RESTful để đặt lại mật khẩu là gì?

Tài nguyên này có nghĩa là một công cụ đặt lại mật khẩu cho những người bị mất hoặc quên mật khẩu của họ. Nó làm mất hiệu lực mật khẩu cũ của họ và gửi mật khẩu qua email cho họ.

Hai lựa chọn mà tôi có là:

POST /reset_password/{user_name}

hoặc là...

POST /reset_password
   -Username passed through request body

Tôi khá chắc chắn rằng yêu cầu phải là một BÀI ĐĂNG. Tôi kém tự tin rằng tôi đã chọn một cái tên thích hợp. Và tôi không chắc liệu user_name có được chuyển qua URL hay nội dung yêu cầu hay không.

CẬP NHẬT: (thêm bình luận bên dưới)

Tôi sẽ đi cho một cái gì đó như thế này:

POST /users/:user_id/reset_password

Bạn có một tập hợp người dùng, trong đó người dùng duy nhất được chỉ định bởi {user_name}. Sau đó, bạn sẽ chỉ định hành động để hoạt động, trong trường hợp này là reset_password. Nó giống như nói "Tạo ( POST) một reset_passwordhành động mới cho {user_name}".

Câu trả lời trước:

Tôi sẽ đi cho một cái gì đó như thế này:

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

Bạn sẽ có hai bộ sưu tập, một bộ sưu tập người dùng và một bộ sưu tập thuộc tính cho mỗi người dùng. Người dùng được chỉ định bởi :user_idthuộc tính và thuộc tính được chỉ định bởi password. Các PUThoạt động cập nhật các thành viên giải quyết của bộ sưu tập.

Người dùng chưa được xác thực

Chúng tôi thực hiện PUTyêu cầu trên một api/v1/account/passwordđiểm cuối và yêu cầu một tham số với email tài khoản tương ứng để xác định tài khoản mà người dùng muốn đặt lại (cập nhật) mật khẩu:

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

Lưu ý: Như @DougDomeny đã đề cập trong nhận xét của mình, việc chuyển email dưới dạng chuỗi truy vấn trong url là một rủi ro bảo mật. Các tham số GET không được tiết lộ khi sử dụng https(và bạn nên luôn sử dụng httpskết nối thích hợp cho các yêu cầu như vậy) nhưng có những rủi ro bảo mật khác liên quan. Bạn có thể đọc thêm về chủ đề này trong bài đăng trên blog này ở đây .

Chuyển email trong phần thân yêu cầu sẽ là một giải pháp thay thế an toàn hơn so với việc chuyển nó dưới dạng tham số GET:

PUT : /api/v1/account/password

Nội dung yêu cầu:

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

Phản hồi có nghĩa là phản hồi 202được chấp nhận :

Yêu cầu đã được chấp nhận để xử lý, nhưng quá trình xử lý vẫn chưa hoàn tất. Yêu cầu cuối cùng có thể được thực hiện hoặc không, vì nó có thể không được phép khi quá trình xử lý thực sự diễn ra. Không có cơ sở nào để gửi lại mã trạng thái từ một hoạt động không đồng bộ như thao tác này.

Người dùng sẽ nhận được email tại email@example.comvà việc xử lý yêu cầu cập nhật phụ thuộc vào các hành động được thực hiện với liên kết từ email.

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

Việc mở liên kết từ email này sẽ chuyển hướng đến biểu mẫu đặt lại mật khẩu trên ứng dụng giao diện người dùng sử dụng mã thông báo đặt lại mật khẩu từ liên kết làm đầu vào cho trường nhập ẩn (mã thông báo là một phần của liên kết dưới dạng chuỗi truy vấn). Một trường nhập khác cho phép người dùng đặt mật khẩu mới. Đầu vào thứ hai để xác nhận mật khẩu mới sẽ được sử dụng để xác thực trên giao diện người dùng (để tránh lỗi chính tả).

Lưu ý: Trong email, chúng tôi cũng có thể đề cập rằng trong trường hợp người dùng không khởi tạo bất kỳ thiết lập lại mật khẩu nào, họ có thể bỏ qua email và tiếp tục sử dụng ứng dụng bình thường với mật khẩu hiện tại của mình

Khi biểu mẫu được gửi với mật khẩu mới và mã thông báo làm đầu vào, quá trình đặt lại mật khẩu sẽ diễn ra. Dữ liệu biểu mẫu sẽ được gửi lại cùng với một PUTyêu cầu nhưng lần này bao gồm cả mã thông báo và chúng tôi sẽ thay thế mật khẩu tài nguyên bằng một giá trị mới:

PUT : /api/v1/account/password

Nội dung yêu cầu:

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

Phản hồi sẽ là phản hồi 204không có nội dung

Máy chủ đã hoàn thành yêu cầu nhưng không cần trả lại phần thân thực thể và có thể muốn trả về thông tin cập nhật. Phản hồi CÓ THỂ bao gồm siêu thông tin mới hoặc cập nhật ở dạng tiêu đề thực thể, nếu có thì NÊN được liên kết với biến thể được yêu cầu.

Người dùng xác thực

Đối với những người dùng đã xác thực muốn thay đổi mật khẩu của họ, PUT yêu cầu có thể được thực hiện ngay lập tức mà không cần email (tài khoản mà chúng tôi đang cập nhật mật khẩu được máy chủ biết). Trong trường hợp đó, biểu mẫu sẽ gửi hai trường:

PUT : /api/v1/account/password

Nội dung yêu cầu:

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

Hãy để uber-RESTful trong một giây. Tại sao không sử dụng hành động DELETE cho mật khẩu để kích hoạt đặt lại? Có lý, phải không? Rốt cuộc, bạn đang loại bỏ một cách hiệu quả mật khẩu hiện có để chuyển sang một mật khẩu khác.

Điều đó có nghĩa là bạn sẽ làm:

DELETE /users/{user_name}/password

Bây giờ, hai lưu ý lớn:

1. HTTP DELETE được cho là không cần thiết (một từ ưa thích để nói "không có vấn đề gì lớn nếu bạn làm điều đó nhiều lần"). Nếu bạn đang làm những việc thông thường như gửi email "Đặt lại mật khẩu", thì bạn sẽ gặp sự cố. Bạn có thể giải quyết vấn đề này khi gắn thẻ người dùng / mật khẩu bằng cờ boolean "Đang đặt lại". Trên mỗi lần xóa, bạn chọn cờ này; nếu nó chưa được đặt thì bạn có thể đặt lại mật khẩu và gửi email của mình. (Lưu ý rằng có cờ này cũng có thể có các mục đích sử dụng khác.)

2. Bạn không thể sử dụng HTTP DELETE thông qua một biểu mẫu , vì vậy bạn sẽ phải thực hiện cuộc gọi AJAX và / hoặc chuyển đường hầm DELETE thông qua BÀI ĐĂNG.

Thông thường, bạn không muốn xóa hoặc hủy mật khẩu hiện có của người dùng theo yêu cầu ban đầu, vì điều này có thể đã được kích hoạt (vô tình hoặc cố ý) bởi người dùng không có quyền truy cập vào email. Thay vào đó, hãy cập nhật mã thông báo đặt lại mật khẩu trên hồ sơ người dùng và gửi mã đó trong một liên kết có trong email. Nhấp vào liên kết sẽ xác nhận người dùng đã nhận được mã thông báo và muốn cập nhật mật khẩu của họ. Tốt nhất, điều này cũng sẽ nhạy cảm với thời gian.

Hành động RESTful trong trường hợp này sẽ là POST: kích hoạt hành động tạo trên bộ điều khiển PasswordResets. Hành động tự nó sẽ cập nhật mã thông báo và gửi email.

Tôi thực sự đang tìm câu trả lời, không có nghĩa là cung cấp một câu trả lời - nhưng "reset_password" nghe có vẻ sai đối với tôi trong ngữ cảnh REST vì đó là một động từ, không phải một danh từ. Ngay cả khi bạn nói rằng bạn đang thực hiện một danh từ "đặt lại hành động" - sử dụng cách biện minh này, tất cả các động từ đều là danh từ.

Ngoài ra, có thể không xảy ra với ai đó đang tìm kiếm câu trả lời tương tự rằng bạn có thể lấy tên người dùng thông qua ngữ cảnh bảo mật và không phải gửi nó qua url hoặc nội dung, điều này khiến tôi lo lắng.

Tôi nghĩ ý tưởng tốt hơn sẽ là:

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)

Về việc cung cấp dữ liệu:

• Để đặt lại mật khẩu hiện tại

  • email nên được cung cấp trong nội dung.

• Để tạo mật khẩu mới (sau khi đặt lại)

  • mật khẩu mới, mã kích hoạt và ID email phải được cung cấp trong nội dung.

• Để cập nhật mật khẩu (cho người dùng đã đăng nhập)

  • mật khẩu cũ, mật khẩu mới nên được đề cập trong nội dung.
  • UserId trong Params.
  • Mã xác thực trong tiêu đề.

Có một số cân nhắc cần thực hiện:

Đặt lại mật khẩu không phải là công cụ quan trọng

Thay đổi mật khẩu ảnh hưởng đến dữ liệu được sử dụng làm thông tin xác thực để thực hiện nó, do đó có thể làm mất hiệu lực các lần thử trong tương lai nếu yêu cầu chỉ được lặp lại nguyên văn trong khi thông tin đăng nhập được lưu trữ đã thay đổi. Ví dụ: nếu mã thông báo đặt lại tạm thời được sử dụng để cho phép thay đổi, theo thông lệ trong tình huống quên mật khẩu, mã thông báo đó sẽ hết hạn sau khi thay đổi mật khẩu thành công, điều này lại vô hiệu hóa các nỗ lực sao chép yêu cầu tiếp theo. Do đó, một cách tiếp cận RESTful để thay đổi mật khẩu dường như là một công việc phù hợp POSThơnPUT .

ID hoặc e-mail trong tải dữ liệu có thể là dư thừa

Mặc dù điều đó không chống lại REST và có thể có một số mục đích đặc biệt, nhưng thường không cần thiết phải chỉ định ID hoặc địa chỉ email để đặt lại mật khẩu. Hãy thử nghĩ xem, tại sao bạn lại cung cấp địa chỉ email như một phần dữ liệu cho một yêu cầu được cho là phải thông qua xác thực theo cách này hay cách khác? Nếu người dùng chỉ đơn giản là thay đổi mật khẩu của họ, họ cần xác thực để làm như vậy (thông qua tên người dùng: mật khẩu, email: mật khẩu hoặc mã thông báo truy cập được cung cấp qua tiêu đề). Do đó, chúng tôi có quyền truy cập vào tài khoản của họ từ bước đó. Nếu họ quên mật khẩu, họ sẽ được cung cấp mã thông báo đặt lại tạm thời (qua email) mà họ có thể sử dụng cụ thể làm thông tin đăng nhập để thực hiện thay đổi. Và trong trường hợp này, xác thực thông qua mã thông báo sẽ đủ để xác định tài khoản của họ.

Xem xét tất cả những điều ở trên, đây là những gì tôi tin là kế hoạch thích hợp để thay đổi mật khẩu RESTful:

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

Tôi sẽ không có thứ gì đó thay đổi mật khẩu và gửi cho họ một mật khẩu mới nếu bạn quyết định sử dụng phương thức / users / {id} / password và kiên định với ý tưởng của bạn rằng yêu cầu là tài nguyên của riêng nó. tức là / user-password-request / là tài nguyên, và đang sử dụng PUT, thông tin người dùng phải nằm trong phần nội dung. Mặc dù vậy, tôi sẽ không thay đổi mật khẩu, tôi sẽ gửi email cho người dùng chứa liên kết đến trang có chứa request_guid, có thể được chuyển cùng với yêu cầu đến POST / user / {id} / password /? Request_guid = xxxxx

Điều đó sẽ thay đổi mật khẩu và nó không cho phép ai đó vòi vĩnh người dùng bằng cách yêu cầu thay đổi mật khẩu.

Cộng với PUT ban đầu có thể không thành công nếu có một yêu cầu chưa thực hiện.

Chúng tôi Cập nhật người dùng đã đăng nhập Mật khẩu PUT / v1 / users / password - xác định id người dùng bằng AccessToken.

Việc trao đổi id người dùng không an toàn. API Restful phải xác định người dùng sử dụng AccessToken nhận được trong tiêu đề HTTP.

Ví dụ trong Spring-boot

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