না, তা নয়। এটি বিরক্তিকর, লাল-টেপি, একটি সমাধান করা সমস্যা... তবে এটিকে কম্বল বিবৃতি হিসাবে কঠিন বলবেন না।
আমি "পিএইচপিতে পাসওয়ার্ড হ্যাশ করতে MD5 ব্যবহার করেছি" বছর বয়সী। নিশ্চিত, এটি একটি ভয়ঙ্কর ধারণা ছিল, এমনকি 2012 সালেও। কিন্তু, তারপরে, আমার মনে পড়ে না যে লেখককে "কঠিন" বলে বিবেচনা করেছি। এটি নিজেই একটি খুব সহজবোধ্য অগ্নিপরীক্ষা ছিল - একটি ইমেল বা একটি ব্যবহারকারীর নাম পান, একটি পাসওয়ার্ড পান, এটি হ্যাশ করুন (MD5 সহ, "ঈশ্বর অভিপ্রায়" হিসাবে), এবং আপনি যদি বিশেষভাবে সুরক্ষা সচেতন হন তবে [ লবণ ] পাসওয়ার্ড। কোথাও যে সব সংরক্ষণ করুন, সাধারণত একটি ডাটাবেসে. তা-দা, সাইনআপ হয়ে গেছে।
আজকাল, আখ্যান পরিবর্তন হয়েছে। "অথ ইজ হার্ড" একটি চির-বর্তমান আখ্যানের মতো মনে হয় যা একটি হ্যাকারনিউজ বা রেডডিট ক্লিক দূরে রয়েছে৷ কিন্তু এটা কি সত্যিই? IMO, সত্য হল, auth তৈরি করা কঠিন নয় - যে কেউ এটি শিখতে পারে (এবং কাজের এই লাইনের প্রত্যেকেরই মৌলিক বিষয়গুলি শিখতে হবে)। আসল চ্যালেঞ্জটি অতিরিক্তগুলির মধ্যে রয়েছে: MFA, ব্যবহারকারী পরিচালনা, পাসওয়ার্ড রিসেট, OAuth প্রদানকারীর প্রতিটি এবং বিভিন্ন প্রদানকারীদের থেকে অ্যাকাউন্ট একত্রিত করা। এটা হাজার কাটা দ্বারা মৃত্যু. যেহেতু auth একটি সমাধান করা সমস্যা, তাই চাকাটি পুনরায় উদ্ভাবন করা আপনার সময়ের সর্বোত্তম ব্যবহার নয়। কিন্তু এর অর্থ এই নয় যে "প্রমাণ কঠিন" কারণ একটি কম্বল বিবৃতি সঠিক বা এমনকি সঠিকের কাছাকাছি। আপনার পরীক্ষা করা উচিত, মূল বিষয়গুলি বোঝা এবং সেখান থেকে তৈরি করা উচিত। আপনি যা তৈরি করছেন তার স্কেল (বা সম্ভাব্য স্কেল) দিয়ে জটিলতা বৃদ্ধি পায়।
সুতরাং, কতটা কঠিন প্রমাণীকরণ সত্যিই হতে পারে? এর খনন করা যাক.
পিএইচপি এবং এমডি 5 সম্পর্কে আমি যেখানে গল্পটি রেখেছিলাম সেখানে পিক আপ করা, একটি লগইন কার্যকারিতা তৈরি করা একই ধরণের ধাপ অনুসরণ করে; একটি ইমেল এবং একটি পাসওয়ার্ড পান, আপনার সঞ্চয়স্থানে ইমেলের অস্তিত্ব পরীক্ষা করুন, সেই ইমেলের জন্য সংরক্ষিত লবণের সাথে পাসওয়ার্ডটি হ্যাশ করুন, ডাটাবেসে সংরক্ষিত একটির সাথে ফলাফলের হ্যাশের তুলনা করুন এবং যদি এটি সব ঠিকঠাক কাজ করে, setcookie
মাধ্যমে একটি কুকি সেট করুন (আমরা এখনও এখানে পিএইচপি ল্যান্ডে আছি - এমন নয় যে অন্যান্য ইকোসিস্টেমের সামগ্রিক যুক্তি খুব আলাদা ছিল)।
সাইন আউট করা আরও সহজ ছিল - শুধু সার্ভারে কুকি বাতিল করুন এবং আপনার কাজ শেষ। সার্ভার যদি পরবর্তী অনুরোধের সাথে একটি কুকি দেখতে না পায়, তাহলে আপনি লগ ইন করেননি৷ তাই প্রমাণীকৃত রুটগুলি করাও সামগ্রিকভাবে একটি সাধারণ অগ্নিপরীক্ষা ছিল৷ অনুমতির ক্ষেত্রে জিনিসগুলি লোমশ হয়ে উঠতে পারে, তবে প্রায়শই না, আমাকে যে অ্যাপগুলি তৈরি করতে হয়েছিল, আমাদের কাছে কেবল অ্যাডমিন এবং ব্যবহারকারী ছিল। কোনটি এমন কিছু যা আপনি কেবল ব্যবহারকারীর রেকর্ডের সাথে বা অনুমতি সারণীতে একত্রে সঞ্চয় করতে পারেন যদি আপনার অ্যাপের জন্য আপনার ভূমিকার পরিমাণ প্রসারিত করার প্রয়োজন হয়।
সম্পূর্ণ প্রকাশ—আমি সুপারটোকেনের জন্য কাজ করি। এই অংশটি, যাইহোক, একটি কম্বল বিবৃতি হিসাবে প্রমাণীকরণ কতটা কঠিন সে সম্পর্কে একটি সর্বব্যাপী বর্ণনার উপর ব্যক্তিগত হতাশা থেকে জন্মগ্রহণ করা হয়েছে। অন্য কথায়, আমি "আপনাকে আমার জিনিস বিক্রি করার" চেষ্টা করছি না। আপনি যা খুশি ব্যবহার করুন.
আজ আমরা যেখানে আছি সেখানে পৌঁছানোর জন্য, আমরা শুরুতে শুরু করব... আশ্চর্যজনক, আমি জানি। আমরা সম্ভবত একমত হতে পারি যে এই উপাদানগুলি একটি ইমেল/পাসওয়ার্ড + সামাজিক লগইন PoC তৈরি করার জন্য যথেষ্ট:
এক্সপ্রেস এবং পাসপোর্টের সাথে যাওয়া, যেহেতু আমরা চাকার নতুন উদ্ভাবন করতে যাচ্ছি না, আমরা খুব, খুব নিস্তেজ এবং পুনরাবৃত্তিমূলক কোডের ঠিক 150 লাইনে পৌঁছেছি: https://github.com/supertokens/auth-express/blob/master/index এমজেএস পরবর্তী বিভাগটি হবে সারফেস-লেভেল ব্যাখ্যাকারী কোডে কী চলছে, তাই আপনি যদি ধারণাগুলির সাথে ইতিমধ্যেই পরিচিত হন তবে নির্দ্বিধায় এগিয়ে যান । এক্সপ্রেস অ্যাপটি যাইহোক একটি PoC।
আসুন দ্রুত এটি বিচ্ছিন্ন করা যাক:
আমি যেভাবে এটি দেখছি, এটির কাছে যাওয়ার দুটি উপায় রয়েছে - রেন্ডারিং দিয়ে শুরু করুন এবং প্রমাণীকরণ রুটে বা অন্য পথে যান। বেশিরভাগ দৈবক্রমে, আমি একজন FE-ভারী pleb হয়েছি (আমি এখনও এসকিউএল করতে পারি, যদি আপনি ভাবছেন), তাই আমি "অন-স্ক্রীন রেন্ডারিং স্টাফ" পদ্ধতির সাথে শুরু করব।
যেহেতু এটি একটি PoC, আমরা সমস্ত প্রতিক্রিয়া-অভিনব যেতে যাচ্ছি না। Ejs সহ প্লেইন ol' SSR ঠিক কাজ করবে: https://github.com/supertokens/auth-express/tree/master/views
কিছু passport.js উদাহরণের উপর ভিত্তি করে, কিন্তু আরও সরলীকৃত, আমাদের নিম্নলিখিত প্রয়োজন:
কিছু ডিপস: npm i passport passport-local express-session
। আসুন সংক্ষেপে প্রতিটি সম্পর্কে যাই:
আমাদের ব্যবহারকারীদের সংরক্ষণ করার একটি জায়গা (উপরে লিঙ্ক করা উদাহরণটি একটি ইন-মেমরি অ্যারে ব্যবহার করে): https://github.com/supertokens/auth-express/blob/master/index.mjs#L13
আমাদের পাসপোর্ট উদাহরণের জন্য কনফিগারেশন এবং ব্যবহারকারীর সন্ধানের জন্য আগত অনুরোধগুলি পরিচালনা করার জন্য আমাদের স্থানীয় কৌশল উদাহরণ: https://github.com/supertokens/auth-express/blob/master/index.mjs#L18
পাসপোর্ট শুরু করুন ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) এবং এক্সপ্রেস-সেশন ( https://github.com/supertokens/auth-express/blob/master/ index.mjs#L69 )।
শব্দভাষা, নিশ্চিত. কঠিন? আমি তাই মনে করি না, অন্তত বাস্তবায়ন-এ-এ-এ-এ-টয় অর্থে নয়। কিন্তু আমরা কিছুক্ষণ আগে ইমেল/পাসওয়ার্ড কম্বো ব্যবহার করে অতীতে চলে এসেছি। আমাদের যা আছে তার উপরে একজন সামাজিক প্রদানকারী যোগ করা কতটা কঠিন তা পরিদর্শন করা যাক।
এখানে একটি উদাহরণ প্রদানকারীর জন্য, আমি একটি সাধারণ কারণে GitHub-এর সাথে যাওয়ার সিদ্ধান্ত নিয়েছি—যদি আপনি সম্পূর্ণরূপে অনুসরণ করার সিদ্ধান্ত নেন, এটি শুরু করার জন্য সবচেয়ে সহজ প্রদানকারীদের মধ্যে একটি (আপনার দিকে তাকিয়ে, Google)।
আপনি যদি সম্পূর্ণভাবে অনুসরণ করার সিদ্ধান্ত নেন, তাহলে এই GitHub কীগুলি কীভাবে পাবেন তা বর্ণনা করে এখানে একটি লিঙ্ক রয়েছে: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth- অ্যাপ ওহ, এবং BTW, রেপোতে থাকাগুলি বৈধ নয়, যদি আপনি চিন্তিত হন ;)
প্রথমত, আমাদের আরও একটি নির্ভরতা প্রয়োজন, npm i passport-github2
। passport-github2 হল পাসপোর্টের জন্য একটি প্রমাণীকরণ কৌশল, যা আমাদের GitHub-এর OAuth2 API-এর সাথে একীভূত করার অনুমতি দেয়।
কিছু হ্যান্ডলার ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) এবং কনফিগারেশন ( https://github.com/supertokens/auth-express/blob/master/ index.mjs#L29-L45 ) পরে, ভাল, এটাই। জটিল? সম্ভবত না। লাল-টেপি? আপনি বাজি ধরুন। বিরক্তিকর? একেবারে। বিশেষ করে যদি আপনি এটি বারবার করতে পান। এটি একটি সমাধান করা সমস্যা; চাকার পুনঃউদ্ভাবন প্রায়শই একজনের সময়ের সর্বোত্তম ব্যবহার নয় যেমনটি আমরা প্রতিষ্ঠিত করেছি।
এখন পর্যন্ত, আমরা সম্ভবত একমত হতে পারি যে Auth তৈরি করা কঠিন নয়। অতএব, এটি এই জাদুকরী জিনিস নয় যে শুধুমাত্র সাদা-দাড়িওয়ালা জাদুকররা যারা JWT-এর রহস্যময় ভাষায় কথা বলে তারা বুঝতে এবং প্রয়োগ করতে পারে।
না, আসলে, আমি যুক্তি দেব যে একজন বিকাশকারী হিসাবে, একজনকে প্রমাণীকরণ কীভাবে কাজ করে তার বেয়ার বেসিকগুলি বোঝা উচিত। এবং আমি প্রায়ই একটি বর্ণনা দেখি যা অন্যথায় দাবি করে - "আমাকে বিশ্বাস করুন, ভাই, আমরা আপনার জন্য এটি পরিচালনা করতে পারি" এর সুরে কিছু। এবং নিশ্চিত, আমি সম্মত যে বেশিরভাগ অংশের জন্য, আপনার নিজের প্রমাণ রোল করা সময়ের অপচয়। তবে এটি তৈরি করা এত কঠিন নয় এবং এটি অবশ্যই একটি রহস্যময় জিনিস নয়। যেখানে এটি সত্যই লোমশ হয়ে ওঠে তা আশেপাশের প্রমাণ এবং ব্যবহারকারীর অভিজ্ঞতার সাথে।
এটি বিবেচনা করুন - উপরের উদাহরণে, আমাদের কাছে একটি কার্যকরী প্রমাণীকরণ জিনিস রয়েছে। সাজানোর। কিন্তু এটি যা করতে পারে না তা এখানে (নিবন্ধ ওপেনারেও উল্লেখ করা হয়েছে):
আমরা সম্ভবত এই প্রতিটি বাস্তবায়ন করতে পারেন. এবং তার নিজের উপর, প্রতিটি টুকরা সহজ বিবেচনা করা যেতে পারে। কিন্তু এটা যোগ. সুতরাং, এটি অগত্যা বাস্তবায়ন নয়—এটি এটি বজায় রাখা, এর জন্য দায়ী হওয়া, মানদণ্ডের সাথে আপ টু ডেট থাকা, নিরাপত্তা লঙ্ঘন ইত্যাদি। এছাড়াও, হাতের প্রদর্শনী—আপনার মধ্যে কতজন RfC পড়তে পছন্দ করেন? আমি কল্পনা করি না যে আমরা যদি একটি মিটআপে থাকতাম তবে আমি অনেক হাত উত্থাপিত দেখতাম।
আমার বক্তব্য হল প্রমাণ করা সহজ নয়, সামগ্রিকভাবে নেওয়া। অবশ্যই, আমরা উপরে যেমনটি করেছি, আমরা সহজেই একটি PoC-এর জন্য কিছু একত্রিত করতে পারি। কিন্তু এটা যাদুকর নয়, এটা বোঝা অসম্ভব নয়, এবং দয়া করে বলবেন না যে এটা। সেই চিন্তাধারা (এবং বিপণন), IMO, সামগ্রিকভাবে শিল্পের জন্য ক্ষতিকর।
সুতরাং, স্বাভাবিক ফলো-আপ প্রশ্নটি হবে - কখন আপনার নিজের রোল করা উচিত?
...সব উপায়ে আমি এমনকি এটা উত্সাহিত চাই. তুমি করে অনেক কিছু শিখেছ, তাহলে কেন পারো না? যদি আপনার ইন্ডি/টয় প্রোজেক্ট বা ব্লগে যথেষ্ট ব্যবহারকারীর ভিত্তি বা অনুসরণ করা হয়, তাহলে এটিকে একটি পরিষেবা, একটি স্ব-হোস্টেড সমাধান বা অন্য কিছুতে পরিবর্তন করুন। সর্বোপরি, সেই সময়ে আপনার কাছে একটি পণ্য রয়েছে এবং আপনার সময় নিঃসন্দেহে প্রমাণীকরণ বজায় রাখার পরিবর্তে সেই পণ্যটি তৈরিতে আরও ভাল ব্যয় হবে।
সাধারণত, আপনি যদি পণ্য তৈরি করছেন, আপনার নিজের প্রমাণীকরণ করবেন না। এটি একটি খুব বিরক্তিকর এবং লাল-টেপি চাকা পুনরায় উদ্ভাবন করছে। আপনার থেকে বেছে নেওয়ার জন্য প্রচুর বিকল্প রয়েছে। প্লাস, আপনি কিছু নির্মাণ করছেন, তাই না? আপনার পণ্য প্রমাণীকরণ না হলে আমরা কেন এই কথোপকথন করছি?
করবেন না। স্টার্টআপগুলির মতো একই কারণ - তবে এটি অবশ্যই এখানে আরও প্রযোজ্য।
আপনি সম্ভবত দেখতে পারেন যেখানে আমি এই সঙ্গে যাচ্ছি. "প্রমাণ করা কঠিন" হল, আমি বলব, একটি বিপণন পিচ যখন একটি কম্বল বিবৃতি হিসাবে ব্যবহৃত হয়। আপনি প্রমাণ বুঝতে পারেন, আপনি এটি তৈরি করতে পারেন, কিন্তু এটি বিরক্তিকর, এটি বজায় রাখা মজাদার নয় এবং এটি একটি সমস্যা যা সমাধান করা হয়েছে৷ এইভাবে, এটি একটি পণ্য হিসাবে বিবেচিত হতে পারে - যেটি আপনি যে ফ্লেভারটি বেছে নিন তাকটি বেছে নিতে পারেন (নীচে কিছু বিকল্প)।
যারা তাদের স্ট্যাকের মালিকানায় রয়েছে (যেমনটি সত্যিই আপনার), আপনার কাছেও বেছে নেওয়ার জন্য প্রচুর বিকল্প রয়েছে:
অথ libs
প্রমাণ সার্ভার
স্টোরেজ + প্রমাণ
সুতরাং, আপনি যদি Auth-এর জন্য থার্ড-পার্টি সফ্টওয়্যার ব্যবহার করতে না চান, তবুও আপনি আপনার প্রয়োজন এবং পছন্দের উপর নির্ভর করে শেলফ থেকে একটি ওপেন-সোর্স বেছে নিতে পারেন এবং এটির সাথে রোল করতে পারেন।
আমার "বড়" টেকঅ্যাওয়ে হল চাকার নতুন উদ্ভাবন এড়াতে, বিশেষ করে যদি এটি একটি সমাধান করা সমস্যা হয়, যেমন প্রমাণ করা হয়। উল্লিখিত চাকা সম্পর্কে শিক্ষিত হন, তাদের সাথে পরীক্ষা করুন, একটি খেলনা চাকা তৈরি করুন এবং এটি বুঝুন। কিন্তু দয়া করে, অনুগ্রহ করে, এটিকে বোঝা এবং নির্মাণ করা অসম্ভব কঠিন জিনিস হিসাবে এটি বিক্রি করবেন না। শিক্ষিত করুন, গেটকিপ করবেন না।