RESTful পাসওয়ার্ড পুনরায় সেট করুন

Question

পাসওয়ার্ড পুনরায় সেট করার জন্য একটি RESTful উত্স গঠনের উপযুক্ত উপায় কী?

এই সংস্থানটি এমন কারও পাসওয়ার্ড রিসেটর হিসাবে বোঝানো হয়েছে যাঁর পাসওয়ার্ড হারিয়ে গেছে বা ভুলে গেছে। এটি তাদের পুরানো পাসওয়ার্ডকে অবৈধ করে এবং তাদের একটি পাসওয়ার্ড ইমেল করে।

আমার কাছে দুটি বিকল্প রয়েছে:

POST /reset_password/{user_name}

বা ...

POST /reset_password
   -Username passed through request body

আমি নিশ্চিত যে অনুরোধটি একটি পোস্ট হওয়া উচিত। আমি কোনও উপযুক্ত নাম নির্বাচন করেছি বলে আমি কম আত্মবিশ্বাসী। এবং আমি নিশ্চিত নই যে ব্যবহারকারীর নামটি ইউআরএল বা অনুরোধ সংস্থার মধ্য দিয়ে যেতে হবে কিনা।

Answer 1

আপডেট: (আরও নীচে মন্তব্য করতে)

আমি এই জাতীয় কিছু জন্য যেতে হবে:

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

আপনার কাছে দুটি ব্যবহারকারীর সংগ্রহ, একটি ব্যবহারকারী সংগ্রহ এবং প্রতিটি ব্যবহারকারীর জন্য একটি বৈশিষ্ট্য সংগ্রহ রয়েছে collection ব্যবহারকারীর দ্বারা নির্দিষ্ট করা হয় :user_idএবং বৈশিষ্ট্যটি দ্বারা নির্দিষ্ট করা হয় password। PUTঅপারেশন সংগ্রহ সুরাহা সদস্য আপডেট।

Comments

আমি আপনার আপডেট হওয়া (পোষ্ট) সমাধানের সাথে একমত। পুট অনুরোধগুলি আদর্শবান হওয়া উচিত (অর্থাত্ বারবার অনুরোধগুলি ফলাফলকে প্রভাবিত করবে না)। এটি পোস্টের অনুরোধগুলির ক্ষেত্রে নয়।

— রস ম্যাকফার্লেন

আমি রিসেট পাসওয়ার্ডটি পাসওয়ার্ড_সেটে পরিবর্তন করব

— রিচার্ড নপ

ছেলেরা হ্যাং ... এটি কি কারওর পাসওয়ার্ড পুনরায় সেট করার জন্য প্রয়োজনীয়ভাবে অনুমতি দেবে না? যেমন এটি যদি বর্তমানের পাসওয়ার্ড ভুলে যায় এমন কারও পক্ষে হয় তবে আক্রান্ত ব্যবহারকারীকে বর্তমান পাসওয়ার্ড দিয়ে প্রমাণীকরণ করা যাবে না। সুতরাং মূলত এর অর্থ এই এপিআই কোনও পাসওয়ার্ড মোটেও গ্রহণ করতে পারেনি - এইভাবে যে কারওর পাসওয়ার্ডটি পুনরায় সেট করতে সক্ষম করে, এবং যদি এপিআই এটি ফেরত দেয়, এমনকি কোনও পরিচিত ব্যবহারকারীর পাসওয়ার্ড ধরে ফেলতে পারে ??? বা আমি কি কিছু মিস করছি

— ট্রান্সিয়েন্ট_লুপ

/ ব্যবহারকারী / {আইডি} / পাসওয়ার্ড এবং এর মতো সমস্যা হ'ল আপনি ব্যবহারকারীর "আইডি" জানেন না। আপনি তাদের "ব্যবহারকারী নাম" বা "ইমেল" বা "ফোন" জানতেন, তবে "আইডি" নয়।

— coolaj86

