আপনার অ্যাপে লগইন কীভাবে যুক্ত করবেন: পাসওয়ার্ড, ম্যাজিক লিংক, Google ও রোল

আপনার অ্যাপে লগইন যুক্ত করতে একটি পদ্ধতি বেছে নিন — ইমেইল ও পাসওয়ার্ড, ম্যাজিক লিংক (ইমেইলে পাঠানো একবারের সাইন-ইন লিংক), অথবা "Sign in with Google" — এবং শূন্য থেকে না লিখে একটি প্রমাণিত auth লাইব্রেরি বা হোস্টেড প্রোভাইডার দিয়ে বাস্তবায়ন করুন। তারপর ঠিক করুন প্রতি ধরনের ব্যবহারকারী কী করতে পারবে (রোল), এবং প্রতিটি পেজ ও API রিকোয়েস্টে সার্ভারে তা কার্যকর করুন। সেশন সুরক্ষিত কুকি ব্যবহার করবে, মেয়াদোত্তীর্ণ হবে, এবং লগআউটে সঠিকভাবে শেষ হবে।

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

প্রথমে সিদ্ধান্ত নিন: আপনার আদৌ লগইন দরকার কিনা

লগইন ঘর্ষণ ও দায়িত্ব বাড়ায়। যখন দরকার:

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

মার্কেটিং সাইট, পাবলিক ডিরেক্টরি, বা শুধু আপনাকে ইমেইল পাঠায় এমন ফর্মের জন্য হয়তো লাগে না। ওয়েটলিস্টে অ্যাকাউন্ট লাগে না; একটি ইমেইল ফিল্ডই যথেষ্ট।

চারটি সাধারণ লগইন পদ্ধতি

অনেক অ্যাপ দুটো মেশায়: Google সাইন-ইন ও ইমেইল ম্যাজিক লিংক একটি জনপ্রিয় জুটি, যা কোনো পাসওয়ার্ড সংরক্ষণ না করেই বেশিরভাগ মানুষকে ধরে।

ইমেইল ও পাসওয়ার্ড

পাসওয়ার্ড অফার করলে এগুলো অপরিহার্য:

• একটি ধীর পাসওয়ার্ড-হ্যাশিং অ্যালগরিদম দিয়ে পাসওয়ার্ড হ্যাশ করুন। OWASP-এর পাসওয়ার্ড সংরক্ষণ নির্দেশিকা Argon2id সুপারিশ করে, বিকল্প হিসেবে scrypt, bcrypt বা PBKDF2। পাসওয়ার্ড কখনো সাধারণ টেক্সটে বা দ্রুত সাধারণ হ্যাশে রাখবেন না।
• পাসওয়ার্ড রিসেট একটি এলোমেলো, একবারের, মেয়াদোত্তীর্ণ হওয়া লিংক ব্যবহার করে, যাচাই করা ইমেইলে পাঠানো।
• কোন ইমেইলের অ্যাকাউন্ট আছে তা প্রকাশ করবেন না। "ওই ইমেইল নিবন্ধিত থাকলে আমরা একটি রিসেট লিংক পাঠিয়েছি" বলা ভালো, "কোনো অ্যাকাউন্ট পাওয়া যায়নি" বলার চেয়ে।
• লগইন ও রিসেট চেষ্টায় রেট লিমিট দিন, যাতে পাসওয়ার্ড অনুমান ধীর হয়।
• লম্বা পাসওয়ার্ড ও পাসওয়ার্ড ম্যানেজার অনুমতি দিন; অদ্ভুত অক্ষর মেশানোর জোরজবরদস্তি নিয়ম বাদ দিন।

ম্যাজিক লিংক ও একবারের কোড

ম্যাজিক লিংক হলো ব্যবহারকারীর কাছে ইমেইলে পাঠানো একটি সাইন-ইন লিংক। ক্লিক করলে সে লগইন হয়ে যায়। একবারের কোড একই ধারণা, তবে ক্লিকের বদলে টাইপ করে।

• লিংক ও কোড দ্রুত মেয়াদোত্তীর্ণ হয় এবং একবারই কাজ করে।
• লিংকটি যে ডিভাইসে ক্লিক হয়েছে সেখানেই ব্যবহারকারীকে লগইন করা উচিত, এবং টোকেন লগ বা অ্যানালিটিক্স টুলে থেকে যাবে না।
• নির্ভরযোগ্য ইমেইল পাঠানো দরকার — দেখুন অ্যাপ থেকে ইমেইল পাঠাবেন কীভাবে। Gmail ও Outlook-এ পরীক্ষা করুন এবং স্প্যাম ফোল্ডারও দেখুন।

Google দিয়ে সাইন ইন (এবং অন্য OAuth প্রোভাইডার)

"Sign in with Google" OAuth ও OpenID Connect ব্যবহার করে: Google নিশ্চিত করে ব্যবহারকারী কে, এবং আপনার অ্যাপকে তার ইমেইল ও নাম জানায়। সেপ্টেম্বর ২০২৬ পর্যন্ত সেটআপ হয় Google Cloud Console-এর Google Auth Platform অংশে:

1. একটি প্রজেক্ট তৈরি বা নির্বাচন করুন, এবং Branding পেজ পূরণ করুন — consent screen-এ ব্যবহারকারীরা যা দেখে (অ্যাপের নাম, সাপোর্ট ইমেইল, লোগো)।
2. Clients পেজে "Web application" ধরনের একটি client তৈরি করুন।
3. authorized JavaScript origins ও redirect URIs যোগ করুন — আপনার অ্যাপ যে সঠিক ঠিকানায় চলে এবং সাইন-ইনের পরে Google ব্যবহারকারীকে যেখানে ফেরত পাঠায়।
4. client ID ও client secret আপনার অ্যাপের সিক্রেটে রাখুন।

Google-এর OAuth ডকুমেন্টেশন অনুযায়ী যেসব সমস্যা সাধারণত হয়:

• redirect_uri_mismatch: redirect ঠিকানা হুবহু মিলতে হবে, http বনাম https, বড়-ছোট হাতের অক্ষর ও শেষের স্ল্যাশসহ। আপনার প্রিভিউ ঠিকানা ও লাইভ ডোমেইন দুটোর জন্য একটি করে যোগ করুন।
• HTTPS লাগে: redirect URI HTTPS ব্যবহার করতে হবে, ডেভেলপমেন্টের সময় localhost ছাড়া।
• state প্যারামিটার ফেরত আসার সময় যাচাই করা উচিত, যাতে ক্রস-সাইট রিকোয়েস্ট ফরজারি থেকে রক্ষা হয়। ভালো লাইব্রেরি এটি নিজেই করে।

আপনি যদি শুধু মৌলিক সাইন-ইন তথ্য (নাম, ইমেইল, প্রোফাইল) চান, Google বলে অ্যাপ যাচাই বাধ্যতামূলক নয়। ব্যবহারকারীদের Gmail, Drive বা Calendar-এ অ্যাক্সেস চাওয়া আলাদা, এবং তার জন্য যাচাই লাগে।

নিজে বানাবেন না প্রোভাইডার ব্যবহার করবেন?

প্রথম দুটোর যেকোনোটি যুক্তিসঙ্গত। হোস্টেড প্রোভাইডার বেশি কাজ নিজে করে কিন্তু একটি নির্ভরতা যোগ করে, আর কখনো সক্রিয় ব্যবহারকারী প্রতি খরচ হয়; বর্তমান দামের জন্য তাদের সাইট দেখুন। লাইব্রেরি সবকিছু আপনার ডাটাবেসে রাখে কিন্তু সঠিকভাবে কনফিগার করার দায়িত্ব বেশি আপনার। যেটাই বাছুন, পাসওয়ার্ড বা সেশন লজিক হাতে লেখার বদলে AI-কে তা ব্যবহার করতে বলুন।

রোল ও অনুমতি

লগইন বলে কে একজন। অনুমতি ঠিক করে কী করতে পারবে। শুরুতে সহজ রাখুন:

রোলের নামের চেয়ে বেশি গুরুত্বপূর্ণ নিয়মগুলো:

• সার্ভারে প্রতিবার যাচাই করুন। পেজে কোনো বোতাম লুকানো কাউকে সরাসরি API ডাকা থেকে আটকায় না।
• মালিক অনুযায়ী সীমিত করুন। একজন সদস্য "booking 123" আনলে তা শুধু তার নিজের হলে পাওয়া উচিত।
• ব্যবহারকারীরা নিজেকে প্রোমোট করতে পারে না। প্রোফাইল আপডেটে ব্রাউজার থেকে পাঠানো রোল ফিল্ড উপেক্ষা করুন।
• ডিফল্ট হোক কোনো অ্যাক্সেস নয়। আপনি ভিন্ন সিদ্ধান্ত না নিলে নতুন রুটের লগইন লাগা উচিত।

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

সেশন নিরাপত্তা

লগইনের পরে অ্যাপ একটি সেশনের মাধ্যমে ব্যবহারকারীকে মনে রাখে — সাধারণত একটি কুকি। OWASP-এর সেশন ব্যবস্থাপনা নির্দেশিকা সুপারিশ করে:

• সেশন কুকি সেট হয় Secure (শুধু HTTPS), HttpOnly (পেজ স্ক্রিপ্ট পড়তে পারে না) ও SameSite সহ
• লগইনে একটি নতুন সেশন ID দেওয়া হয়, এবং অধিকার বদলালেও আবার
• একটি নিষ্ক্রিয়তা টাইমআউট ও সর্বোচ্চ আয়ুষ্কাল আছে, সার্ভারে কার্যকর
• লগআউট সেশন সার্ভারে শেষ করে, শুধু কুকি মোছে না
• ব্যবহারকারী পাসওয়ার্ড বদলালে সেশন বাতিল হয়

