সম্পর্কিত মূল অনুরোধের সাথে আপনার সাইট জুড়ে পাসকি পুনরায় ব্যবহারের অনুমতি দিন

সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

Maud Nalpas

সমস্যা সম্পর্কিত মূল অনুরোধ সমাধান

পাসকিগুলি একটি নির্দিষ্ট ওয়েবসাইটের সাথে সংযুক্ত থাকে এবং শুধুমাত্র সেই ওয়েবসাইটে সাইন ইন করার জন্য ব্যবহার করা যেতে পারে যার জন্য তারা তৈরি করা হয়েছিল৷

এটি নির্ভরকারী পার্টি আইডি (RP ID) তে নির্দিষ্ট করা হয়েছে, যা example.com ডোমেনের জন্য তৈরি করা পাসকিগুলির জন্য www.example.com বা example.com হতে পারে।

যদিও RP আইডি পাসকিগুলিকে সর্বত্র প্রমাণীকরণের জন্য একক শংসাপত্র হিসাবে ব্যবহার করা থেকে বাধা দেয়, তারা এর জন্য সমস্যা তৈরি করে:

• একাধিক ডোমেন সহ সাইট : ব্যবহারকারীরা একই কোম্পানি দ্বারা পরিচালিত বিভিন্ন দেশ-নির্দিষ্ট ডোমেন (উদাহরণস্বরূপ example.com এবং example.co.uk ) জুড়ে সাইন ইন করতে একই পাসকি ব্যবহার করতে পারে না।
• ব্র্যান্ডেড ডোমেন : ব্যবহারকারীরা একটি ব্র্যান্ডের (যেমন acme.com এবং acmerewards.com ) দ্বারা ব্যবহৃত বিভিন্ন ডোমেনে একই শংসাপত্র ব্যবহার করতে পারে না।
• মোবাইল অ্যাপস : মোবাইল অ্যাপের প্রায়ই নিজস্ব ডোমেন থাকে না, যা শংসাপত্র ব্যবস্থাপনাকে চ্যালেঞ্জিং করে তোলে।

আইডেন্টিটি ফেডারেশনের উপর ভিত্তি করে এবং অন্যান্য আইফ্রেমের উপর ভিত্তি করে সমাধান আছে, কিন্তু কিছু ক্ষেত্রে সেগুলি অসুবিধাজনক। সম্পর্কিত মূল অনুরোধ একটি সমাধান প্রস্তাব.

সমাধান

রিলেটেড অরিজিন রিকোয়েস্টের সাথে, একটি ওয়েবসাইট তার আরপি আইডি ব্যবহার করার জন্য অনুমোদিত উত্স নির্দিষ্ট করতে পারে।

এটি ব্যবহারকারীদের আপনার পরিচালনা করা একাধিক সাইট জুড়ে একই পাসকি পুনরায় ব্যবহার করার সম্ভাবনা আনলক করে।

সম্পর্কিত অরিজিন অনুরোধগুলি ব্যবহার করতে, আপনাকে একটি নির্দিষ্ট URL https://{RP ID}/.well-known/webauthn এ একটি বিশেষ JSON ফাইল পরিবেশন করতে হবে। example.com যদি অতিরিক্ত উত্সকে এটিকে একটি RP আইডি হিসাবে ব্যবহার করার অনুমতি দিতে চায়, তাহলে এটি https://example.com/.well-known/webauthn:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

পরের বার যখন এই সাইটগুলির মধ্যে যেকোন একটি পাসকি তৈরির ( navigator.credentials.create ) বা প্রমাণীকরণ ( navigator.credentials.get ) এর জন্য একটি কল করে যা example.com একটি RP আইডি হিসাবে ব্যবহার করে, ব্রাউজার একটি RP আইডি লক্ষ্য করবে যা অনুরোধের মূলের সাথে মেলে না৷ ব্রাউজার যদি রিলেটেড অরিজিন রিকোয়েস্ট সমর্থন করে, তাহলে এটি প্রথমে https://{RP ID}/.well-known/webauthn এ একটি webauthn ফাইল খোঁজে। ফাইলটি বিদ্যমান থাকলে, ব্রাউজার চেক করে যে অনুরোধটি করার মূলটি সেই ফাইলটিতে অনুমোদিত কিনা। যদি তাই হয়, এটি পাসকি তৈরি বা প্রমাণীকরণ ধাপে এগিয়ে যায়। যদি ব্রাউজার রিলেটেড অরিজিন রিকোয়েস্ট সমর্থন না করে, তাহলে এটি একটি SecurityError নিক্ষেপ করে।

