বিশুদ্ধ প্রমাণীকরণ

Question

RESTful প্রমাণীকরণ বলতে কী বোঝায় এবং এটি কীভাবে কাজ করে? আমি গুগলে একটি ভাল ওভারভিউ খুঁজে পাচ্ছি না। আমার একমাত্র উপলব্ধি হ'ল আপনি ইউআরএলে সেশন কী (রিকর্ডারাল) পাস করেছেন তবে এটি মারাত্মক ভুল হতে পারে।

Comments

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

— এস .লট

আপনি এইচটিটিপিএস ব্যবহার করলে এটি মারাত্মকভাবে ভুল হবে না। URL সহ সম্পূর্ণ HTTP অনুরোধটি এনক্রিপ্ট করা হবে।

— ভারত খত্রি

@ ভরতখত্রি: হ্যাঁ তা হবে। আমি কখনই ব্যবহারকারীর কাছে দৃশ্যমান URL- এ সংবেদনশীল তথ্য প্রেরণ করব না। ব্যবহারিক উদ্দেশ্যে এই তথ্য ফাঁস হওয়ার সম্ভাবনা অনেক বেশি। এইচটিটিপিএস দুর্ঘটনাজনিত ফাঁস জন্য সহায়তা করতে পারে না।

— জো তাই

@ জ্যাকফল্যান্ড: সত্যিকারের রেস্টস্টুল প্রমাণীকরণ বলতে কী বোঝ? আমি আগ্রহী বেকাউস আমি গ্রহণযোগ্য উত্তর থেকে সবেমাত্র তৃতীয় উপায়টি প্রয়োগ করেছি, তবে আমি এতে সন্তুষ্ট নই (ইউআরএলটিতে অতিরিক্ত পরম পছন্দ করি না)।

— ব্লুলেটচ্যুস 16

কিছু কিছু মানুষের ব্যবহার jwt.io/introduction এই সমস্যা সমাধানের .. আমি এই মুহূর্তে আমার ক্ষেত্রে সমাধান সম্পর্কে গবেষণা করতে: stackoverflow.com/questions/36974163/... >> আশা করছি এই ইচ্ছার কাজ জরিমানা।

— তোহা

Answer 1

একটি RESTful ক্লায়েন্ট-সার্ভার আর্কিটেকচারে প্রমাণীকরণ কীভাবে পরিচালনা করবেন তা বিতর্কের বিষয়।

সাধারণত, এটি HTTP বিশ্বে SOA- এর মাধ্যমে অর্জন করা যায়:

• এইচটিটিপিএসের উপরে এইচটিটিপি বুনিয়াদি লেখক;
• কুকিজ এবং সেশন পরিচালনা;
• HTTP শিরোনামে টোকন (যেমন OAuth 2.0 + JWT);
• অতিরিক্ত স্বাক্ষর পরামিতিগুলির সাথে প্রমাণীকরণের অনুসন্ধান করুন।

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

আপনার সুরক্ষা নীতি এবং সফ্টওয়্যার আর্কিটেকচারের উদ্দেশ্য অনুসারে প্রতিটি প্রমাণীকরণ স্কিমের নিজস্ব প্রো এবং সিওএন থাকে।

এইচটিটিপিএসের উপরে এইচটিটিপি বেসিক লেখক

স্ট্যান্ডার্ড এইচটিটিপিএস প্রোটোকলের উপর ভিত্তি করে এই প্রথম সমাধানটি বেশিরভাগ ওয়েব পরিষেবা ব্যবহার করে।

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

আমরা ডাইজেস্ট প্রমাণীকরণ ব্যবহার করতে পারি তবে এটির জন্য এইচটিটিপিএসও প্রয়োজন কারণ এটি এমআইএম বা রিপ্লে আক্রমণগুলির ঝুঁকিপূর্ণ এবং এইচটিটিপি-র সাথে সুনির্দিষ্ট।

কুকিজের মাধ্যমে সেশন

সত্যি কথা বলতে, সার্ভারে পরিচালিত একটি সেশনটি সত্যই স্টেটলেস নয়।

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

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

কুকি কৌশলটি নিজেই এইচটিটিপি-লিঙ্কযুক্ত, সুতরাং এটি সত্যই আরামদায়ক নয়, যা প্রোটোকল-স্বতন্ত্র, আইএমএইচও হওয়া উচিত। এটি এমআইএম বা রিপ্লে আক্রমণে ঝুঁকিপূর্ণ ।

টোকেনের মাধ্যমে মঞ্জুরিপ্রাপ্ত (OAuth2)

বিকল্পটি হ'ল এইচটিটিপি শিরোনামের মধ্যে একটি টোকেন স্থাপন করা যাতে অনুরোধটি প্রমাণীকৃত হয়। উদাহরণস্বরূপ এটি OAuth 2.0 করে। দেখুন বোঝায় যা RFC 6749 :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

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

প্রমাণীকরণের অনুসন্ধান করুন

ক্যারি প্রমাণীকরণ ইউআরআই-তে কিছু অতিরিক্ত পরামিতিগুলির মাধ্যমে প্রতিটি RESTful অনুরোধে স্বাক্ষর করে। দেখুন এই রেফারেন্স নিবন্ধ ।

এটি এই নিবন্ধে যেমন সংজ্ঞায়িত করা হয়েছিল:

সমস্ত আরআরইএসটি ক্যোয়ারীগুলিকে স্বাক্ষরকারী টোকেন হিসাবে ব্যক্তিগত শংসাপত্র ব্যবহার করে বর্ণনামূলক ক্রমে লোয়ার-কেস অনুসারে বাছাইকৃত ক্যোয়ারী প্যারামিটারগুলিতে স্বাক্ষর করে প্রমাণীকরণ করতে হবে। URL টি ক্যোয়ারী স্ট্রিং এনকোড করার আগে সাইন ইন হওয়া উচিত।

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

