ওপেনআইডি কানেক্টে আইডি টোকেনের মেয়াদ শেষ হওয়ার উদ্দেশ্য কী?

Question 1

ওপেনআইডি কানেক্টে একটি অ্যাক্সেস টোকেনের একটি মেয়াদ শেষ হওয়ার সময় থাকে। অনুমোদনের কোড প্রবাহের জন্য, এটি সাধারণত সংক্ষিপ্ত (উদাহরণস্বরূপ 20 মিনিট) যার পরে আপনি নতুন অ্যাক্সেস টোকেনটির জন্য অনুরোধ করতে রিফ্রেশ টোকেন ব্যবহার করেন।

আইডি টোকেনটি এছাড়াও একটি মেয়াদ শেষ হওয়ার সময় হয়েছে। আমার প্রশ্ন হ'ল এর উদ্দেশ্য কী?

রিফ্রেশ টোকেনের মেয়াদ শেষ হওয়ার চেয়ে কম আইডি টোকেনের মেয়াদ শেষ হওয়ার অর্থ আপনার অবশেষে মেয়াদ শেষ হয়ে গেছে আইডি টোকেন, তবে একটি বৈধ অ্যাক্সেস টোকেন।

সুতরাং আপনি কি বোঝাতে চাইছেন:

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

থেকে OpenID স্পেসিফিকেশন শুধু বলছেন যে যখন যাচাই একটি আইডি টোকেন

"The current time MUST be before the time represented by the exp Claim."

যা (সম্ভবত) উপরের তৃতীয় বিকল্পটি সমর্থন করে।

সম্পাদনা

ওপেনআইডি সংযোগ যেমন OAuth2 তে তৈরি করে নীচের পরিপূরক প্রশ্নের উত্তর OAuth2 নির্দিষ্টকরণে পাওয়া যাবে যা বলছে,

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

একটি সম্পর্কিত প্রশ্ন হ'ল আপনি যখন টোকেনগুলির জন্য কোনও অনুমোদনের কোডটি বিনিময় করেন, একই স্পেসিফিকেশনটি বলে যে আপনি একটি প্রতিক্রিয়া পেতে পারেন যেমন:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

তবে এই ক্ষেত্রে "মেয়াদোত্তীর্ণ" কী সম্পর্কিত? অ্যাক্সেস টোকেন, রিফ্রেশ টোকেন বা আইডি টোকেন?

(তথ্যের জন্য, আইডেন্টিটি সার্ভার 3 এটিকে অ্যাক্সেস টোকেনের সমাপ্তির সময় সেট করে)।

Question 2

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

একটি আইডি টোকেন এমন কোনও ক্লায়েন্টকে প্রমাণ করার জন্য যা ব্যবহারকারী প্রমাণীকরণ করেছে এবং ফলস্বরূপ তারা কারা।

যখন কোনও ক্লায়েন্ট একটি আইডি টোকেন পান, তখন এটি সাধারণত এটি একটি দাবি দাবিতে রূপান্তর করার মতো কিছু করবে এবং এটি চালিয়ে যাবে, যেমন একটি কুকি ব্যবহার করে।

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

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

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

Question 3

আমার নিজের কারণে এটি খনন করতে হয়েছিল এবং এটি লিখে রেখেছিলাম, তাই আমি যা শিখেছি তা এখানে পোস্ট করব ...

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

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

সুতরাং, অ্যাক্সেস টোকেনের মতো (অনুমোদনের জন্য ব্যবহৃত - ব্যবহারকারী কী অনুমতি নিয়েছে তা নির্দিষ্ট করে ) রিফ্রেশ করা যেতে পারে, আপনি কি আইডি টোকেনকে পুনরায় সতেজ করতে পারেন (প্রমাণীকরণের জন্য ব্যবহৃত - ব্যবহারকারী কে তা নির্দিষ্ট করে )? ওআইডিসির স্পেসিফিকেশন অনুসারে উত্তরটি সুস্পষ্ট নয়। ওআইডিসি / ওআউথে টোকেন পাওয়ার জন্য তিনটি "প্রবাহ" রয়েছে, অথরাইজেশন কোড প্রবাহ, ইম্পিপ্লেস ফ্লো এবং হাইব্রিড ফ্লো (যা আমি নীচে এড়িয়ে যাব কারণ এটি অন্য দুটিটির একটি বৈকল্পিক)।