এই পদ্ধতির সাথে মৌলিক ত্রুটিটি এটি ধরে নেয় যে আপনি ইতিমধ্যে ব্যবহারকারীর আইডি জানেন। এটি কিছু পরিস্থিতিতে সত্য হবে তবে আপনি কীভাবে তা করতে পারেন তবে যখন ব্যবহারকারীর নাম বা ব্যবহারকারী আইডিটি পুনরায় সেট করার জন্য কেবল কোনও ইমেল নির্দিষ্ট করা প্রয়োজন known

— আলাপিন

Answer 2

অরক্ষিত ব্যবহারকারীগণ

আমরা PUTএকটি api/v1/account/passwordশেষ পয়েন্টে একটি অনুরোধ করব এবং ব্যবহারকারী যে অ্যাকাউন্টের জন্য পাসওয়ার্ডটি পুনরায় সেট করতে (আপডেট করতে) চায় সেটি শনাক্ত করতে সংশ্লিষ্ট অ্যাকাউন্ট ইমেলের সাথে একটি পরামিতি প্রয়োজন:

PUT : /api/v1/account/password?email={[e-mail]}

দ্রষ্টব্য: যেমন @ ডগডোমেনি তার মন্তব্যে উল্লেখ করেছেন যে ইউআরএলটিতে কোয়েরি স্ট্রিং হিসাবে ইমেলটি পাস করা একটি সুরক্ষা ঝুঁকি। GET প্যারামিটারগুলি ব্যবহার করার সময় উন্মুক্ত করা হয় না https(এবং আপনার httpsঅনুরোধগুলির জন্য সর্বদা একটি সঠিক সংযোগ ব্যবহার করা উচিত ) তবে এতে জড়িত অন্যান্য সুরক্ষা ঝুঁকি রয়েছে are আপনি এই ব্লগ পোস্টে এই বিষয়ে আরও পড়তে পারেন এখানে ।

অনুরোধ সংস্থায় ইমেলটি প্রবেশ করা এটি জিইটি পরম হিসাবে পাস করার জন্য আরও সুরক্ষিত বিকল্প হবে:

PUT : /api/v1/account/password

অনুরোধ বডি:

{
    "email": "[e-mail]"
}

প্রতিক্রিয়াটির একটি 202স্বীকৃত প্রতিক্রিয়া অর্থ রয়েছে:

প্রক্রিয়াজাতকরণের জন্য অনুরোধটি গ্রহণ করা হয়েছে, তবে প্রক্রিয়াজাতকরণ শেষ হয়নি। অনুরোধটি শেষ পর্যন্ত কার্যকর করা হতে পারে বা নাও হতে পারে, কারণ বাস্তবে প্রক্রিয়াজাতকরণের সময় এটি অনুমোদিত নয়। এর মতো একটি অ্যাসিনক্রোনাস অপারেশন থেকে একটি স্ট্যাটাস কোড পুনরায় পাঠানোর কোনও সুবিধা নেই।

ব্যবহারকারীর একটি ইমেল পাবেন [e-mail]এবং আপডেটের অনুরোধটি প্রক্রিয়াটি ইমেল থেকে লিঙ্কটি নিয়ে নেওয়া পদক্ষেপের উপর নির্ভর করে।

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

এই ইমেলটি থেকে লিঙ্কটি খোলার সাথে সামনের শেষ অ্যাপ্লিকেশনটিতে রিসেট পাসওয়ার্ড ফর্মের দিকে পরিচালিত হবে যা কোনও লুকানো ইনপুট ক্ষেত্রের ইনপুট হিসাবে লিঙ্ক থেকে রিসেট পাসওয়ার্ড টোকেন ব্যবহার করে (টোকেনটি ক্যোয়ারী স্ট্রিং হিসাবে লিঙ্কটির অংশ) is অন্য একটি ইনপুট ক্ষেত্র ব্যবহারকারীকে একটি নতুন পাসওয়ার্ড সেট করতে দেয়। নতুন পাসওয়ার্ডটি নিশ্চিত করতে দ্বিতীয় ইনপুটটি ফ্রন্ট-এন্ডে বৈধতার জন্য ব্যবহৃত হবে (টাইপস প্রতিরোধে)।