উদাহরণস্বরূপ, উপরের লিঙ্কটি থেকে এখানে একটি জেনেরিক ইউআরআই নমুনা রয়েছে:

GET /object?apiKey=Qwerty2010

যেমন প্রেরণ করা উচিত:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

স্বাক্ষরিত স্ট্রিংটি হ'ল /object?apikey=Qwerty2010&timestamp=1261496500এবং স্বাক্ষরটি API কীটির ব্যক্তিগত উপাদান ব্যবহার করে সেই স্ট্রিংয়ের SHA256 হ্যাশ।

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

JSON এবং REST এর উপর ভিত্তি করে আমাদের ক্লায়েন্ট-সার্ভার ORM / SOA / MVC কাঠামোর মধ্যে RESTful প্রমাণীকরণ সম্পর্কে কিছু বিশদ জানতে এই নিবন্ধটি দেখুন । যেহেতু আমরা কেবল HTTP / 1.1 এর মাধ্যমে যোগাযোগের অনুমতি দিই না, তবে পাইপ বা জিডিআই বার্তাগুলির নামকরণও করেছি (স্থানীয়ভাবে), আমরা সত্যই RESTful প্রমাণীকরণের ধরণটি প্রয়োগ করার চেষ্টা করেছি এবং HTTP নির্দিষ্টকরণের উপর নির্ভর করতে পারি না (যেমন শিরোনাম বা কুকিজ)।

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

অনুশীলনে, আসন্ন ম্যাক টোকেন প্রমাণীকরণ OAuth 2.0 এর জন্য "টোকেন দ্বারা অনুমোদিত" বর্তমান স্কিমের ক্ষেত্রে একটি বিশাল উন্নতি হতে পারে। তবে এটি এখনও কাজ চলছে এবং এইচটিটিপি সংক্রমণে আবদ্ধ।

উপসংহার

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

Comments

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

— মিক্কো রেন্টালাইনেন

@ মিকো রেন্টালাইনেন তবে এই কুকিটি এখনও সার্ভার দ্বারা পরিচালিত হবে, যেমনটি আমি লিখেছি। এটি একধরনের রাষ্ট্রহীন, তবে "খাঁটি" রাষ্ট্রহীন নয়। সমস্ত ক্ষেত্রে, আপনার ক্লায়েন্ট লগইন / লগআউটকে উত্সর্গীকৃত জাভাস্ক্রিপ্ট কোডের প্রয়োজন, যা পুরোপুরি সম্ভব যেমন উদাহরণস্বরূপ HTTP ডাইজেস্ট এথ - ভাল ধারণা, তবে এখানে চাকাটি পুনরায় উদ্ভাবন করতে কোনও বড় সুবিধা নেই।

— অর্ণাড বোচেজ 3'13

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

— মিক্কো রেন্টালাইনেন

আমি সঠিক উত্তর হল stackoverflow.com/questions/6068113/...

— graffic

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

— ডাবিস ভান্ডারমির

Answer 2

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

ব্রাউজারে দেখার জন্য এইচটিএমএল পৃষ্ঠাগুলি উত্পাদন করে এমন RESTful পরিষেবাদিতে HTTP প্রমাণীকরণ ব্যবহার করে আমি যে সমস্যাগুলি পেয়েছি সেগুলি হ'ল:

• ব্যবহারকারী সাধারণত একটি কুরুচিপূর্ণ ব্রাউজার দ্বারা তৈরি লগইন বাক্স পায় যা খুব ব্যবহারকারী-বন্ধুত্বপূর্ণ। আপনি পাসওয়ার্ড পুনরুদ্ধার, সহায়তা বাক্স, ইত্যাদি যোগ করতে পারবেন না।
• অন্য কোনও নামে লগ আউট করা বা লগ ইন করা একটি সমস্যা - ব্রাউজারগুলি আপনার উইন্ডোটি বন্ধ না করা পর্যন্ত সাইটে প্রমাণীকরণের তথ্য প্রেরণ করতে থাকবে
• সময়সীমা কঠিন

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

আমি বিশ্বাস করি কুকিজই এর সমাধান। তবে অপেক্ষা করুন, কুকিজগুলি খারাপ, তাই না? না, তারা নয়, প্রায়শই কুকিগুলি ব্যবহার করা খারাপ। একটি কুকি নিজেই কেবল ক্লায়েন্ট-সাইড তথ্যের এক টুকরো, ঠিক যেমন HTTP প্রমাণীকরণ তথ্যের যেমন আপনি ব্রাউজ করার সময় ব্রাউজারটি ট্র্যাক করে রাখে। এবং এই ক্লায়েন্ট-সাইডের তথ্যটি প্রতিটি অনুরোধে সার্ভারে প্রেরণ করা হয়, ঠিক আবার HTTP প্রমাণীকরণ তথ্য যেমন হবে info ধারণাগতভাবে, কেবলমাত্র পার্থক্যটি হ'ল ক্লায়েন্ট-সাইডের এই অংশের সামগ্রীটি তার প্রতিক্রিয়ার অংশ হিসাবে সার্ভার দ্বারা নির্ধারণ করা যেতে পারে ।

সেশনগুলি কেবলমাত্র নীচের নিয়মগুলি সহ একটি বিশ্রামের সংস্থান তৈরি করে:

• একটি অধিবেশন একটি ব্যবহারকারী আইডির একটি কী মানচিত্র করে (এবং সম্ভবত টাইমআউটগুলির জন্য শেষ-অ্যাকশন-টাইমস্ট্যাম্প)
• যদি কোনও সেশন বিদ্যমান থাকে, তার মানে কীটি বৈধ।
• লগইন মানে / সেশনে পোষ্ট করা, একটি নতুন কী একটি কুকি হিসাবে সেট করা হয়
• লগআউটটির অর্থ হ'ল ডিফল্টিং / সেশন / {কী load (ওভারলোডড পোস্টের সাথে মনে রাখবেন, আমরা একটি ব্রাউজার, এবং এইচটিএমএল 5 এখনও যেতে অনেক দীর্ঘ পথ)
• প্রতিটি অনুরোধে কুকি হিসাবে কীটি প্রেরণ করে এবং সেশনটি বিদ্যমান এবং বৈধ কিনা তা পরীক্ষা করে প্রমাণীকরণ করা হয়

এইচটিটিপি প্রমাণীকরণের মধ্যে এখন একমাত্র পার্থক্য হ'ল প্রমাণীকরণ কীটি সার্ভারের দ্বারা উত্পন্ন এবং ক্লায়েন্টকে প্রেরণ করা হয় যে এটি ক্লায়েন্টকে প্রবেশের শংসাপত্রগুলি থেকে এটি কম্পিউটিংয়ের পরিবর্তে প্রেরণ করে keeps

রূপান্তরকারী 42 যোগ করেছেন যে https ব্যবহার করার সময় (যা আমাদের হওয়া উচিত), কুকির কাছে এটির সুরক্ষিত পতাকা সেট থাকা জরুরি যাতে প্রমাণীকরণের তথ্য কোনও নিরাপদ সংযোগের মাধ্যমে কখনও প্রেরণ করা যায় না। দারুণ বিষয়, আমি নিজে দেখিনি।

আমি অনুভব করি যে এটি একটি কার্যকর সমাধান যা কার্যকর কাজ করে, তবে আমি অবশ্যই স্বীকার করব যে এই স্কিমের সম্ভাব্য গর্তগুলি সনাক্ত করতে আমি কোনও সুরক্ষা বিশেষজ্ঞের পক্ষে যথেষ্ট নই - আমি কেবল জানি যে শত শত অ-বিশ্রামযোগ্য ওয়েব অ্যাপ্লিকেশনগুলি মূলত একই ব্যবহার করে লগইন প্রোটোকল (পিএইচপি-তে $ _SESSION, জাভা EE তে এইচটিটিপিএসশন ইত্যাদি) কুকির শিরোনামের বিষয়বস্তুগুলি কেবল একটি সার্ভার-সাইড রিসোর্সকে সম্বোধন করতে ব্যবহৃত হয়, যেমন কোনও অনুবাদ গ্রন্থটি অনুবাদ সংস্থানগুলিতে অ্যাক্সেস করতে ব্যবহৃত হতে পারে, ইত্যাদি। আমি অনুভব করি যে এটি একই, তবে অন্যেরাও তা করেন না? তোমরা কি মনে কর?

Comments

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

— jhndodo

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

— jhndodo

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

— skrebbel

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

— মিক্কো রেন্টালাইনেন

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

— জো ফিলিপস

Answer 3

এখানে ইতিমধ্যে ভাল লোকেরা ইতিমধ্যে এই বিষয়টিতে বলেছে। তবে এখানে আমার 2 সেন্ট।

ইন্টারঅ্যাকশন 2 টি মোড আছে:

1. মানব-থেকে-মেশিন (এইচটিএম)
2. মেশিন থেকে মেশিন (এমটিএম)

যন্ত্রটি হ'ল সাধারণ ডিনোমিনেটর, আরইএসটি এপিআই হিসাবে প্রকাশ করা হয়, এবং অভিনেতা / ক্লায়েন্টরা হয় মানুষ বা মেশিন হয়।

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

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

এটি বিবেচনা করুন: আপনার কাছে একটি ডেটা / তথ্য প্ল্যাটফর্ম রয়েছে REST API গুলিগুলির সম্পদ উন্মুক্ত। সম্ভবত আপনার কাছে একটি স্ব-পরিষেবা বিআই প্ল্যাটফর্ম রয়েছে যা সমস্ত ডেটা কিউবকে পরিচালনা করে। তবে আপনি চান আপনার (মানব) গ্রাহকরা (1) ওয়েব অ্যাপ্লিকেশন, (2) মোবাইল অ্যাপ্লিকেশন এবং (3) কিছু তৃতীয় পক্ষের অ্যাপ্লিকেশন এর মাধ্যমে এটি অ্যাক্সেস করুন। শেষ পর্যন্ত, এমনকি এমটিএমগুলির চেইনটি এইচটিএম-ডানদিকে নিয়ে যায়। সুতরাং মানব ব্যবহারকারী তথ্য চেইনের শীর্ষে রয়েছেন।

প্রথম 2 টি ক্ষেত্রে, আপনার কাছে হিউম্যান-টু-মেশিন ইন্টারঅ্যাকশন সম্পর্কিত একটি মামলা রয়েছে, তথ্যটি আসলে একজন মানব ব্যবহারকারী ব্যবহার করছেন। শেষ ক্ষেত্রে, আপনার কাছে একটি মেশিন প্রোগ্রাম রয়েছে যা REST এপিআইগুলি গ্রাস করে।

প্রমাণীকরণের ধারণাটি বোর্ড জুড়ে প্রযোজ্য। আপনি কীভাবে এটি ডিজাইন করবেন যাতে আপনার REST এপিআইগুলি অভিন্ন, সুরক্ষিত পদ্ধতিতে অ্যাক্সেস পায়? আমি এটি যেভাবে দেখছি, সেখানে 2 টি উপায় রয়েছে:

ওয়ে-1:

1. শুরু করার জন্য কোনও লগইন নেই। প্রতিটি অনুরোধ লগইন সম্পাদন করে
2. ক্লায়েন্ট প্রতিটি অনুরোধের সাথে তার সনাক্তকরণের পরামিতিগুলি + অনুরোধের জন্য নির্দিষ্ট পরামিতি প্রেরণ করে
3. আরআরএসআইপি এগুলি তাদের নিয়ে যায়, ঘুরে দাঁড়ায়, ব্যবহারকারীর স্টোরকে (যা যা হয়) পিং করে এবং লেখককে নিশ্চিত করে
4. যদি লেখকটি প্রতিষ্ঠিত হয়, তবে অনুরোধটি সরবরাহ করে; অন্যথায়, উপযুক্ত HTTP স্থিতি কোডটি অস্বীকার করে
5. আপনার ক্যাটালগের সমস্ত REST এপিআই জুড়ে প্রতিটি অনুরোধের জন্য উপরেরটি পুনরাবৃত্তি করুন

ওয়ে-2:

1. ক্লায়েন্ট একটি লেখার অনুরোধ দিয়ে শুরু হয়
2. একটি লগইন REST এপিআই সমস্ত অনুরোধগুলি পরিচালনা করবে
3. এটি প্রমাণীকরণের প্যারামিটারগুলি (এপিআই কী, ইউআইডি / পিডাব্লুডি বা আপনি যা কিছু বেছে নিন) গ্রহণ করে এবং ব্যবহারকারীর স্টোরের (লিডিএপি, এডি, বা মাইএসকিউএল ডিবি ইত্যাদি) প্রমাণীকরণ করে)
4. যদি যাচাই করা হয় তবে একটি লেখক টোকেন তৈরি করে তা ক্লায়েন্ট / কলারের কাছে ফেরত দেয়
5. কলার তারপরে লগ আউট না হওয়া বা লিজের মেয়াদ শেষ না হওয়া অবধি এই ব্যবসায়ের টোকেন + পরবর্তী ব্যবসায়িক REST এপিআইগুলিতে প্রতিটি পরবর্তী অনুরোধের সাথে নির্দিষ্ট প্যারামগুলি অনুরোধ করে

স্পষ্টতই, ওয়ে -২ এ, আরএসটি এপিআইগুলিকে টোকেনকে বৈধ হিসাবে স্বীকৃতি ও বিশ্বাস করার একটি উপায় প্রয়োজন। লগইন এপিআই প্রমাণীকরণ যাচাই করল, এবং সেইজন্য আপনার ক্যাটালগের অন্যান্য "রিয়েল এপিআই" দ্বারা "ভালেট কী" বিশ্বাস করা দরকার।

অবশ্যই এটির অর্থ হ'ল রাইট কী / টোকেনটিকে REST এপিআই-এর মধ্যে সঞ্চয় এবং ভাগ করা দরকার। এই ভাগ করা, বিশ্বস্ত টোকেন সংগ্রহস্থল স্থানীয় / সংঘবদ্ধ যেকোনও হতে পারে, অন্য সংস্থাগুলির REST এপিআইগুলিকে একে অপরের প্রতি বিশ্বাস স্থাপনের অনুমতি দেয়।

কিন্তু আমার দ্বিমত আছে.

মুল বক্তব্যটি হ'ল একটি "রাষ্ট্র" (ক্লায়েন্টের সত্যায়িত অবস্থান সম্পর্কে) বজায় রাখা এবং ভাগ করে নেওয়া দরকার যাতে সমস্ত REST এপিআই বিশ্বাসের একটি বৃত্ত তৈরি করতে পারে। যদি আমরা এটি না করি, যা ওয়ে -1, তবে আমাদের অবশ্যই মেনে নিতে হবে যে কোনও / সমস্ত অনুরোধগুলি আসার জন্য প্রমাণীকরণের একটি আইন অবশ্যই সম্পাদন করা উচিত।

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

সুতরাং আরও স্তর, আরও বিলম্ব।

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

একইভাবে ওয়ে -২। আপনার (মানব) ব্যবহারকারী কখনই লক্ষ্য করবেন না। সুতরাং কোনও ক্ষতি করা হয়নি।

আমরা যদি এমটিএম-তে ওয়ে -1 প্রয়োগ করি? এক্ষেত্রে এটির মেশিন হওয়ায় আমরা প্রতিটি অনুরোধের সাথে প্রমাণীকরণের তথ্য জমা দেওয়ার অনুরোধ করে আমরা এই লোকটির কাছ থেকে নরকটি পেতে পারি। কেউ গ্রাহ্য করে না! এমটিএম-এ ওয়ে -২ সম্পাদন করা কোনও বিশেষ প্রতিক্রিয়া সৃষ্টি করবে না; এটি একটি জঘন্য মেশিন। এটা কম যত্ন করতে পারে!

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

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

Comments

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

— বিষ্ণু রাথ

এটি কি সর্বদা কোনও মেশিন প্রমাণীকরণ করে না? মানুষ পাসওয়ার্ড সম্পর্কে বাজে কথা দেয় না, এটি ব্যবহারকারীদের জন্য দুর্ভাগ্যজনক বিরক্তি যা সঠিকভাবে সুরক্ষাকে যৌক্তিক করে তোলে। আমার কাছে এটি বিকাশকারীর সমস্যা যে তারা কীভাবে মেশিনটির কাজটি করতে চায় তা চাই।

— টড বাউর

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

— কিংজ 19

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

— কিংজ