জন্য OIDC / OAuth এর মধ্যে অন্তর্নিহিত প্রবাহ আপনাকে অনুমোদন শেষবিন্দু ব্রাউজারে ব্যবহারকারী পুনঃনির্দেশিত এবং অন্তর্ভুক্ত করে অনুমোদন শেষবিন্দু এ আইডি টোকেন অনুরোধ id_tokenএর মান হিসাবে response_typeঅনুরোধ প্যারামিটার। একটি অন্তর্নিহিত প্রবাহ সফল প্রমাণীকরণের প্রতিক্রিয়াটি অন্তর্ভুক্ত করার জন্য প্রয়োজনীয় id_token।

জন্য প্রমাণীকরণ কোড প্রবাহ , ক্লায়েন্ট নির্দিষ্ট করে codeএর মান হিসাবে response_typeঅনুরোধ পরামিতি যখন অনুমোদন শেষবিন্দু ব্যবহারকারী পুনঃনির্দেশিত। একটি সফল প্রতিক্রিয়া একটি অনুমোদন কোড অন্তর্ভুক্ত। ক্লায়েন্ট ক্লায়েন্ট অনুমোদনের কোডটি দিয়ে টোকেন এন্ডপয়েন্টে একটি অনুরোধ জানায় এবং ওআইডিসি কোর বিভাগ ৩.১.৩.৩ অনুসারে সফল টোকেন প্রতিক্রিয়া অবশ্যই একটি আইডি টোকেন অন্তর্ভুক্ত করে ।

উভয় প্রবাহের জন্য, আপনি প্রাথমিকভাবে আইডি টোকেন পাবেন, তবে আপনি কীভাবে তা রিফ্রেশ করবেন? ওআইডিসি বিভাগ 12: রিফ্রেশ টোকন ব্যবহার করে রিফ্রেশ টোকেন প্রতিক্রিয়া সম্পর্কে নিম্নলিখিত বিবৃতি রয়েছে:

রিফ্রেশ টোকেনের সফল বৈধতা পাওয়ার পরে, প্রতিক্রিয়াটির অংশটি 3.1.3.3 এর টোকন প্রতিক্রিয়া যা এতে আইডি_ টোকেন নাও থাকতে পারে ।

এটা তোলে নাও হতে পারে একটি আইডি টোকেন থাকে এবং যেহেতু কোন উপায় আইডি টোকেন অন্তর্ভুক্ত করা বলপূর্বক নিদিষ্ট হয়, তাহলে আপনি অনুমান করতে হবে যে প্রতিক্রিয়া আইডি টোকেন থাকবে না। সুতরাং প্রযুক্তিগতভাবে একটি রিফ্রেশ টোকেন ব্যবহার করে একটি আইডি টোকেন "রিফ্রেশ" করার কোনও নির্দিষ্ট উপায় নেই। অতএব, নতুন আইডি টোকন পাওয়ার একমাত্র উপায় হ'ল ব্যবহারকারীকে অনুমোদনের শেষ পয়েন্টে পুনর্নির্মাণ করে এবং উপরে বর্ণিত হিসাবে অন্তর্নিহিত প্রবাহ বা প্রমাণীকরণ কোড প্রবাহ শুরু করে পুনরায় অনুমোদন / প্রমাণীকরণ করুন । ওআইডিসি স্পেসিফিকেশন অনুমোদনের অনুরোধে একটি promptঅনুরোধের প্যারামিটার যুক্ত করে যাতে ক্লায়েন্ট অনুরোধ করতে পারে যে অনুমোদন সার্ভারটি কোনও ইউআই দিয়ে ব্যবহারকারীকে প্রম্পট না করে, তবে পুনর্নির্দেশটি এখনও ঘটতে হবে।

Question 4

যদি আমি সঠিকভাবে বুঝতে অনুযায়ী এই এবং থেকে OpenID কোর 1.0 বৈশিষ্ট , নিজেই টোকেন আইডি একটি প্রক্রিয়া সেশন জিদ হিসেবে কুকিজে সংরক্ষণ করা যাবে না, এবং ক্লায়েন্ট প্রতি প্রমাণীকরণ-প্রয়োজন অনুরোধের সাথে পাঠিয়ে দিলেন। ক্লায়েন্ট তারপরে আইডি টোকেনটি স্থানীয়ভাবে বা সরবরাহকারীর ভেরিফায়ার এন্ডপয়েন্টের মাধ্যমে (যদি সরবরাহ করা হয়, গুগলের মতো করে ) যাচাই করতে পারে । যদি টোকেনটির মেয়াদ শেষ হয়ে যায়, prompt=noneতবে ইউআরএল প্যারামিটারটি ছাড়া এটি অন্য লেখকের অনুরোধ করা উচিত । এছাড়াও id_token_hintপ্যারামিটারে মেয়াদোত্তীর্ণ আইডি টোকেন প্রেরণ নিশ্চিত করুন , অন্যথায় সরবরাহকারী কোনও ত্রুটি ফিরে আসতে পারে।