টিউটোরিয়ালে ব্রাউজারের লোকাল স্টোরেজে লগইন টোকেন রাখা সাধারণ, কিন্তু এতে পেজে চলা যেকোনো স্ক্রিপ্ট সেগুলো পেতে পারে; ওয়েব অ্যাপের জন্য সুরক্ষিত কুকিই সাধারণত ভালো ডিফল্ট।

মূল বিষয়গুলো ঢাকা একটি প্রম্পট

এই অ্যাপে ব্যবহারকারী অ্যাকাউন্ট যোগ করো। ব্যবহারকারীরা ইমেইল ও পাসওয়ার্ড দিয়ে সাইন আপ ও লগইন করতে পারবে, অথবা Google দিয়ে। কাস্টম auth কোড না লিখে [লাইব্রেরি বা প্রোভাইডার] ব্যবহার করো। পাসওয়ার্ড Argon2id বা bcrypt দিয়ে হ্যাশ করো। ইমেইলে একবারের, এক ঘণ্টায় মেয়াদোত্তীর্ণ হওয়া লিংক সহ পাসওয়ার্ড রিসেট যোগ করো। সেশন নিরাপদ, HttpOnly কুকিতে রাখো। /dashboard ও প্রতিটি /api রুট সুরক্ষিত করো যাতে শুধু লগইন করা ব্যবহারকারী ব্যবহার করতে পারে, এবং ব্যবহারকারীরা শুধু নিজের প্রজেক্ট দেখতে পারে। সব ব্যবহারকারী দেখতে পারে এমন একটি "admin" রোল যোগ করো; শুধু অ্যাডমিন /admin-এ যেতে পারবে, সার্ভারে যাচাই করে।

তারপর পরীক্ষা করুন: সাইন আপ করুন, লগআউট করুন, লগইন করুন, পাসওয়ার্ড রিসেট করুন, লগআউট অবস্থায় একটি ব্যক্তিগত URL চেষ্টা করুন, এবং অন্য ব্যবহারকারীর রেকর্ড চেষ্টা করুন।

AI-বানানো লগইনের সাধারণ ভুল

• শুধু পেজে সুরক্ষা। পেজ লগআউট ব্যবহারকারীকে রিডাইরেক্ট করে, কিন্তু API যে কাউকে ডেটা ফেরত দেয়।
• ব্রাউজারে সিক্রেট। OAuth client secret ও auth প্রোভাইডারের অ্যাডমিন কী সার্ভারে থাকা উচিত।
• প্রিভিউ ও লাইভ URL গুলিয়ে ফেলা। Google-এর redirect URI বা রিসেট ইমেইলের লিংক প্রিভিউয়ের দিকে নির্দেশ করে, তাই প্রকাশের পরে লগইন ভাঙে।
• ইমেইল যাচাই না থাকা। যে কেউ anyone@company.com হিসেবে সাইন আপ করতে পারে। ওই ঠিকানার সাথে যুক্ত কিছু দেওয়ার আগে ইমেইল যাচাই করুন।
• শুধু সঠিক পথ পরীক্ষা করা। ভুল পাসওয়ার্ড, মেয়াদোত্তীর্ণ লিংক ও দ্বিতীয় অ্যাকাউন্ট দিয়ে চেষ্টা করুন।

Mythex-এ লগইন যুক্ত করা

Mythex-এ আপনার অ্যাপের ব্যবহারকারীদের জন্য লগইন হলো এমন কিছু যা আপনি অ্যাপে যুক্ত করেন — এটি আপনার নিজের Mythex অ্যাকাউন্ট থেকে আলাদা। Mythex-এর নিজস্ব বিল্ট-ইন auth পণ্য নেই, তাই আপনি একটি auth লাইব্রেরি বা প্রোভাইডার ও তার কী নিয়ে আসেন:

1. একটি পদ্ধতি বেছে নিন — যেমন আপনার নিজের ডাটাবেসে সংরক্ষিত ইমেইল ও পাসওয়ার্ড, অথবা একটি হোস্টেড প্রোভাইডারের SDK।
2. আপনি নিজে ব্যবহারকারী সংরক্ষণ করলে অ্যাপের একটি ডাটাবেস লাগবে; চ্যাটে চেয়ে নিন বা /database ব্যবহার করুন।
3. প্রোভাইডারের কী প্রজেক্ট সিক্রেটে রাখুন (/secrets বা প্রজেক্ট সেটিংস)।
4. উপরের মতো একটি প্রম্পট ব্যবহার করুন, তারপর Preview-তে পরীক্ষা করুন। Google সাইন-ইনের জন্য প্রিভিউ ও প্রকাশিত ঠিকানা দুটোর জন্যই redirect URI যোগ করুন।

ডকসে দেখুন আপনার অ্যাপে লগইন যুক্ত করুন। আপনি যদি একটি পেইড প্রোডাক্ট বানান, একটি SaaS MVP কীভাবে বানাবেন অ্যাকাউন্ট ও বিলিং একসাথে কভার করে।

প্রশ্নোত্তর