আপনি অনুপস্থিত Way-3, সংকর পদ্ধতির। ক্লায়েন্টটি যেমন হিসাবে লগ ইন করে Way-2তবে হিসাবে Way-1, শংসাপত্রগুলি কোনও সার্ভারের পাশের রাজ্যের বিরুদ্ধে পরীক্ষা করা হয় না। নির্বিশেষে, একটি প্রমাণীকরণ টোকেন তৈরি করা হয়েছে এবং ক্লায়েন্টকে আবার হিসাবে পাঠানো হয়েছে Way-2। এই টোকেনটি পরে কোনও ক্লায়েন্টের সুনির্দিষ্ট রাজ্যের সন্ধান করে অসামান্য ক্রিপ্টো ব্যবহার করে সত্যতার জন্য পরীক্ষা করা হয়।

— jcoffland

Answer 4

এখানে একটি সত্যই এবং সম্পূর্ণরূপে RESTful প্রমাণীকরণ সমাধান:

1. প্রমাণীকরণের সার্ভারে একটি সর্বজনীন / ব্যক্তিগত কী জুড়ি তৈরি করুন।
2. সমস্ত সার্ভারে সর্বজনীন কী বিতরণ করুন।

3. যখন কোনও ক্লায়েন্ট প্রমাণীকরণ করে:

   3.1। একটি টোকেন ইস্যু করুন যাতে নিম্নলিখিতটি রয়েছে:

   • মেয়াদ অতিক্রান্ত হওয়ার সময়
   • ব্যবহারকারীর নাম (alচ্ছিক)
   • ব্যবহারকারী আইপি (alচ্ছিক)
   • একটি পাসওয়ার্ডের হ্যাশ (alচ্ছিক)

   3.2। ব্যক্তিগত কী দিয়ে টোকনটি এনক্রিপ্ট করুন।

   3.3। এনক্রিপ্ট করা টোকেনটি ব্যবহারকারীকে ফেরত পাঠান।

4. যখন ব্যবহারকারী কোনও এপিআই অ্যাক্সেস করেন তাদের অবশ্যই তাদের লেখক টোকনে পাস করতে হবে।

5. সার্ভারগুলি প্রমাণীকরণ করতে পারে যে টুথটি অনুমোদনের সার্ভারের সর্বজনীন কী ব্যবহার করে ডিক্রিপ্ট করে বৈধ।

এটি রাষ্ট্রবিহীন / RESTful প্রমাণীকরণ।

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

Comments

কেউ যদি সেই লেখককে টোকেন ধরে রাখে এবং ক্লায়েন্ট হওয়ার ভান করে এপিআইগুলিতে আবেদন করে তবে কী হবে?

— আবিদি

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

— jcoffland

কারণ কেবলমাত্র প্রমাণীকরণের সার্ভারটিই ব্যক্তিগত কীটি জানে। অন্যান্য সার্ভারগুলি কেবল সর্বজনীন কী এবং ব্যবহারকারীর টোকেন জেনে ব্যবহারকারীকে প্রমাণীকরণ করতে পারে।

— jcoffland

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

— ক্রেগ

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

— ক্রেগ

Answer 5

আপনার সাথে সত্য কথা বলতে আমি এখানে দুর্দান্ত উত্তরগুলি দেখেছি তবে এমন কিছু যা আমাকে কিছুটা বিরক্ত করে তা যখন কেউ পুরো স্টেটলেস ধারণাটি এমন এক চূড়ান্ত দিকে নিয়ে যায় যেখানে এটি কৌতূহলযুক্ত হয়ে ওঠে। এটি আমাকে সেই পুরানো স্মার্টটাক ভক্তদের মনে করিয়ে দেয় যা কেবল খাঁটি ওওকে আলিঙ্গন করতে চেয়েছিল এবং যদি কোনও জিনিস না হয় তবে আপনি এটি ভুল করছেন। আমাকে একটু বিরতি দাও.

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

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

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

Comments

লোকেরা আপনাকে সেশন ব্যবহার করতে নিষেধ করার চেষ্টা করছে না। আপনি এটি করতে নির্দ্বিধায় তবে আপনি যদি করেন তবে এটি বিশ্রাম নয়।

— আন্দ্রে Caldas

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

— arg20

সুতরাং এটি যদি বিশ্রাম না দেয় তবে আমরা এটিকে কী বলব? এবং অবশ্যই যদি কোনও অনুরোধে সেশন আইডি অন্তর্ভুক্ত থাকে, তবে এটি কোনও ব্যবহারকারীর আইডিসহ অনুরোধের মতো রাষ্ট্রহীন? ব্যবহারকারীর আইডির স্টেটলেস এবং সেশন আইডির স্থিতি কেন?

— এমফহোল্মস

কুকিগুলি ক্রস-সাইট অনুরোধ জালিয়াতির পক্ষে ঝুঁকির থাকে, তাই তাদের সুরক্ষা লঙ্ঘন করা সহজ করে তোলে। কাস্টম শিরোনাম বা কাস্টম অনুমোদনের স্কিমের মতো ব্রাউজার দ্বারা স্বয়ংক্রিয়ভাবে প্রেরণ করা হয়নি এমন কিছু ব্যবহার করা ভাল।

— ডাবিস ভান্ডারমির

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

— অর্ণাড বোচেজ 12'15

Answer 6

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

Comments

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

— jcoffland

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

— এরিক মার্টিনো

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

— jcoffland

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

— মাইকেল একোকা

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

— ক্রেগ

Answer 7

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

এর কাছে যাওয়ার সহজতম উপায় হ'ল আরএফসি 2617 এ এইচটিটিপি-র অন্তর্নির্মিত প্রমাণীকরণ প্রক্রিয়া দিয়ে শুরু করা ।

Comments

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

— jcoffland