ব্রাউজার সমর্থন

• Chrome: Chrome 128 থেকে শুরু করে সমর্থিত।
• Safari: macOS 15 বিটা 3 থেকে শুরু করে এবং মোবাইল iOS 18 বিটা 3 থেকে সমর্থিত।
• ফায়ারফক্স: অবস্থানের জন্য অপেক্ষা করছে ।

সম্পর্কিত মূল অনুরোধগুলি কীভাবে সেট আপ করবেন

নিম্নলিখিত ডেমো দুটি সাইটের উদাহরণ ব্যবহার করে, https://ror-1.glitch.me এবং https://ror-2.glitch.me ।
ব্যবহারকারীদের এই উভয় সাইট জুড়ে একই পাসকি দিয়ে সাইন ইন করতে সক্ষম করার জন্য, এটি ror-2.glitch.me তার RP ID হিসাবে ror-1.glitch.me ব্যবহার করার অনুমতি দেওয়ার জন্য সম্পর্কিত অরিজিন অনুরোধগুলি ব্যবহার করে৷

ডেমো

https://ror-2.glitch.me একটি RP আইডি হিসাবে ror-1.glitch.me ব্যবহার করার জন্য রিলেটেড অরিজিন অনুরোধগুলি প্রয়োগ করে, তাই ror-1 এবং ror-2 উভয়ই একটি পাসকি তৈরি করার পরে বা এটির সাথে প্রমাণীকরণ করার পরে একটি RP আইডি হিসাবে ror-1.glitch.me ব্যবহার করে৷
আমরা এই সাইটগুলিতে একটি ভাগ করা পাসকি ডাটাবেসও প্রয়োগ করেছি৷

নিম্নলিখিত ব্যবহারকারীর অভিজ্ঞতা পর্যবেক্ষণ করুন:

• আপনি সফলভাবে একটি পাসকি তৈরি করতে পারেন, এবং এটির সাথে ror-2 এ প্রমাণীকরণ করতে পারেন — যদিও এর RP আইডি ror-1 (এবং ror-2 নয়)।
• একবার আপনি ror-1 বা ror-2 তে একটি পাসকি তৈরি করলে, আপনি এটির সাথে ror-1 এবং ror-2 উভয় ক্ষেত্রেই প্রমাণীকরণ করতে পারেন। কারণ ror-2 একটি RP ID হিসাবে ror-1 নির্দিষ্ট করে, এই সাইটগুলির যেকোনো একটি থেকে একটি পাসকি তৈরি বা প্রমাণীকরণের অনুরোধ করা ror-1 এ অনুরোধ করার মতোই। আরপি আইডিই একমাত্র জিনিস যা একটি অনুরোধকে মূলের সাথে সংযুক্ত করে।
• একবার আপনি ror-1 বা ror-2 তে একটি পাসকি তৈরি করলে, এটি Chrome-এর দ্বারা ror-1 এবং ror-2 উভয়তেই স্বয়ংক্রিয়ভাবে পূরণ করা যেতে পারে।
• এই সাইটের যেকোনো একটিতে তৈরি করা শংসাপত্রের একটি RP ID থাকবে ror-1 ।

কোড দেখুন:

• ror-1 কোডবেসে সেট আপ করা ./well-known/webauthn ফাইলটি দেখুন।
• ror-2 কোডবেসে RP_ID_ROR ঘটনাগুলি দেখুন।

ধাপ 1: একটি শেয়ার্ড অ্যাকাউন্ট ডাটাবেস প্রয়োগ করুন

আপনি যদি চান যে আপনার ব্যবহারকারীরা site-1 এবং site-2 জুড়ে একই পাসকি দিয়ে সাইন ইন করতে সক্ষম হন, তাহলে এই দুটি সাইট জুড়ে শেয়ার করা একটি অ্যাকাউন্ট ডাটাবেস বাস্তবায়ন করুন।

