Restful पासवर्ड रीसेट

107

पासवर्ड रीसेट करने के लिए एक RESTful संसाधन की संरचना करने का उचित तरीका क्या है?

यह संसाधन किसी ऐसे व्यक्ति के लिए पासवर्ड रीसेट करने वाला है जो अपना पासवर्ड खो चुका है या भूल गया है। यह उनके पुराने पासवर्ड को अमान्य कर देता है और उन्हें एक पासवर्ड ई-मेल कर देता है।

मेरे पास दो विकल्प हैं:

POST /reset_password/{user_name}

या ...

POST /reset_password
   -Username passed through request body

मुझे पूरा यकीन है कि अनुरोध एक POST होना चाहिए। मुझे कम विश्वास है कि मैंने एक उपयुक्त नाम का चयन किया है। और मुझे यकीन नहीं है कि user_name URL या अनुरोध निकाय के माध्यम से पारित किया जाना चाहिए।

rest password-recovery

— क्रिस डुट्रो
स्रोत

54

अद्यतन: (आगे टिप्पणी करने के लिए)

मैं कुछ इस तरह के लिए जाना जाएगा:

POST /users/:user_id/reset_password

आपके पास उपयोगकर्ताओं का एक संग्रह है, जहां एकल उपयोगकर्ता द्वारा निर्दिष्ट किया गया है {user_name}। फिर आप उस पर कार्रवाई करने के लिए निर्दिष्ट करेंगे, जो इस मामले में है reset_password। यह "बनाने ( POST) के लिए एक नई reset_passwordकार्रवाई " कहने जैसा है {user_name}।

पिछला उत्तर:

मैं कुछ इस तरह के लिए जाना जाएगा:

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

आपके पास दो संग्रह, एक उपयोगकर्ता संग्रह और प्रत्येक उपयोगकर्ता के लिए एक विशेषता संग्रह होगा। उपयोगकर्ता द्वारा निर्दिष्ट किया गया है :user_idऔर विशेषता द्वारा निर्दिष्ट किया गया है password। PUTआपरेशन संग्रह का संबोधित सदस्य अद्यतन करता है।

— डैनियल वासल्लो
स्रोत

10

मैं आपके अपडेट किए गए (POST) समाधान से सहमत हूं। PUT अनुरोधों को निष्प्रभावी होना चाहिए (अर्थात बार-बार अनुरोधों के परिणाम को प्रभावित नहीं करना चाहिए)। यह POST अनुरोधों के मामले में नहीं है।

— रॉस मैकफर्लेन

16

मैं reset_password को password_reset में बदल दूंगा

— रिचर्ड

9

लोगों को लटकाओ ... क्या यह अनिवार्य रूप से किसी के पासवर्ड को रीसेट करने की अनुमति नहीं देगा? जैसे, यदि यह किसी ऐसे व्यक्ति के लिए है जो वर्तमान पासवर्ड भूल जाता है, तो प्रभावित उपयोगकर्ता को वर्तमान पासवर्ड से प्रमाणित नहीं किया जा सकता है। तो अनिवार्य रूप से इसका मतलब है कि यह एपीआई किसी भी पासवर्ड को स्वीकार नहीं कर सकता है - इस प्रकार किसी को भी किसी के पासवर्ड को रीसेट करने में सक्षम बनाता है, और अगर एपीआई इसे वापस करता है, तो किसी भी ज्ञात उपयोगकर्ता के पासवर्ड को पकड़ें ??? या मैं कुछ याद आ रही है

— transient_loop

39

/ User / {id} / पासवर्ड और इस तरह की समस्या यह है कि आप उपयोगकर्ता की "id" नहीं जान सकते। आपको उनका "उपयोगकर्ता नाम" या "ईमेल" या "फोन" पता होगा, लेकिन "आईडी" नहीं।

— coolaj86

17