@ জ্যাকফল্যান্ড: এটি উভয় অ্যাকাউন্টেই সহজ নয়। প্রথম HTTP অথথের পাসওয়ার্ড সংরক্ষণ করার জন্য সার্ভারের প্রয়োজন হয় না। হ্যাশ পাসওয়ার্ডের পরিবর্তে সংরক্ষিত হয় (8+ চক্রের সঙ্গে প্রস্তাবিত bcrypt)। দ্বিতীয়ত, অনুমোদনের শিরোনাম প্রতিটি অনুরোধের সাথে প্রেরণ করার কারণে সার্ভারের কোনও রাজ্য নেই। এবং যদি আপনি সঞ্চিত পাসওয়ার্ড হ্যাশগুলিকে রাষ্ট্র হিসাবে বিবেচনা করেন তবে সেগুলি সঞ্চিত পাবলিক কীগুলির চেয়ে বেশি আর কোনও রাজ্য নয়।

— বরিস বি।

@ বরিস বি। হ্যাঁ আমি বুঝতে পারি যে পাসওয়ার্ডটি হ্যাশ হিসাবে সংরক্ষিত। হ্যাশ পাসওয়ার্ড এখনও ক্লায়েন্ট নির্দিষ্ট রাষ্ট্র। আমার সমাধানে বর্ণিত হিসাবে পাবলিক-কী সংরক্ষণ করার পার্থক্যটি হ'ল এখানে কেবলমাত্র একটি পাবলিক-কী রয়েছে, প্রমাণীকরণের সার্ভারের পাবলিক-কী key এটি ব্যবহারকারী হিসাবে একটি পাসওয়ার্ড হ্যাশ সংরক্ষণ করার চেয়ে খুব আলাদা। সার্ভার প্রতিটি ব্যবহারকারীর জন্য একটি পাসওয়ার্ড সঞ্চয় করে তবে আপনি এটি কীভাবে সাজবেন তা বিবেচনাধীন নয় তবে এটি ব্যবহারকারী হিসাবে প্রতি স্টোরেজ করে রাখা হয় এবং এটি 100% আরএসইটি নয়।

— jcoffland

আমি মনে করি না যে কোনও ব্যবহারকারী হ্যাশ পাসওয়ার্ড সার্ভারে সংরক্ষণ করে সার্ভার-সাইডের অবস্থা হিসাবে বিবেচনা করা উচিত। ব্যবহারকারীরা হ'ল সংস্থান, নাম, ঠিকানা বা হ্যাশ পাসওয়ার্ডের মতো তথ্য ধারণ করে।

— কোডেপঙ্ক্ট

Answer 8