বিঃদ্রঃ: ইমেলটিতে আমরা উল্লেখ করতে পারি যে ব্যবহারকারীর কোনও পাসওয়ার্ড পুনরায় সেট করার সূচনা না করায় সে ইমেলটিকে উপেক্ষা করতে পারে এবং তার বর্তমান পাসওয়ার্ডের সাথে অ্যাপ্লিকেশনটি স্বাভাবিকভাবে ব্যবহার করতে পারে

ফর্মটি যখন নতুন পাসওয়ার্ড এবং টোকেনটি ইনপুট হিসাবে জমা দেওয়া হবে তখন পুনরায় সেট করুন পাসওয়ার্ড প্রক্রিয়াটি ঘটবে। ফর্ম ডেটা PUTআবার একটি অনুরোধের সাথে পাঠানো হবে তবে এবার টোকেন সহ এবং আমরা রিসোর্স পাসওয়ার্ডকে একটি নতুন মান দিয়ে প্রতিস্থাপন করব:

PUT : /api/v1/account/password

অনুরোধ বডি:

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

প্রতিক্রিয়াটি 204কোনও সামগ্রীর প্রতিক্রিয়া হবে

সার্ভারটি অনুরোধটি পূরণ করেছে তবে কোনও সত্তা-দেহ ফেরত দেওয়ার দরকার নেই এবং সম্ভবত আপডেট মেন্টেরফর্মেশনটি ফিরে আসতে চাইবে। প্রতিক্রিয়া হতে পারে সত্তা-শিরোনাম আকারে নতুন বা আপডেট মেন্টেরফর্মেশন অন্তর্ভুক্ত, যা উপস্থিত থাকলে অনুরোধ বৈকল্পিকের সাথে যুক্ত হতে হবে।

প্রমাণীকৃত ব্যবহারকারীরা

অনুমোদনপ্রাপ্ত ব্যবহারকারীরা যাঁর পাসওয়ার্ড পরিবর্তন করতে চান তাদের জন্য PUTঅনুরোধটি ইমেল ছাড়াই তাত্ক্ষণিকভাবে সম্পাদন করা যেতে পারে (আমরা যে অ্যাকাউন্টের জন্য পাসওয়ার্ডটি আপডেট করছি সেটি সার্ভারের সাথে পরিচিত)। এই ক্ষেত্রে ফর্মটি দুটি ক্ষেত্র জমা দেবে:

PUT : /api/v1/account/password

অনুরোধ বডি:

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

Comments

আপনার প্রথম অনুচ্ছেদে আপনি PUT বলছেন তবে নীচের উদাহরণটি মুছে ফেলবে। কোনটি সঠিক?

— jpierson

এটি ইউআরএলটিতে ইমেল ঠিকানাটি প্রকাশ করে যা কোনও জেএসএন ডেটা আরও সুরক্ষিত রাখবে।

— ডগ ডোমেনি

@ ডগডমিনি হ্যাঁ, জেসন ডেটা হিসাবে ইমেল প্রেরণ করা আরও ভাল would আমি বিকল্পটিতে আরও সুরক্ষিত বিকল্প হিসাবে উত্তরে এটি যুক্ত করেছি, অন্যথায় সমাধানটি একই হতে পারে।

— উইল্ট করুন

@ উইল্ট: এটি কোন প্যাচ অপারেশন হবে না?

— পুটকে

@ অজিতেনশাহ এটি লেখার সময় আমি ভেবেছিলাম পিট আরও ভাল হবে তবে কেন তা ঠিক মনে নেই। আমি আপনার যুক্তিতে একমত যে প্যাচ এই মামলার পক্ষে আরও উপযুক্ত হতে পারে।

— উইল্ট

Answer 3

