รีเซ็ตรหัสผ่าน RESTful

วิธีที่เหมาะสมในการจัดโครงสร้างทรัพยากร RESTful สำหรับการรีเซ็ตรหัสผ่านคืออะไร?

แหล่งข้อมูลนี้มีไว้เพื่อเป็นตัวรีเซ็ตรหัสผ่านสำหรับผู้ที่ทำรหัสผ่านหายหรือลืม รหัสผ่านเดิมทำให้รหัสผ่านไม่ถูกต้องและส่งรหัสผ่านให้ทางอีเมล

สองตัวเลือกที่ฉันมีคือ:

POST /reset_password/{user_name}

หรือ...

POST /reset_password
   -Username passed through request body

ฉันค่อนข้างมั่นใจว่าคำขอควรเป็น POST ฉันไม่ค่อยมั่นใจว่าฉันได้เลือกชื่อที่เหมาะสมแล้ว และฉันไม่แน่ใจว่าควรส่ง user_name ผ่าน URL หรือเนื้อหาคำขอ

UPDATE: (แสดงความคิดเห็นเพิ่มเติมด้านล่าง)

ฉันจะไปหาอะไรแบบนี้:

POST /users/:user_id/reset_password

คุณมีกลุ่มผู้ใช้โดยที่ผู้ใช้รายเดียวถูกระบุโดยไฟล์{user_name}. reset_passwordจากนั้นคุณจะต้องระบุให้การดำเนินการที่จะดำเนินการในซึ่งในกรณีนี้คือ ก็เหมือนกับการพูดว่า "Create ( POST) a new reset_passwordaction for {user_name}"

คำตอบก่อนหน้า:

ฉันจะไปหาอะไรแบบนี้:

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

คุณมีสองคอลเลกชันคอลเลกชันผู้ใช้และคอลเล็กชันแอตทริบิวต์สำหรับผู้ใช้แต่ละคน ผู้ใช้จะถูกระบุโดยและแอตทริบิวต์ที่ระบุไว้โดย:user_id passwordการPUTดำเนินการนี้จะอัพเดตสมาชิกที่ระบุแอดเดรสของคอลเล็กชัน

ผู้ใช้ที่ไม่ได้ตรวจสอบสิทธิ์

เราทำการPUTร้องขอในapi/v1/account/passwordปลายทางและต้องการพารามิเตอร์พร้อมอีเมลบัญชีที่เกี่ยวข้องเพื่อระบุบัญชีที่ผู้ใช้ต้องการรีเซ็ต (อัปเดต) รหัสผ่าน:

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

บันทึก: ตามที่@DougDomenyกล่าวถึงในความคิดเห็นของเขาที่ส่งอีเมลเป็นสตริงข้อความค้นหาใน url ถือเป็นความเสี่ยงด้านความปลอดภัย พารามิเตอร์ GET จะไม่ถูกเปิดเผยเมื่อใช้งานhttps(และคุณควรใช้การhttpsเชื่อมต่อที่เหมาะสมสำหรับคำขอดังกล่าวเสมอ) แต่มีความเสี่ยงด้านความปลอดภัยอื่น ๆ ที่เกี่ยวข้อง คุณสามารถอ่านเพิ่มเติมเกี่ยวกับหัวข้อนี้ในบล็อกโพสต์ที่นี่

การส่งอีเมลในเนื้อหาคำขอจะเป็นทางเลือกที่ปลอดภัยกว่าในการส่งเป็นพารามิเตอร์ GET:

PUT : /api/v1/account/password

ขอเนื้อหา:

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

คำตอบมีความหมายตอบ202รับที่ยอมรับ :

คำขอได้รับการยอมรับสำหรับการประมวลผล แต่การประมวลผลยังไม่เสร็จสมบูรณ์ ในที่สุดคำขออาจจะดำเนินการหรือไม่ก็ได้เนื่องจากอาจไม่ได้รับอนุญาตเมื่อการประมวลผลเกิดขึ้นจริง ไม่มีสิ่งอำนวยความสะดวกสำหรับการส่งรหัสสถานะซ้ำจากการดำเนินการแบบอะซิงโครนัสเช่นนี้