@স্ক্রেবেল দ্বারা উল্লিখিত 'অত্যন্ত অন্তর্দৃষ্টিপূর্ণ' নিবন্ধে ( http://www.berenddeboer.net/rest/authentication.html ) প্রমাণীকরণের একটি বিভক্ত কিন্তু সত্যই ভাঙা পদ্ধতি নিয়ে আলোচনা করেছে।

আপনি পৃষ্ঠাটি দেখার চেষ্টা করতে পারেন (যা কেবল প্রমাণীকৃত ব্যবহারকারীর কাছে দেখার যোগ্য বলে মনে করা হয়) http://www.berenddeboer.net/rest/site/authenticated.html কোনও লগইন শংসাপত্র ছাড়াই।

(দুঃখিত আমি উত্তর সম্পর্কে মন্তব্য করতে পারবেন না।)

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

Comments

স্ট্রাইপ ডটকম আরএসটি এবং প্রমাণীকরণের মিশ্রণ না করার বিষয়ে আপনার মন্তব্যকে অন্যথায় বলবে ..

— এরিক

স্টেটলেস কেবল সার্ভারকে বোঝায়, ক্লায়েন্টকে নয়। ক্লায়েন্টটি অধিবেশনটির সমস্ত স্থিতি মনে করতে পারে এবং প্রতিটি অনুরোধের সাথে প্রাসঙ্গিক যা প্রেরণ করতে পারে।

— ডাবিস ভান্ডারমির

অবশেষে কেউ কিছু বুদ্ধিমান কথা বলছেন, তবে রাষ্ট্রবিহীন প্রমাণীকরণ পাবলিক-কী ক্রিপ্টো ব্যবহার করে সম্ভব। আমার উত্তর দেখুন।

— jcoffland

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

— মাইকেল একোকা

"আমি বলব REST এবং প্রমাণীকরণ কেবল মিশ্রিত হয় না" " কিছু সাধারণ জ্ঞানের মত শোনাচ্ছে। প্রমাণীকরণের সাথে অসম্পূর্ণ একটি সিস্টেম ("স্বীকৃত" নিজেই, অবশ্যই একটি রাষ্ট্র) ব্যতীত সীমিত উপযোগিতা Ex আমি মনে করি আমরা সকলেই ব্যবহারিকতা এবং শুদ্ধবাদী গোড়ামীবাদের চৌরাস্তাতে বিতর্ক করছি এবং খোলামেলা ব্যবহারিকতার জয়ের উচিত। REST এর প্রচুর দিক রয়েছে যা প্রমাণীকরণের ক্ষেত্রে রাষ্ট্র এড়ানোর চেষ্টা করে কনট্রিশনে না গিয়ে চূড়ান্ত উপকারী, সেখানে কি নেই?

— ক্রেগ

Answer 9

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

Comments

সিএসআরএফ দুর্বলতার কারণে কুকিজ এবং এইচটিটিপি এথ এড়ানো উচিত।

— ডাবিস ভান্ডারমির

আপনি কি সাহায্য করতে পারেন দয়া করে আমার প্রশ্নটি দেখতে পারেন? stackoverflow.com/questions/60111743/...

— হেমন্ত Metalia

Answer 10

16-ফেব্রুয়ারী -2018 এ আপডেট

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

---

আমি মনে করি নিচের পদ্ধতিটি REST পরিষেবা প্রমাণীকরণের জন্য ব্যবহার করা যেতে পারে:

1. প্রমাণীকরণের জন্য ব্যবহারকারীর নাম এবং পাসওয়ার্ড গ্রহণ করতে একটি লগইন RESTful API তৈরি করুন। ট্রানজিট চলাকালীন সুরক্ষার জন্য ক্যাচিং এবং এসএসএল প্রতিরোধ করতে এইচটিটিপি পোষ্ট পদ্ধতিটি ব্যবহার করুন সফল প্রমাণীকরণের জন্য, এপিআই দুটি JWT প্রদান করে - একটি অ্যাক্সেস টোকেন (সংক্ষিপ্ত মেয়াদ, 30 মিনিট বলে) এবং একটি রিফ্রেশ টোকন (দীর্ঘ মেয়াদী, 24 ঘন্টা বলুন)
2. ক্লায়েন্ট (একটি ওয়েব ভিত্তিক ইউআই) স্থানীয় স্টোরেজে জেডাব্লুটিটি সংরক্ষণ করে এবং পরবর্তী প্রতিটি এপিআই কল "অনুমোদন: বহনকারী # অ্যাক্সেস টোকন" শিরোনামে অ্যাক্সেস টোকনকে পাস করে
3. এপিআই স্বাক্ষর এবং মেয়াদ শেষ হওয়ার তারিখ যাচাই করে টোকেনের বৈধতা পরীক্ষা করে che যদি টোকেনটি বৈধ হয়, তাহলে ব্যবহারকারী (এটি JWT- এ "উপ" দাবিটি ব্যবহারকারীর নাম হিসাবে ব্যাখ্যা করে) ক্যাশে দেখার সাথে API এ অ্যাক্সেস পেয়েছে কিনা তা পরীক্ষা করে দেখুন। যদি ব্যবহারকারী এপিআই অ্যাক্সেসের জন্য অনুমোদিত হয় তবে ব্যবসায়ের যুক্তি সম্পাদন করুন
4. টোকেনটির মেয়াদ শেষ হয়ে গেলে, API টি এইচটিটিপি প্রতিক্রিয়া কোড 400 প্রদান করে
5. ক্লায়েন্ট, 400/401 পেয়ে, নতুন অ্যাক্সেস টোকন পেতে "অনুমোদন: বহনকারী # রিফ্রেশ টোকেন" শিরোনামে রিফ্রেশ টোকেনের সাথে আরেকটি আরআরটি এপিআই আবেদন করে।
6. রিফ্রেশ টোকেন সহ কল ​​পাওয়ার পরে, স্বাক্ষর এবং মেয়াদ শেষ হওয়ার তারিখটি পরীক্ষা করে রিফ্রেশ টোকেনটি বৈধ কিনা তা পরীক্ষা করে দেখুন। রিফ্রেশ টোকেনটি বৈধ হলে ডিবি থেকে ব্যবহারকারীর অ্যাক্সেস ডান ক্যাশে রিফ্রেশ করুন এবং নতুন অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেনটি ফিরিয়ে দিন। যদি রিফ্রেশ টোকেনটি অবৈধ হয় তবে HTTP প্রতিক্রিয়া কোড 400 ফিরিয়ে দিন
7. যদি নতুন অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেনটি ফিরে আসে তবে দ্বিতীয় ধাপে যান HTTP প্রতিক্রিয়া কোড 400 যদি ফিরে আসে তবে ক্লায়েন্ট ধরে নেয় যে রিফ্রেশ টোকেনটির মেয়াদ শেষ হয়ে গেছে এবং ব্যবহারকারীর কাছ থেকে ব্যবহারকারীর নাম এবং পাসওয়ার্ড চাইবে
8. লগআউট করার জন্য, স্থানীয় স্টোরেজ পরিষ্কার করুন

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

Comments

সুতরাং আপনি উদাহরণস্বরূপ কৌণিক দিয়ে তৈরি একটি স্ট্যাটিক ওয়েবসাইটের সাথে এটি একটি এপিআই ব্যবহার করবেন? এবং মোবাইল অ্যাপস সম্পর্কে কি?

— ইয়াজান রাওয়াসদেহ

Answer 11

এটি করার উপায় এটি: লগইনের জন্য OAuth 2.0 ব্যবহার করা ।

গুগল যতক্ষণ না এটি OAuth সমর্থন করে ততক্ষণ আপনি অন্যান্য প্রমাণীকরণের পদ্ধতিগুলি ব্যবহার করতে পারেন।

Comments

OAuth2 এইচটিটিপিএস ছাড়া নিরাপদ নয়, বা রাষ্ট্রহীন।

— অর্ণাড বোচেজ

এইচটিটিপিএস ছাড়া কিছুই সুরক্ষিত নয়।

— ক্রেগ

@ ক্রেইগ এবং এইচটিটিপিএস সুরক্ষিত নাও হতে পারে, যদি শংসাপত্র শৃঙ্খলাটি ভেঙে যায়, যা আরও ভাল ভাল হতে পারে - en.wikedia.org/wiki/Bulrun_(decryption_program) ;)

— আর্নাড বোচেজ

@ আরনাউডবাচেজ দয়া করে স্পষ্ট করে বলুন কীভাবে একটি ভাঙা শংসাপত্র শৃঙ্খলা বৃহত্তর জন্য? আমি বুঝতে পারছি না আপনি কোথায় যাচ্ছেন? ;)

— ক্রেগ

@ ক্রেইগ দয়া করে লিঙ্কটি অনুসরণ করুন, এবং উপভোগ করুন! এই "বৃহত্তর ভাল" দৃষ্টিভঙ্গি আমার মন্তব্যে স্পষ্টতই ছদ্মবেশী ছিল: বুলারুনের মতো সিস্টেমগুলি আমাদের প্রিয় এবং বিশ্বস্ত সরকার দ্বারা "আমাদের নিজের ভাল" জন্য বোঝানো হয়েছে।