इस दृष्टिकोण के साथ मौलिक दोष यह है कि यह मानता है कि आप पहले से ही उपयोगकर्ता आईडी जानते हैं। यह कुछ परिस्थितियों में सही होगा लेकिन आप इसे तब कैसे करते हैं जब उपयोगकर्ता नाम या उपयोगकर्ता आईडी ज्ञात नहीं है यदि उपयोगकर्ता को केवल रीसेट के लिए एक ईमेल निर्दिष्ट करने की आवश्यकता है।

— अलापिन

94

अनधिकृत उपयोगकर्ता

हम 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कोई सामग्री प्रतिक्रिया नहीं होगी

सर्वर ने अनुरोध पूरा कर लिया है, लेकिन उसे निकाय-निकाय को वापस करने की आवश्यकता नहीं है, और अद्यतन मेटैनफॉर्मेशन वापस करना चाह सकता है। प्रतिक्रिया MAY में इकाई-हेडर के रूप में नए या अपडेट किए गए मेटैनफॉर्मेशन शामिल हैं, जो कि यदि वर्तमान SHOULD को अनुरोधित संस्करण के साथ जोड़ा जाता है।

प्रमाणीकृत उपयोगकर्ता

प्रामाणिक उपयोगकर्ताओं के लिए जो अपना पासवर्ड बदलना चाहते हैं, PUTअनुरोध ईमेल के बिना तुरंत किया जा सकता है (जिस खाते के लिए हम पासवर्ड अपडेट कर रहे हैं वह सर्वर को पता है)। इस तरह के मामले में फॉर्म दो फ़ील्ड सबमिट करेगा:

PUT : /api/v1/account/password

अनुरोध निकाय:

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

— विल्ट
स्रोत

अपने पहले पैराग्राफ में आप PUT कहते हैं लेकिन नीचे दिया गया उदाहरण DELETE कहता है। कौन सा सही है?

— जिपरसन

यह URL पर ईमेल पते को उजागर करता है, जो JSON डेटा को अधिक सुरक्षित करेगा।

— डौग डोमेनी

@DougDomeny हाँ, json डेटा के रूप में ईमेल भेजना शायद बेहतर होगा। मैंने इसे वैकल्पिक अधिक सुरक्षित विकल्प के रूप में उत्तर में जोड़ा, अन्यथा समाधान समान हो सकता है।

— विल्ट

@ रजाई: यह एक PATCH ऑपरेशन नहीं होगा? PUT को पूरा संसाधन भेजने की आवश्यकता है

— j10

1

@ तजतनशाह अच्छा बिंदु। यह लिखते समय मुझे लगा कि PUT बेहतर होगा, लेकिन मुझे ठीक-ठीक याद नहीं है। मैं आपके तर्क से सहमत हूं कि पैच इस मामले के लिए अधिक उपयुक्त हो सकता है।

— विल्ट

18

चलो एक दूसरे के लिए uber-RESTful प्राप्त करें। रीसेट को ट्रिगर करने के लिए पासवर्ड के लिए DELETE कार्रवाई का उपयोग क्यों न करें? समझ में आता है, है ना? आखिरकार, आप मौजूदा पासवर्ड को दूसरे के पक्ष में प्रभावी रूप से छोड़ रहे हैं।

इसका मतलब है कि आप ऐसा करेंगे:

DELETE /users/{user_name}/password

अब, दो बड़े चेतावनी:

HTTP DELETE को माना जाता है कि ("अगर आप इसे कई बार करते हैं तो कोई बड़ी बात नहीं" कहने के लिए एक फैंसी शब्द है)। यदि आप "पासवर्ड रीसेट" ईमेल भेजने जैसे मानक सामान कर रहे हैं, तो आप समस्याओं में भाग लेंगे। आप उपयोगकर्ता / पासवर्ड को बूलियन "इस रीसेट" ध्वज के साथ टैग कर सकते हैं। प्रत्येक हटाने पर, आप इस ध्वज की जांच करते हैं; यदि यह सेट नहीं है तो आप पासवर्ड रीसेट कर सकते हैं और अपना ईमेल भेज सकते हैं। (ध्यान दें कि इस ध्वज के अन्य उपयोग भी हो सकते हैं।)
आप एक फॉर्म के माध्यम से HTTP DELETE का उपयोग नहीं कर सकते हैं , इसलिए आपको POST के माध्यम से एक AJAX कॉल और / या DELETE करना होगा।

— क्रेग वॉकर
स्रोत

9

दिलचस्प विचार। हालाँकि मुझे DELETEयहाँ अच्छी तरह से फिटिंग दिखाई नहीं दे रही है। आप पासवर्ड को बेतरतीब ढंग से उत्पन्न एक के साथ प्रतिस्थापित कर रहे होंगे, मुझे लगता है, इसलिए DELETEभ्रामक हो सकता है। मुझे पसंद है Create (POST) new reset_password action, जहां आप जिस संज्ञा (संसाधन) पर कार्य कर रहे हैं वह "रीसेट_पासवर्ड कार्रवाई" है। यह ईमेल भेजने के लिए अच्छी तरह से फिट बैठता है, क्योंकि कार्रवाई इन सभी निम्न-स्तरीय विवरणों को एन्क्रिप्ट करती है। POSTउदासीन नहीं है।

— डैनियल वेसलो

मुझे प्रस्ताव पसंद है। अंक 1 में सशर्त अनुरोधों का उपयोग करके निपटा जा सकता है, अर्थात् HEAD जो ETag + DELETE और इफ-मैच हैडर भेजता है। अगर कोई ऐसे पासवर्ड को हटाने की कोशिश करता है जो अब सक्रिय नहीं है, तो उसे 412 मिलेगा।

— व्हिस्कीसिएर

1

मैं DELETE से बचूंगा। आप अपडेट कर रहे हैं, क्योंकि एक ही इकाई / अवधारणा को एक नया मूल्य मिलेगा। लेकिन वास्तव में, आमतौर पर यह अब भी नहीं हो रहा है, लेकिन केवल बाद के अलग अनुरोध में नया पासवर्ड भेजने के बाद (रीसेट पासवर्ड मेल के बाद) - आजकल कोई भी मेल द्वारा नया पासवर्ड नहीं भेजता है, लेकिन नए अनुरोध में इसे रीसेट करने के लिए एक टोकन एक दिया टोकन, है ना?

— antonio.fornie

11

यदि रीसेट अनुरोध करने के बाद उपयोगकर्ता को अपना पासवर्ड याद है तो क्या होगा? यादृच्छिक खातों को रीसेट करने की कोशिश कर रहे कुछ बॉट के बारे में क्या? उपयोगकर्ता को ऐसे मामले में रीसेट ईमेल को अनदेखा करने की अनुमति दी जानी चाहिए (ईमेल को ऐसा कहना चाहिए), जिसका अर्थ है कि आपके सिस्टम को पासवर्ड को स्वयं से हटाना या अपडेट नहीं करना चाहिए।

— मैक्सिमे लवल

3

@MaximeLaval यह बहुत अच्छी बात है। वास्तव में, आप "एक रीसेट अनुरोध बना रहे हैं", जो एक POST होगा।

— क्रेग वॉकर

12

अक्सर आप प्रारंभिक अनुरोध पर उपयोगकर्ता के मौजूदा पासवर्ड को नष्ट या नष्ट नहीं करना चाहते हैं, क्योंकि यह उस उपयोगकर्ता द्वारा ट्रिगर (अनजाने या जानबूझकर) हो सकता है जिनके पास ईमेल तक पहुंच नहीं है। इसके बजाय, उपयोगकर्ता रिकॉर्ड पर रीसेट पासवर्ड टोकन अपडेट करें और इसे ईमेल में शामिल लिंक में भेजें। लिंक पर क्लिक करने से उपयोगकर्ता को टोकन प्राप्त होने की पुष्टि होती है और वह अपना पासवर्ड अपडेट करना चाहता है। आदर्श रूप में, यह समय के साथ-साथ संवेदनशील भी होगा।