সুতরাং, আইডি টোকনের মেয়াদ শেষ হয়ে যাওয়া স্বাভাবিক বলে মনে হয় না, তবে prompt=noneনিশ্চিত করে যে কোনও আইডি টোকেন কোনও ব্যবহারকারীর হস্তক্ষেপের সাথে সহজেই পাওয়া যাবে (অবশ্যই যদি ব্যবহারকারী সেই ওপেনআইডি থেকে লগ আউট না করে)।

Question 5

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

প্রয়োজনীয় গ্রাহককে id_tokenঅবশ্যই সর্বদা এর (সময়) মেয়াদ যাচাই করতে হবে।

আমি আইএস এর সাথে 100% পরিচিত নই, তবে আমি অনুমান করব এটি একটি সুবিধার ক্ষেত্র। আপনার সবসময় expদাবিটি পরীক্ষা করা উচিত ।

মেয়াদোত্তীকরণ বৈধতার মধ্যে একটি মাত্র। id_tokenগুলি এছাড়াও ডিজিটালি স্বাক্ষরিত এবং এটি একটি বৈধতা যা আপনাকে অবশ্যই সম্পাদন করতে হবে।

Question 6

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

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

ইন কোড প্রবাহিত আপনি ওপি এর অনুমোদন শেষবিন্দু কল, এবং একটি গ্রহণ অনুমোদন কোড (এছাড়াও একটি অনুমোদন টোকেন, বা সংক্ষেপে authcode বলা হয়)। এটি একই কারণের জন্য আপনি ইমপ্লিট প্রবাহে প্রাপ্ত আইডি_ টোকেনের অনুরূপ সমাপ্ত হতে হবে এবং এটি পুনর্নবীকরণযোগ্য হবে না এবং হওয়া উচিত নয়।

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

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

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

Question 7

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

আপনি যখন কোনও সেশন http://openid.net/specs/openid-connect-session-1_0.html থেকে ব্যবহারকারীকে লগ আউট করার চেষ্টা id_tokenকরছেন id_token_hintতখন আপনিও এটি ব্যবহার করুন । আমি দৃ honest়তার সাথে মনে করি না যে এই মুহুর্তে মেয়াদ উত্তীর্ণ হয়ে গেলে যেহেতু আপনি কেবলমাত্র কোনও নির্দিষ্ট ব্যবহারকারীকে লগ আউট করার বিষয়ে উদ্বিগ্ন হন তা সত্যিই গুরুত্বপূর্ণ ।id_token

Question 8

টিএলডিআর;

আইডি টোকেন যা বলে তা বিশ্বাস করার আগে যাচাই করুন।

আরো বিস্তারিত

ওপেনআইডি কানেক্টে আইডি টোকেনের মেয়াদোত্তীকরণের উদ্দেশ্য কী?

উদ্দেশ্যটি হ'ল ক্লায়েন্টটি আইডি টোকেনটি বৈধ করার অনুমতি দেয় এবং আইডি টোকেনের তথ্য ব্যবহার করে এমন ক্রিয়াকলাপের আগে ক্লায়েন্টকে অবশ্যই আইডি টোকেনকে বৈধতা দিতে হবে ।

থেকে ঝাঁপ দাও অন্তর্নিহিত ফ্লো বৈশিষ্ট :

যদি এই দস্তাবেজে সংজ্ঞায়িত বৈধকরণের কোনও প্রক্রিয়া ব্যর্থ হয় তবে অবশ্যই সঠিকভাবে যাচাই করতে ব্যর্থ হওয়া তথ্যের প্রয়োজন হয় এমন কোনও অপারেশন বাতিল করা উচিত এবং যা যা বৈধ করতে ব্যর্থ হয়েছিল সেগুলি ব্যবহার করা উচিত নয়।

এটি সংশোধন করতে, গুগলের ওপেনআইডি কানেক্ট ডকুমেন্টেশন আইডি টোকেন বৈধতা সম্পর্কে এটি বলে:

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

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