ผู้ใช้จะได้รับอีเมลที่ email@example.comและการประมวลผลคำขออัปเดตขึ้นอยู่กับการดำเนินการกับลิงก์จากอีเมล

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

การเปิดลิงก์จากอีเมลนี้จะนำไปยังแบบฟอร์มรีเซ็ตรหัสผ่านบนแอปพลิเคชันส่วนหน้าที่ใช้โทเค็นรีเซ็ตรหัสผ่านจากลิงก์เป็นอินพุตสำหรับฟิลด์อินพุตที่ซ่อนอยู่ (โทเค็นเป็นส่วนหนึ่งของลิงก์เป็นสตริงข้อความค้นหา) ช่องป้อนข้อมูลอื่นอนุญาตให้ผู้ใช้ตั้งรหัสผ่านใหม่ อินพุตที่สองเพื่อยืนยันรหัสผ่านใหม่จะถูกใช้สำหรับการตรวจสอบความถูกต้องในส่วนหน้า (เพื่อป้องกันการพิมพ์ผิด)

บันทึก: ในอีเมลเราสามารถพูดถึงว่าในกรณีที่ผู้ใช้ไม่ได้เริ่มต้นการรีเซ็ตรหัสผ่านใด ๆ เขา / เธอสามารถเพิกเฉยต่ออีเมลและใช้แอปพลิเคชันได้ตามปกติด้วยรหัสผ่านปัจจุบันของเขา / เธอ

เมื่อส่งแบบฟอร์มพร้อมรหัสผ่านใหม่และโทเค็นเป็นอินพุตกระบวนการรีเซ็ตรหัสผ่านจะเกิดขึ้น ข้อมูลแบบฟอร์มจะถูกส่งไปพร้อมกับPUTคำร้องขออีกครั้ง แต่คราวนี้รวมถึงโทเค็นและเราจะแทนที่รหัสผ่านทรัพยากรด้วยค่าใหม่:

PUT : /api/v1/account/password

ขอเนื้อหา:

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

การตอบสนองจะเป็น204เนื้อหาที่ไม่ตอบสนอง

เซิร์ฟเวอร์ได้ดำเนินการตามคำขอแล้ว แต่ไม่จำเป็นต้องส่งคืนเอนทิตี - ร่างกายและอาจต้องการส่งคืนข้อมูลเมตาที่อัปเดต การตอบกลับอาจรวมข้อมูลเมตาเนียใหม่หรือที่อัปเดตในรูปแบบของส่วนหัวเอนทิตีซึ่งหากมีอยู่ควรเชื่อมโยงกับตัวแปรที่ร้องขอ

ผู้ใช้ที่พิสูจน์ตัวตน

สำหรับผู้ใช้ที่ได้รับการรับรองความถูกต้องและต้องการเปลี่ยนรหัสผ่านPUTสามารถดำเนินการตามคำขอได้ทันทีโดยไม่ต้องใช้อีเมล (บัญชีที่เรากำลังอัปเดตรหัสผ่านนั้นเป็นที่รู้จักในเซิร์ฟเวอร์) ในกรณีนี้แบบฟอร์มจะส่งสองช่อง:

PUT : /api/v1/account/password

ขอเนื้อหา:

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

ขอ uber-RESTful สักวินาที ทำไมไม่ใช้การดำเนินการ DELETE สำหรับรหัสผ่านเพื่อเริ่มการรีเซ็ต เข้าท่าใช่มั้ย? ท้ายที่สุดคุณกำลังทิ้งรหัสผ่านที่มีอยู่อย่างมีประสิทธิภาพเพื่อสนับสนุนรหัสผ่านอื่น

นั่นหมายความว่าคุณจะทำ:

DELETE /users/{user_name}/password

ตอนนี้สองคำเตือนใหญ่:

1. HTTP DELETE ควรเป็น idempotent (คำแฟนซีสำหรับพูดว่า "ไม่มีเรื่องใหญ่ถ้าคุณทำหลายครั้ง") หากคุณกำลังดำเนินการตามมาตรฐานเช่นการส่งอีเมล "รีเซ็ตรหัสผ่าน" แสดงว่าคุณกำลังประสบปัญหา คุณสามารถหลีกเลี่ยงการแท็กผู้ใช้ / รหัสผ่านนี้ได้ด้วยแฟล็ก "Is Reset" แบบบูลีน ในการลบทุกครั้งคุณตรวจสอบแฟล็กนี้ ถ้ามันไม่ได้ตั้งค่าแล้วคุณสามารถรีเซ็ตรหัสผ่านและส่งอีเมลของคุณ (โปรดทราบว่าการมีแฟล็กนี้อาจมีประโยชน์อื่น ๆ ด้วย)

2. คุณไม่สามารถใช้ HTTP DELETE ผ่านแบบฟอร์มได้ดังนั้นคุณจะต้องทำการโทร AJAX และ / หรืออุโมงค์ DELETE ผ่าน POST

บ่อยครั้งที่คุณไม่ต้องการลบหรือทำลายรหัสผ่านที่มีอยู่ของผู้ใช้ในคำขอเริ่มต้นเนื่องจากสิ่งนี้อาจถูกกระตุ้น (โดยไม่ได้ตั้งใจหรือโดยเจตนา) โดยผู้ใช้ที่ไม่มีสิทธิ์เข้าถึงอีเมล ให้อัปเดตโทเค็นรีเซ็ตรหัสผ่านในบันทึกผู้ใช้แทนและส่งไปในลิงก์ที่รวมอยู่ในอีเมล การคลิกลิงก์จะเป็นการยืนยันว่าผู้ใช้ได้รับโทเค็นและต้องการอัปเดตรหัสผ่าน ตามหลักการแล้วนี่จะเป็นเรื่องละเอียดอ่อนเช่นกัน

การดำเนินการ RESTful ในกรณีนี้จะเป็น POST: เรียกใช้การดำเนินการสร้างบนตัวควบคุม PasswordResets การดำเนินการจะอัปเดตโทเค็นและส่งอีเมล

ฉันกำลังมองหาคำตอบจริง ๆ ไม่ใช่หมายถึงการให้คำตอบ แต่ "reset_password" ฟังดูผิดสำหรับฉันในบริบท REST เนื่องจากเป็นคำกริยาไม่ใช่คำนาม แม้ว่าคุณจะบอกว่าคุณกำลังใช้คำนาม "รีเซ็ตการกระทำ" - โดยใช้เหตุผลนี้คำกริยาทั้งหมดเป็นคำนาม

นอกจากนี้อาจไม่เกิดขึ้นกับคนที่ค้นหาคำตอบเดียวกับที่คุณอาจได้รับชื่อผู้ใช้ผ่านบริบทความปลอดภัยและไม่จำเป็นต้องส่งผ่าน url หรือ body เลยซึ่งทำให้ฉันรู้สึกกังวล

ฉันคิดว่าความคิดที่ดีกว่าคือ:

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)

เกี่ยวกับการจัดหาข้อมูล:

• รีเซ็ตรหัสผ่านปัจจุบัน

  • ควรได้รับอีเมลในร่างกาย

• เพื่อสร้างรหัสผ่านใหม่ (หลังจากรีเซ็ต)

  • ควรระบุรหัสผ่านรหัสเปิดใช้งานและรหัสอีเมลใหม่ในเนื้อความ

• ในการอัปเดตรหัสผ่าน (สำหรับผู้ใช้ล็อกอิน)

  • รหัสผ่านเก่าควรระบุรหัสผ่านใหม่ในเนื้อหา
  • UserId ใน Params
  • Auth Token ในส่วนหัว

มีข้อควรพิจารณาบางประการดังนี้

การรีเซ็ตรหัสผ่านไม่ได้มีอยู่