আসুন এক সেকেন্ডের জন্য উবার-রিস্টফুল হয়ে যাই। রিসেট ট্রিগার করতে পাসওয়ার্ডের জন্য মোছা পদক্ষেপটি কেন ব্যবহার করবেন না? বোধ হয়, তাই না? সর্বোপরি, আপনি বিদ্যমান পাসওয়ার্ডটিকে কার্যকরভাবে অন্যটির পক্ষে বাতিল করছেন।

তার মানে আপনি কি করবেন:

DELETE /users/{user_name}/password

এখন, দুটি বড় সতর্কতা:

1. এইচটিটিপি মুছে ফেলার কথা আদর্শবান্ধব বলে মনে করা হয় ("যদি আপনি এটি একাধিকবার করেন তবে কোনও বড় বিষয় নয়" বলার অভিনব শব্দ)) যদি আপনি "পাসওয়ার্ড রিসেট" ইমেল প্রেরণের মতো স্ট্যান্ডার্ড জিনিসগুলি করেন তবে আপনি সমস্যার মধ্যে চলে যাবেন। আপনি এই বুলিয়ান "ইস রিসেট" পতাকাটি দিয়ে ব্যবহারকারীর / পাসওয়ার্ডটিকে ঘিরে কাজ করতে পারেন। প্রতি মুছতে, আপনি এই পতাকাটি পরীক্ষা করে দেখুন; যদি এটি সেট না করা থাকে তবে আপনি পাসওয়ার্ডটি পুনরায় সেট করতে এবং আপনার ইমেলটি প্রেরণ করতে পারেন। (দ্রষ্টব্য যে এই পতাকাটি থাকার অন্যান্য ব্যবহারগুলিও থাকতে পারে))

2. আপনি কোনও ফর্মের মাধ্যমে এইচটিটিপি ডিলেট ব্যবহার করতে পারবেন না , সুতরাং আপনাকে একটি এজেএক্স কল করতে হবে এবং / অথবা পোষ্টের মাধ্যমে মুছে ফেলতে হবে টানেল।

Comments

আকর্ষণীয় ধারণা। তবে আমি DELETEএখানে ভাল মানায় না । আপনি এলোমেলোভাবে উত্পন্ন উত্পন্ন পাসওয়ার্ডটির পরিবর্তে পাসওয়ার্ডটি স্থাপন করবেন, আমার ধারণা, DELETEএটি বিভ্রান্তিকর হতে পারে। আমি পছন্দ করি Create (POST) new reset_password action, যেখানে আপনি যে বিশেষ্যটি (রিসোর্স) নিয়ে অভিনয় করবেন সেটি হ'ল "রিসেট_প্যাসওয়ার্ড ক্রিয়া"। এটি ইমেল প্রেরণের জন্যও ভাল ফিট করে, যেহেতু ক্রিয়াটি এই সমস্ত নিম্ন-স্তরের বিবরণকে আবদ্ধ করে। POSTআদর্শবান নয়।

— ড্যানিয়েল ভ্যাসালো

আমি প্রস্তাবটি পছন্দ করি শর্তসাপেক্ষ অনুরোধগুলি, অর্থাৎ হেড যা ETag + DELETE এবং যদি ম্যাচ শিরোনাম প্রেরণ করে 1 ইস্যুটি মোকাবেলা করা যেতে পারে। কেউ যদি এমন কোনও পাসওয়ার্ড মুছে ফেলার চেষ্টা করে যা আর সক্রিয় নেই, তবে সে একটি 412 পেয়ে যাবে

— হুইস্কিসিয়ার

আমি মুছে ফেলতে হবে। আপনি আপডেট করছেন, যেহেতু একই সত্তা / ধারণাটি একটি নতুন মান পাবে। তবে প্রকৃতপক্ষে, সাধারণত এটি এখনই ঘটছে না তবে কেবলমাত্র পরে অন্য একটি অনুরোধে নতুন পাসওয়ার্ড প্রেরণের পরে (রিসেটের পাসওয়ার্ড মেইলের পরে) - আজকাল কেউই মেইলে কোনও নতুন পাসওয়ার্ড পাঠায় না, তবে একটি নতুন অনুরোধে এটি পুনরায় সেট করার জন্য একটি টোকেন রয়েছে একটি প্রদত্ত টোকেন, তাই না?