इस मामले में RESTful कार्रवाई एक POST होगी: PasswordResets कंट्रोलर पर क्रिएट एक्शन को ट्रिगर करना। कार्रवाई स्वयं टोकन को अपडेट करेगी और एक ईमेल भेज देगी।

— मार्क स्वार्डस्ट्रॉम
स्रोत

9

मैं वास्तव में एक उत्तर की तलाश कर रहा हूं, जिसका अर्थ एक प्रदान करना नहीं है - लेकिन "रीसेट_पासवर्ड" मुझे एक आरईएसटी संदर्भ में गलत लगता है क्योंकि यह एक क्रिया है, एक संज्ञा नहीं। यहां तक कि अगर आप कहते हैं कि आप "रीसेट कार्रवाई" संज्ञा कर रहे हैं - इस औचित्य का उपयोग करके, सभी क्रियाएं संज्ञाएं हैं।

इसके अलावा, यह उसी उत्तर की खोज करने वाले किसी व्यक्ति को नहीं हुआ होगा, जिसे आप सुरक्षा संदर्भ के माध्यम से उपयोगकर्ता नाम प्राप्त करने में सक्षम हो सकते हैं, और इसे यूआरएल या शरीर के माध्यम से बिल्कुल भी नहीं भेजना होगा, जो मुझे परेशान करता है।

— orbfish
स्रोत

4

शायद reset-passwordएक क्रिया की तरह लगता है, लेकिन आप password-resetइसे संज्ञा बनाने के लिए आसानी से इसे उल्टा कर सकते हैं ( )। और यदि आपने इवेंट सोर्सिंग का उपयोग करके अपने एप्लिकेशन को मॉडल किया है या यहां तक कि अगर आपके पास किसी भी प्रकार की ऑडिटिंग है, तो यह समझ में आता है कि आपके पास वास्तव में इस नाम के साथ एक वास्तविक इकाई है और यहां तक कि उपयोगकर्ताओं या प्रशासकों को देखने के लिए उस पर GETs भी दे सकते हैं। इतिहास (जाहिर है पासवर्ड पाठ मास्किंग)। मुझे बिल्कुल भी परेशान नहीं करता है। और सर्वर साइड पर उपयोगकर्ता नाम को स्वचालित रूप से चुनने के लिए - आप कर सकते हैं, लेकिन फिर आप प्रशासन / प्रतिरूपण जैसी चीजों को कैसे संभालते हैं?

— हारून पकड़ा गया

1

REST में क्रिया का उपयोग करने में कुछ भी गलत नहीं है। जब तक उपयुक्त स्थानों में इसका उपयोग किया जाता है। मुझे लगता है कि यह एक रेजिस्टर की तुलना में अधिक नियंत्रक है, और reset-passwordइसका प्रभाव अच्छी तरह से वर्णन करने का प्रबंधन करता है।

— एंडर्स Andstman

6

मुझे लगता है कि बेहतर विचार होगा:

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)

डेटा की आपूर्ति के बारे में:

वर्तमान पासवर्ड रीसेट करने के लिए
- ईमेल बॉडी में दिया जाना चाहिए।
नया पासवर्ड बनाने के लिए (रीसेट के बाद)
- नया पासवर्ड, एक्टिवेशन कोड और ईमेलआईडी बॉडी में दिया जाना चाहिए।
पासवर्ड अपडेट करने के लिए (लॉग इन उपयोगकर्ता के लिए)
- पुराने पासवर्ड, नए पासवर्ड का उल्लेख किया जाना चाहिए।
- Params में UserId।
- हेडर में प्रामाणिक टोकन।