ধাপ 2: সাইট-1-এ আপনার .well-known/webauthn JSON ফাইল সেট আপ করুন

প্রথমে, site-1.com কনফিগার করুন যাতে এটি site-2.com এটিকে RP আইডি হিসাবে ব্যবহার করতে দেয়। এটি করতে, আপনার webauthn JSON ফাইল তৈরি করুন:

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON অবজেক্টে অবশ্যই কী নামের অরিজিন থাকতে হবে যার মান হল ওয়েব অরিজিন ধারণকারী এক বা একাধিক স্ট্রিংয়ের অ্যারে।

গুরুত্বপূর্ণ সীমাবদ্ধতা: সর্বোচ্চ 5টি লেবেল

এই তালিকার প্রতিটি উপাদান eTLD + 1 লেবেল বের করার জন্য প্রক্রিয়া করা হবে। উদাহরণস্বরূপ, example.co.uk এবং example.de এর eTLD + 1 লেবেল দুটিই example । কিন্তু example-rewards.com এর eTLD + 1 লেবেল হল example-rewards । ক্রোমে, লেবেলের সর্বোচ্চ সংখ্যা ৫টি।

ধাপ 3: সাইট-1-এ আপনার .well-known/webauthn JSON পরিবেশন করুন

তারপর, site-1.com/.well-known/webauthn .well-known/webauthn এর অধীনে আপনার JSON ফাইলটি পরিবেশন করুন।

উদাহরণস্বরূপ, এক্সপ্রেসে:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

এখানে, আমরা এক্সপ্রেস res.json ব্যবহার করছি, যা ইতিমধ্যেই সঠিক content-type ( 'application/json' );

ধাপ 4: সাইট-2-এ কাঙ্খিত RP ID উল্লেখ করুন

আপনার site-2 কোডবেসে, site-1.com ১.কমকে যেখানে প্রয়োজন সেখানে RP আইডি হিসেবে সেট করুন:

• শংসাপত্র তৈরি করার পরে:
  • navigator.credentials.create ফ্রন্টএন্ড কলে পাস করা শংসাপত্র তৈরির options site-1.com RP ID হিসাবে সেট করুন এবং সাধারণত সার্ভার-সাইডে তৈরি করা হয়।
  • প্রত্যাশিত RP আইডি হিসাবে site-1.com সেট করুন, যেহেতু আপনি এটিকে আপনার ডাটাবেসে সংরক্ষণ করার আগে শংসাপত্র যাচাইকরণ চালান।
• প্রমাণীকরণের উপর:
  • navigator.credentials.get ফ্রন্টএন্ড কল, এবং সাধারণত সার্ভার-সাইড জেনারেট করা প্রমাণীকরণ options site-1.com RP ID হিসাবে সেট করুন।
  • site-1.com সার্ভারে যাচাই করা প্রত্যাশিত RP আইডি হিসাবে সেট করুন, যেহেতু আপনি ব্যবহারকারীকে প্রমাণীকরণের আগে শংসাপত্র যাচাইকরণ চালান।

সমস্যা সমাধান

অন্যান্য বিবেচনা

সাইট এবং মোবাইল অ্যাপ জুড়ে পাসকি শেয়ার করুন

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

• ক্রোমে: ডিজিটাল সম্পদ লিঙ্ক । ডিজিটাল সম্পদ লিঙ্কের জন্য সমর্থন যোগ করুন এ আরও জানুন।
• সাফারিতে: যুক্ত ডোমেইন ।

সাইট জুড়ে পাসওয়ার্ড শেয়ার করুন

সম্পর্কিত অরিজিন অনুরোধগুলি আপনার ব্যবহারকারীদের সাইট জুড়ে একটি পাসকি পুনরায় ব্যবহার করার অনুমতি দেয়। সাইট জুড়ে পাসওয়ার্ড শেয়ার করার সমাধান পাসওয়ার্ড পরিচালকদের মধ্যে পরিবর্তিত হয়। Google পাসওয়ার্ড ম্যানেজারের জন্য, ডিজিটাল সম্পদ লিঙ্ক ব্যবহার করুন। সাফারি একটি ভিন্ন সিস্টেম আছে.

শংসাপত্র পরিচালক এবং ব্যবহারকারী এজেন্টদের ভূমিকা

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