— antonio.fornie

পুনরায় সেট করার অনুরোধ করার পরে যদি ব্যবহারকারী তার পাসওয়ার্ড মনে রাখে? কিছু বট এলোমেলো অ্যাকাউন্ট পুনরায় সেট করার চেষ্টা করছে সে সম্পর্কে কী? ব্যবহারকারীর এ ক্ষেত্রে রিসেট ইমেলটিকে অগ্রাহ্য করার অনুমতি দেওয়া উচিত (ইমেলটি তাই বলা উচিত) যার অর্থ আপনার সিস্টেমে নিজেরাই পাসওয়ার্ড মুছতে বা আপডেট করা উচিত নয়।

— ম্যাক্সিম লাভাল

@ ম্যাক্সিমাল্যাভাল এটি একটি খুব ভাল বিষয়। সত্যিই, আপনি "রিসেট অনুরোধ তৈরি করছেন", যা একটি পোষ্ট হবে।

— ক্রেগ ওয়াকার

Answer 4

প্রায়শই আপনি প্রাথমিক অনুরোধে ব্যবহারকারীর বিদ্যমান পাসওয়ার্ড মুছতে বা নষ্ট করতে চান না, কারণ এটি ইমেলটির অ্যাক্সেস না থাকা কোনও ব্যবহারকারী দ্বারা (অনিচ্ছাকৃতভাবে বা ইচ্ছাকৃতভাবে) ট্রিগার করা হতে পারে। পরিবর্তে, ব্যবহারকারী রেকর্ডে একটি পুনরায় সেট পাসওয়ার্ড টোকেন আপডেট করুন এবং এটি একটি ইমেলের অন্তর্ভুক্ত একটি লিঙ্কে প্রেরণ করুন। লিঙ্কটিতে ক্লিক করা ব্যবহারকারীর টোকেনটি নিশ্চিত করেছে এবং তাদের পাসওয়ার্ড আপডেট করার ইচ্ছা করেছে। আদর্শভাবে, সময়টি সংবেদনশীলও হতে পারে।

এই ক্ষেত্রে বিশিষ্ট পদক্ষেপটি একটি পোস্ট হবে: পাসওয়ার্ডরিসেটস নিয়ন্ত্রকের উপর ক্রিয়াকলাপটি তৈরি করে। ক্রিয়াটি নিজেই টোকেন আপডেট করে ইমেল প্রেরণ করবে।

Answer 5

আমি আসলে একটি উত্তর খুঁজছি, কোনও জবাব দেওয়ার অর্থ নয় - তবে "রিসেট_প্যাসওয়ার্ড" একটি REST প্রসঙ্গে আমার কাছে ভুল বলে মনে হচ্ছে কারণ এটি একটি ক্রিয়াপদ, বিশেষ্য নয়। এমনকি আপনি যদি বলেন যে আপনি "রিসেট অ্যাকশন" বিশেষ্য করছেন - এই ন্যায্যতাটি ব্যবহার করে, সমস্ত ক্রিয়া বিশেষ্য হয়।

এছাড়াও, একই উত্তরটির সন্ধানকারী কারও ক্ষেত্রে এটি না ঘটতে পারে যে আপনি সুরক্ষা প্রসঙ্গে আপনাকে ব্যবহারকারীর নামটি পেতে সক্ষম হতে পারেন, এবং ইউআরএল বা শরীরের মাধ্যমে একেবারেই প্রেরণ করতে হবে না, যা আমাকে বিব্রত করে তোলে।

Comments