การเปลี่ยนรหัสผ่านจะส่งผลต่อข้อมูลที่ใช้เป็นข้อมูลรับรองในการดำเนินการซึ่งผลที่ตามมาอาจทำให้ความพยายามในอนาคตเป็นโมฆะหากมีการขอซ้ำคำต่อคำในขณะที่ข้อมูลรับรองที่จัดเก็บมีการเปลี่ยนแปลง ตัวอย่างเช่นหากมีการใช้โทเค็นรีเซ็ตชั่วคราวเพื่ออนุญาตการเปลี่ยนแปลงเนื่องจากเป็นเรื่องปกติในสถานการณ์ที่ลืมรหัสผ่านโทเค็นนั้นควรจะหมดอายุเมื่อเปลี่ยนรหัสผ่านสำเร็จซึ่งจะลบล้างความพยายามในการจำลองคำขออีกครั้ง ดังนั้นวิธีการที่สงบไปสู่การเปลี่ยนแปลงรหัสผ่านน่าจะเป็นงานที่ดีเหมาะสำหรับกว่าPOSTPUT

ID หรืออีเมลในการโหลดข้อมูลอาจซ้ำซ้อน

แม้ว่าจะไม่ได้ต่อต้าน REST และอาจมีจุดประสงค์พิเศษบางอย่าง แต่ก็มักไม่จำเป็นต้องระบุ ID หรือที่อยู่อีเมลสำหรับการรีเซ็ตรหัสผ่าน ลองคิดดูทำไมคุณถึงให้ที่อยู่อีเมลเป็นส่วนหนึ่งของข้อมูลในคำขอที่ควรผ่านการตรวจสอบสิทธิ์ไม่ทางใดก็ทางหนึ่ง หากผู้ใช้เพียงแค่เปลี่ยนรหัสผ่านพวกเขาจำเป็นต้องตรวจสอบสิทธิ์เพื่อดำเนินการดังกล่าว (ผ่านชื่อผู้ใช้: รหัสผ่านอีเมล: รหัสผ่านหรือโทเค็นการเข้าถึงที่ให้ไว้ทางส่วนหัว) ดังนั้นเราจึงสามารถเข้าถึงบัญชีของพวกเขาได้จากขั้นตอนนั้น หากพวกเขาลืมรหัสผ่านพวกเขาจะได้รับโทเค็นรีเซ็ตชั่วคราว (ทางอีเมล) ซึ่งพวกเขาสามารถใช้เป็นข้อมูลรับรองเพื่อทำการเปลี่ยนแปลงโดยเฉพาะ และในกรณีนี้การพิสูจน์ตัวตนผ่านโทเค็นก็น่าจะเพียงพอที่จะระบุบัญชีของพวกเขาได้

เมื่อพิจารณาจากข้างต้นทั้งหมดนี่คือสิ่งที่ฉันเชื่อว่าเป็นรูปแบบที่เหมาะสมในการเปลี่ยนรหัสผ่าน RESTful:

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

ฉันจะไม่มีบางอย่างที่เปลี่ยนรหัสผ่านและส่งรหัสใหม่ให้หากคุณตัดสินใจใช้วิธี / users / {id} / รหัสผ่านและยึดติดกับแนวคิดของคุณว่าคำขอเป็นทรัพยากรของตัวเอง เช่น / user-password-request / เป็นทรัพยากรและใช้ PUT ข้อมูลผู้ใช้ควรอยู่ในเนื้อความ ฉันจะไม่เปลี่ยนรหัสผ่าน แต่ Id จะส่งอีเมลไปยังผู้ใช้ซึ่งมีลิงก์ไปยังหน้าที่มี request_guid ซึ่งสามารถส่งต่อไปพร้อมกับคำขอไปยัง POST / user / {id} / password /? request_guid = xxxxx

ซึ่งจะเปลี่ยนรหัสผ่านและไม่อนุญาตให้ใครบางคนบีบผู้ใช้โดยขอเปลี่ยนรหัสผ่าน

นอกจากนี้การ PUT ครั้งแรกอาจล้มเหลวหากมีคำขอที่ค้างอยู่

เราอัปเดตรหัสผ่านผู้ใช้ที่เข้าสู่ระบบ PUT / v1 / ผู้ใช้ / รหัสผ่าน - ระบุ ID ผู้ใช้โดยใช้ AccessToken

การแลกเปลี่ยน ID ผู้ใช้ไม่ปลอดภัย Restful API ต้องระบุผู้ใช้โดยใช้ AccessToken ที่ได้รับในส่วนหัว HTTP

ตัวอย่างในสปริงบูต

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