সমস্যা সম্পর্কিত মূল অনুরোধ সমাধান
পাসকিগুলি একটি নির্দিষ্ট ওয়েবসাইটের সাথে সংযুক্ত থাকে এবং শুধুমাত্র সেই ওয়েবসাইটে সাইন ইন করার জন্য ব্যবহার করা যেতে পারে যার জন্য তারা তৈরি করা হয়েছিল৷
এটি নির্ভরকারী পার্টি আইডি (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
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 ব্যবহারকারীর এজেন্ট বা আপনার ব্যবহারকারীরা যে শংসাপত্র ম্যানেজার ব্যবহার করছেন তাতে ব্যবহারকারী-দৃশ্যমান ধারণা হওয়া উচিত নয়। পরিবর্তে, ব্যবহারকারী এজেন্ট এবং শংসাপত্র পরিচালকদের উচিত ব্যবহারকারীদের দেখানো উচিত যেখানে তাদের শংসাপত্র ব্যবহার করা হয়েছে। এই পরিবর্তন বাস্তবায়নে সময় লাগবে। একটি অস্থায়ী সমাধান বর্তমান ওয়েবসাইট এবং মূল নিবন্ধন সাইট উভয় প্রদর্শন করা হবে.