সম্ভবত reset-passwordএকটি ক্রিয়াপদ মত শোনাচ্ছে তবে password-resetএটি একটি বিশেষ্য হিসাবে তৈরি করতে আপনি সহজেই এটি ( ) বিপরীত করতে পারেন । এবং যদি আপনি ইভেন্ট সোর্সিং ব্যবহার করে বা আপনার কাছে কেবল কোনও ধরণের নিরীক্ষণ করে থাকেন তবে তা আপনার বোধগম্য হয় যে এই নামটি সহ আপনার প্রকৃত সত্তা রয়েছে এবং এটি ব্যবহারকারী বা প্রশাসকগণের জন্য জিইটিগুলি দেখতে পাবে ইতিহাস (স্পষ্টত পাসওয়ার্ডের পাঠ্য ম্যাস্কিং)। আমাকে মোটেও নার্ভাস করে না। এবং সার্ভারে স্বয়ংক্রিয়ভাবে ব্যবহারকারীর নামটি বাছাই করার জন্য - আপনি পারেন, তবে তবে আপনি প্রশাসন / ছদ্মবেশকরণের মতো জিনিসগুলি কীভাবে পরিচালনা করবেন?

— অ্যারোনআউট

REST- এ ক্রিয়াপদ ব্যবহারে কোনও ভুল নেই। যতক্ষণ না এটি যথাযথ জায়গায় ব্যবহৃত হয়। আমি মনে করি এটি একটি রিসোর্সের চেয়ে বেশি নিয়ামক এবং reset-passwordএর প্রভাবগুলি ভালভাবে বর্ণনা করার জন্য পরিচালনা করে।

— অ্যান্ডার্সস্টমান

Answer 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)

তথ্য সরবরাহ সম্পর্কিত:

• বর্তমান পাসওয়ার্ড পুনরায় সেট করতে

  • ইমেল শরীরের দেওয়া উচিত।

• নতুন পাসওয়ার্ড তৈরি করতে (পুনরায় সেট করার পরে)

  • নতুন পাসওয়ার্ড, অ্যাক্টিভেশন কোড এবং ইমেলআইডি দেবে।

• পাসওয়ার্ড আপডেট করার জন্য (লগইন-ব্যবহারকারীর জন্য)

  • পুরানো পাসওয়ার্ড, নতুন পাসওয়ার্ড শরীরে উল্লেখ করা উচিত।
  • প্যারামে ইউজারআইডি।
  • শিরোনামে আথ টোকেন।

Comments

অন্যান্য উত্তরে যেমন মন্তব্য করা হয়েছে, "ডিলিট / এপিআই / ভি 1 / অ্যাকাউন্ট / পাসওয়ার্ড" একটি খারাপ ধারণা, কারণ যে কেউ যে কারও পাসওয়ার্ড পুনরায় সেট করতে পারে।

— ম্যাক্সিমিডেপ্রে

পাসওয়ার্ডটি পুনরায় সেট করতে আমাদের একটি নিবন্ধিত ইমেল আইডি দরকার। অজানা ব্যবহারকারীর ইমেল আইডি জানার সম্ভাবনা খুব মারাত্মক, যদি না আমরা ফেসবুকের মতো সাইট চালাচ্ছি এবং যে কোনও উপায়ে প্রচুর পরিমাণে ইমেল আইডি সংগ্রহ করা হয় না। তারপরে সুরক্ষা নীতিগুলি সেই অনুযায়ী সংজ্ঞায়িত করা হবে। কারও পাসওয়ার্ড পুনরায় সেট করতে আপনার পরামর্শ কি?

— কোডসনোকার 6

Answer 7

গ্রহণ করার জন্য কয়েকটি বিবেচনা রয়েছে:

পাসওয়ার্ড পুনরায় সেটগুলি আদর্শবান নয়