— codesnooker
स्रोत

2

जैसा कि अन्य उत्तरों में टिप्पणी की गई है, "DELETE / api / v1 / account / password" एक बुरा विचार है, क्योंकि कोई भी किसी के पासवर्ड को रीसेट कर सकता है।

— 18

पासवर्ड रीसेट करने के लिए हमें एक पंजीकृत ईमेल आईडी की आवश्यकता होती है। जब तक हम फेसबुक जैसी साइट नहीं चला रहे हैं और किसी भी माध्यम से ईमेल आईडी एकत्र नहीं करेंगे, तब तक अज्ञात उपयोगकर्ता की ईमेल आईडी जानने की संभावना बहुत गंभीर है। फिर उसके अनुसार सुरक्षा नीतियों को परिभाषित किया जाएगा। किसी पासवर्ड को रीसेट करने के लिए आपका क्या सुझाव है?

— कोडन्यूकर

5

लेने के लिए कुछ विचार हैं:

पासवर्ड रीसेट करने वाले व्यक्ति बेरोजगार नहीं होते हैं

एक पासवर्ड परिवर्तन इसे निष्पादित करने के लिए क्रेडेंशियल के रूप में उपयोग किए गए डेटा को प्रभावित करता है, जिसके परिणामस्वरूप भविष्य के प्रयासों को अमान्य कर सकता है यदि अनुरोध केवल दोहराए गए हैं जबकि संग्रहीत क्रेडेंशियल्स बदल गए हैं। उदाहरण के लिए, यदि एक अस्थायी रीसेट टोकन का उपयोग परिवर्तन की अनुमति देने के लिए किया जाता है, क्योंकि यह एक भूल पासवर्ड स्थिति में प्रथागत है, तो टोकन को सफल पासवर्ड परिवर्तन पर समाप्त किया जाना चाहिए, जो फिर से अनुरोध को दोहराने पर आगे के प्रयासों को शून्य करता है। इस प्रकार एक पासवर्ड परिवर्तन के लिए Restful दृष्टिकोण एक नौकरी के लिए बेहतर अनुकूल POSTलगता है PUT।

डेटा लोड में आईडी या ई-मेल शायद बेमानी है

हालाँकि यह REST के खिलाफ नहीं है और इसका कुछ विशेष उद्देश्य हो सकता है, लेकिन पासवर्ड रीसेट के लिए आईडी या ईमेल पता निर्दिष्ट करना अक्सर अनावश्यक होता है। इसके बारे में सोचें, आप डेटा के हिस्से के रूप में ईमेल पते को एक अनुरोध पर क्यों प्रदान करेंगे, जिसे प्रमाणीकरण के माध्यम से जाना चाहिए? यदि उपयोगकर्ता बस अपना पासवर्ड बदल रहा है तो उन्हें ऐसा करने के लिए प्रमाणित करने की आवश्यकता है (उपयोगकर्ता नाम: पासवर्ड, ईमेल: पासवर्ड, या हेडर के माध्यम से प्रदान किए गए टोकन)। इसलिए, हमारे पास उस चरण से उनके खाते तक पहुंच है। यदि वे अपना पासवर्ड भूल गए थे, तो उन्हें अस्थायी रीसेट टोकन (ईमेल के माध्यम से) प्रदान किया जाता था, जिसे वे परिवर्तन करने के लिए विशेष रूप से क्रेडेंशियल के रूप में उपयोग कर सकते हैं। और इस मामले में टोकन के माध्यम से प्रमाणीकरण उनके खाते की पहचान करने के लिए पर्याप्त होना चाहिए।

उपरोक्त सभी को यहां ध्यान में रखते हुए कि मैं एक उचित पासवर्ड परिवर्तन के लिए उचित योजना मानता हूं:

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

— माइकल एकोका
स्रोत