— আরনৌদ বাউচেজ

Answer 12

একটি পাবলিক কী অবকাঠামো ব্যবহার করে যাতে কোনও কী নিবন্ধন করে যথাযথ বাধ্যবাধকতা জড়িত থাকে তা নিশ্চিত করে যে পাবলিক কীটি এমনভাবে নির্ধারিত হয় যার সাথে এটি অ-প্রত্যাখ্যান নিশ্চিত করে

Http://en.wikedia.org/wiki/Public_key_inf কাঠামো দেখুন । আপনি যদি যথাযথ পিকেআই মানগুলি অনুসরণ করেন তবে যে ব্যক্তি বা এজেন্টটি চুরি করা চাবিটি ভুলভাবে ব্যবহার করে সে চিহ্নিত এবং লক আউট হতে পারে। এজেন্টের যদি কোনও শংসাপত্র ব্যবহারের প্রয়োজন হয় তবে বাঁধনটি বেশ শক্ত হয়ে যায়। একটি চালাক এবং দ্রুত চলন্ত চোর পালাতে পারে, তবে তারা আরও টুকরো টুকরো করে ফেলে।

Answer 13

আমার বুঝতে থেকে এই প্রশ্নের উত্তর দিতে ...

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

উদাহরণস্বরূপ, একটি রুবি অন রেলস অ্যাপ্লিকেশনটিতে আমরা আমাদের ওয়েব অ্যাপটি তৈরি করতে পারি যেমন লগ ইন করা কোনও ব্যবহারকারী যদি http://store.com/account/logout পরিদর্শন করেন তবে সেই পৃষ্ঠার জিইটি ব্যবহারকারী লগআউট করার চেষ্টা হিসাবে দেখা যাবে । আমাদের রেল কন্ট্রোলারে আমরা এমন একটি ক্রিয়া তৈরি করব যা ব্যবহারকারীর লগ আউট করে এবং সেগুলি হোম পৃষ্ঠায় প্রেরণ করে।

লগইন পৃষ্ঠায় একটি জিইটি একটি ফর্ম দেবে। লগইন পৃষ্ঠায় একটি পোষ্ট লগইন প্রচেষ্টা হিসাবে দেখা হবে এবং পোষ্ট ডেটা গ্রহণ এবং লগইন করতে এটি ব্যবহার করা হবে।

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

আমি এখনও শিখছি - আমি যদি ভুল বলেছি বলে কিছু পাওয়া যায় তবে দয়া করে আমাকে সংশোধন করুন, এবং আপনি যদি আরও কিছু শিখেন তবে এটি এখানে আবার পোস্ট করুন। ধন্যবাদ।

Answer 14

কোনও ওয়েব অ্যাপ্লিকেশন সুরক্ষিত করার জন্য বৈধ টিপস

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

আপনি RESTful API গুলি সুরক্ষিত করতে JWTs (JSON ওয়েব টোকেন) ব্যবহার করতে পারেন , সার্ভার-সাইড সেশনের তুলনায় এর অনেক সুবিধা রয়েছে, সুবিধাগুলি মূলত:

1- আরও স্কেলযোগ্য, কারণ আপনার এপিআই সার্ভারগুলিতে প্রতিটি ব্যবহারকারীর জন্য সেশন বজায় রাখতে হবে না (যখন আপনার অনেক সেশন থাকে তখন এটি বড় বোঝা হতে পারে)

২- জেডাব্লুটিটি স্ব-অন্তর্ভুক্ত থাকে এবং দাবী রাখে যা ব্যবহারকারীর ভূমিকা উদাহরণ হিসাবে বর্ণনা করে এবং তিনি কী কী অ্যাক্সেস করতে পারেন এবং তারিখ এবং সমাপ্তির তারিখে জারি করতে পারেন (এর পরে জেডব্লিউটি বৈধ হবে না)

3- লোড-ব্যালেন্সারগুলিকে হ্যান্ডেল করা সহজ এবং যদি আপনার একাধিক এপিআই সার্ভার থাকে তবে আপনার সেশন ডেটা ভাগ করতে হবে না বা সেশনের একই সার্ভারে যাওয়ার জন্য সার্ভারটি কনফিগার করতে হবে না, যখনই কোনও জেডাব্লুটিটির সাথে কোনও অনুরোধ কোনও সার্ভারকে আঘাত করে তবে তা প্রমাণীকরণযোগ্য হতে পারে & অনুমোদিত

4- আপনার ডিবিতে কম চাপের পাশাপাশি প্রতিটি অনুরোধের জন্য আপনাকে নিয়মিত সেশন আইডি এবং ডেটা সংগ্রহ করতে হবে না

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

অনেক লাইব্রেরি বেশিরভাগ প্রোগ্রামিং ভাষায় JWTs তৈরি ও যাচাইকরণের সহজ উপায় সরবরাহ করে, উদাহরণস্বরূপ: নোড.জেএস- এ সর্বাধিক জনপ্রিয় একটি হল জসনওবটোকেন

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

একটি গুরুত্বপূর্ণ বিষয় লক্ষণীয় হ'ল আপনাকে এইচটিটিপিএস ব্যবহার করে ক্লায়েন্টকে নিরাপদে জেডাব্লুটি সরবরাহ করতে হবে এবং এটি একটি নিরাপদ জায়গায় সংরক্ষণ করতে হবে (উদাহরণস্বরূপ স্থানীয় সঞ্চয়স্থান)।

আপনি এই লিঙ্কটি থেকে জেডব্লিউটি সম্পর্কে আরও শিখতে পারেন