পাসওয়ার্ড পরিবর্তনগুলি এটি সম্পাদন করার জন্য শংসাপত্র হিসাবে ব্যবহৃত ডেটাগুলিকে প্রভাবিত করে, ফলস্বরূপ অনুরোধটি কেবল ভারব্যাটিয়াম পুনরায় করা হয় এবং সঞ্চিত শংসাপত্রগুলি পরিবর্তিত হলে ফলস্বরূপ ভবিষ্যতের প্রচেষ্টাকে অকার্যকর করতে পারে। উদাহরণস্বরূপ, যদি কোনও অস্থায়ী রিসেট টোকেনটি পরিবর্তনের অনুমতি দেওয়ার জন্য ব্যবহার করা হয়, যেমন এটি ভুলে যাওয়া পাসওয়ার্ডের পরিস্থিতিতে প্রথাগত হয়, সফল পাসওয়ার্ড পরিবর্তনের পরে টোকেনটির মেয়াদ শেষ হয়ে যায়, যা অনুরোধটির অনুলিপি করার ক্ষেত্রে আরও প্রচেষ্টা বাতিল করে দেয়। সুতরাং একটি পাসওয়ার্ড পরিবর্তনের জন্য একটি বিশুদ্ধ পদ্ধতির POSTচেয়ে মনে হয় একটি কাজের চেয়ে উপযুক্ত উপযুক্ত PUT।

ডেটা লোডে আইডি বা ই-মেইল সম্ভবত অনর্থক

যদিও এটি রেস্টের বিরুদ্ধে নয় এবং এর কিছু বিশেষ উদ্দেশ্য থাকতে পারে, তবে পাসওয়ার্ড পুনরায় সেট করার জন্য একটি আইডি বা ইমেল ঠিকানা নির্দিষ্ট করা প্রায়শই প্রয়োজন unnecessary এটি ভেবে দেখুন, কেন আপনি অনুরোধটির কোনও অংশ বা অন্য কোনওভাবে প্রমাণীকরণের মধ্য দিয়ে যাওয়ার অনুরোধের ডেটার অংশ হিসাবে ইমেল ঠিকানাটি সরবরাহ করবেন? যদি ব্যবহারকারী কেবল তাদের পাসওয়ার্ড পরিবর্তন করে থাকে তবে তাদের এগুলি করার জন্য তাদের অনুমোদন করতে হবে (ব্যবহারকারীর নাম: পাসওয়ার্ড, ইমেল: পাসওয়ার্ড, অথবা শিরোনামের মাধ্যমে অ্যাক্সেস টোকেন সরবরাহ করা)। সুতরাং, আমরা এই পদক্ষেপ থেকে তাদের অ্যাকাউন্টে অ্যাক্সেস আছে। যদি তারা তাদের পাসওয়ার্ড ভুলে গিয়ে থাকে তবে তাদের একটি অস্থায়ী রিসেট টোকেন সরবরাহ করা হত (ইমেলের মাধ্যমে) যা তারা পরিবর্তনটি সম্পাদন করার জন্য শংসাপত্র হিসাবে বিশেষত ব্যবহার করতে পারে। এবং এই ক্ষেত্রে তাদের অ্যাকাউন্ট সনাক্ত করার জন্য টোকেনের মাধ্যমে প্রমাণীকরণ যথেষ্ট হওয়া উচিত।

উপরোক্ত সমস্ত কিছু বিবেচনায় রেখে এখানে আমি একটি পাসওয়ার্ড পরিবর্তনের জন্য যথাযথ পরিকল্পনা বলে বিশ্বাস করি:

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

Comments

একটি বিবৃতি যা কোনও স্থানধারককে ব্যান্ড-অফ-ব্যান্ডের তথ্যের প্রয়োজন তা সম্পূর্ণ সত্য নয়। একটি বিশেষ মিডিয়া টাইপ একটি অনুরোধ বা প্রতিক্রিয়ার নির্দিষ্ট উপাদানগুলির সিনট্যাক্স এবং শব্দার্থবিজ্ঞানের বর্ণনা দিতে পারে। মিডিয়া টাইপের পক্ষে এটি নির্ধারণ করা সম্ভব যে নির্দিষ্ট ক্ষেত্রের মধ্যে থাকা ইউআরআই নির্দিষ্ট ডেটার জন্য স্থানধারককে সংজ্ঞায়িত করতে পারে এবং শব্দার্থীরা আরও সংজ্ঞায়িত করে যে কোনও এনকোডযুক্ত ব্যবহারকারী-ইমেল বা স্থানধারকের পরিবর্তে কী অন্তর্ভুক্ত করা উচিত নয়। মিডিয়া প্রকারের প্রতি শ্রদ্ধাশীল ক্লায়েন্ট এবং সার্ভারগুলি এখনও বিশিষ্ট আর্কিটেকচার নীতিমালা মেনে চলবে।