एक बयान जो एक प्लेसहोल्डर को आउट-ऑफ-बैंड जानकारी की आवश्यकता होती है, वह पूरी तरह सच नहीं है। एक विशेष मीडिया प्रकार अनुरोध या प्रतिक्रिया के कुछ तत्वों के वाक्यविन्यास और शब्दार्थ का वर्णन कर सकता है। इस प्रकार एक मीडिया प्रकार के लिए यह परिभाषित करना संभव है कि एक निश्चित क्षेत्र में शामिल यूआरआई कुछ डेटा के लिए प्लेसहोल्डर को परिभाषित कर सकता है और शब्दार्थ आगे परिभाषित करता है कि प्लेसहोल्डर के बजाय एक एन्कोडेड उपयोगकर्ता-ईमेल या क्या शामिल नहीं होना चाहिए। ग्राहक और सर्वर जो इस बात का सम्मान करते हैं कि मीडिया प्रकार अभी भी रैस्टफुल आर्किटेक्चर सिद्धांतों के अनुरूप होगा।

— रोमन वोटर 10

1

के बारे में POSTबनाम PUT आरएफसी 7231 निर्दिष्ट करता है कि एक आंशिक अद्यतन दो संसाधनों की ओवरलैपिंग डेटा के माध्यम से प्राप्त किया जा सकता है लेकिन यह संदिग्ध है, तो कुछ इस तरह है /v1/account/passwordवास्तव में एक अच्छा संसाधन वास्तव में की भरपाई करता है। जैसा POSTकि वेब का स्विस-सेना-चाकू है जिसका उपयोग किया जा सकता है यदि अन्य तरीकों में से कोई भी संभव नहीं है, PATCHतो नया पासवर्ड सेट करने के लिए विचार करना भी एक विकल्प हो सकता है।

— रोमन वोटर

जब वे अपना पासवर्ड नहीं जानते, तो पासवर्ड रीसेट का अनुरोध करने के लिए URL के बारे में क्या?

— डैन कार्टर

2

यदि आपके पास / उपयोगकर्ताओं / {आईडी} / पासवर्ड विधि का उपयोग करने का निर्णय लिया जाता है, और आपके विचार से अनुरोध है कि अनुरोध स्वयं का एक संसाधन है, तो मुझे पासवर्ड बदलने और उन्हें नया भेजने के लिए कुछ नहीं होगा। अर्थात / उपयोगकर्ता-पासवर्ड-अनुरोध / संसाधन है, और PUT का उपयोग कर रहा है, उपयोगकर्ता की जानकारी शरीर में होनी चाहिए। हालांकि, मैं पासवर्ड नहीं बदलूंगा, आईडी उपयोगकर्ता को एक ईमेल भेजता है जिसमें एक पृष्ठ का लिंक होता है जिसमें एक request_guid होता है, जिसे POST / उपयोगकर्ता / {id} / पासवर्ड / request_guid = के अनुरोध के साथ पारित किया जा सकता है? xxxxx

यह पासवर्ड बदल देगा, और यह किसी को पासवर्ड बदलने का अनुरोध करके किसी उपयोगकर्ता को नली करने की अनुमति नहीं देता है।

यदि कोई उत्कृष्ट अनुरोध है, तो प्रारंभिक PUT विफल हो सकता है।

— bpeikes
स्रोत

0

हम अपडेट किए गए उपयोगकर्ता पासवर्ड PUT / v1 / उपयोगकर्ताओं / पासवर्ड - AccessToken का उपयोग करके उपयोगकर्ता आईडी की पहचान करते हैं।

यूजर आईडी एक्सचेंज करना सुरक्षित नहीं है। रेस्टफुल एपीआई को HTTP हेडर में प्राप्त AccessToken का उपयोग करके उपयोगकर्ता की पहचान करनी चाहिए।

वसंत-बूट में उदाहरण

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

— डैपर डैन
स्रोत