— রোমান ভটনার

সংক্রান্ত POSTবনাম PUT বোঝায় যা RFC 7231 নির্দিষ্ট করে একটি আংশিক আপডেট দুই সম্পদের ওভারল্যাপিং তথ্য মাধ্যমে অর্জন করা হতে পারে কিন্তু এটি সন্দেহজনক যদি ভালো কিছু হয় /v1/account/passwordসত্যিই একটি ভাল রিসোর্স আসলে জন্য আপ করা নেই। হিসাবে POSTওয়েব যে যদি অন্যান্য পদ্ধতি কেউই সম্ভবপর হয় ব্যবহার করা যেতে পারে বিবেচনা সুইস সেনা-kniff হয় PATCHযথাসাধ্য নতুন পাসওয়ার্ড সেট করার জন্য একটি পছন্দ হবে।

— রোমান ভটনার

পাসওয়ার্ড পুনরায় সেট করার জন্য যখন তারা তাদের পাসওয়ার্ড না জানার অনুরোধ করবে তখন কী করবে?

— ড্যান কার্টার

Answer 8

আমার কাছে এমন কিছু নেই যা পাসওয়ার্ড পরিবর্তন করে এবং তাদের একটি নতুন প্রেরণ করে যদি আপনি / ব্যবহারকারী / {আইডি} / পাসওয়ার্ড পদ্ধতি ব্যবহার করার সিদ্ধান্ত নেন এবং অনুরোধটি তার নিজস্ব একটি উত্স বলে আপনার ধারণায় লেগে থাকুন। অর্থাত্ / ব্যবহারকারীর পাসওয়ার্ড-অনুরোধ / হ'ল সংস্থান, এবং PUT ব্যবহার করা হয়, ব্যবহারকারীর তথ্য শরীরে থাকা উচিত। যদিও আমি পাসওয়ার্ডটি পরিবর্তন করব না, আইডি একটি ইমেল প্রেরণ করে যাতে একটি পৃষ্ঠার লিঙ্ক রয়েছে যা একটি অনুরোধ_গাইড রয়েছে, যা পোষ্ট / ব্যবহারকারী / {আইডি} / পাসওয়ার্ড /? অনুরোধ_গুইড = এর অনুরোধের সাথে পাশ করা যেতে পারে? XXXXX

এটি পাসওয়ার্ড পরিবর্তন করবে এবং এটি কোনও ব্যক্তিকে পাসওয়ার্ড পরিবর্তনের অনুরোধ করে হোসে করার অনুমতি দেয় না।

প্লাস যদি প্রাথমিক অসামান্য অনুরোধ থাকে তবে ব্যর্থ হতে পারে।

Answer 9

আমরা লগড ব্যবহারকারীর পাসওয়ার্ড PUT / v1 / ব্যবহারকারী / পাসওয়ার্ড আপডেট করি - এক্সেসটোকেন ব্যবহার করে ব্যবহারকারীর আইডি সনাক্ত করি।

এটি ব্যবহারকারীর আইডি বিনিময় করা নিরাপদ নয়। রেস্টফুল এপিআই-তে অবশ্যই HTTP শিরোনামে প্রাপ্ত অ্যাক্সেস টোকেন ব্যবহার করে ব্যবহারকারীকে সনাক্ত করতে হবে।

বসন্ত বুট উদাহরণ

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