WebAuthn वर्चुअल ऑथेंटिकेटर के माध्यम से पासकीज़ E2E प्लेराइट टेस्टिंग

पासकीज़ प्रमाणीकरण विधि के रूप में अधिक से अधिक व्यापक रूप से स्वीकार किए जा रहे हैं, जो अपने अंतर्निहित मानक के रूप में वेब प्रमाणीकरण (WebAuthn) पर निर्भर करते हैं। उनकी लोकप्रियता में वृद्धि काफी हाल की है, जो दस्तावेज़ीकरण और अन्य संसाधनों को अपेक्षाकृत दुर्लभ बनाती है। यह, पासकीज़ को लागू करने की जटिल प्रकृति के साथ, डेवलपर्स के लिए अपने प्लेटफ़ॉर्म और सेवाओं के लिए पासकीज़ को डिज़ाइन करने, लागू करने और विशेष रूप से परीक्षण करने पर प्रासंगिक जानकारी खोजना चुनौतीपूर्ण बना सकता है।

यह गाइड उस अंतर को भरने का लक्ष्य रखता है, जो WebAuthn वर्चुअल ऑथेंटिकेटर के उन पहलुओं पर ध्यान केंद्रित करता है जो इसके आधिकारिक दस्तावेज़ीकरण में पूरी तरह से शामिल नहीं हैं। उदाहरण के लिए, हम वर्चुअल ऑथेंटिकेटर के लिए कॉन्फ़िगरेशन विकल्पों पर चर्चा करते हैं जो दस्तावेज़ीकरण में स्व-व्याख्यात्मक नहीं हैं, साथ ही कुछ उपयोग मामलों के लिए वर्कअराउंड भी हैं जिनके लिए वर्चुअल ऑथेंटिकेटर एक सुविधाजनक समाधान प्रदान नहीं करता है। अन्यथा, यह गाइड उन डेवलपर्स के लिए भी सहायक है जो बस परीक्षण कोड में वर्चुअल ऑथेंटिकेटर का उपयोग करने के लिए आसान-से-पालन उदाहरणों की तलाश में हैं।

हमारी गाइड आपके प्रोजेक्ट में पासकी कार्यान्वयन का प्रभावी ढंग से परीक्षण करने के लिए एक सरल वॉकथ्रू प्रदान करने के लिए Playwright के उदाहरणों का उपयोग करती है। Playwright एक एंड-टू-एंड (E2E) परीक्षण ढांचा है जो ब्राउज़र ऑटोमेशन के लिए प्रोटोकॉल के रूप में क्रोम डेवटूल्स प्रोटोकॉल (CDP) का उपयोग करता है। यदि आप विशेष रूप से Playwright में पासकीज़ के परीक्षण के तकनीकी उदाहरणों की तलाश में हैं, तो आप सीधे धारा 5 पर जा सकते हैं। दूसरी ओर, यदि आप Puppeteer या Selenium जैसे अन्य E2E परीक्षण ढांचे का उपयोग कर रहे हैं और इन ढांचों पर पासकीज़ का परीक्षण करना चाहते हैं, तो परीक्षण कोड कार्यान्वयन इस गाइड में दिए गए उदाहरणों के समान या बहुत समान होंगे, यह इस बात पर निर्भर करता है कि आप किस ढांचे का उपयोग कर रहे हैं। अगले भाग में हम विभिन्न E2E ढांचों पर एक पृष्ठभूमि प्रदान करते हैं और यह गाइड इन ढांचों के लिए कितनी प्रासंगिक होगी।

ब्राउज़र ऑटोमेशन, जैसा कि नाम से पता चलता है, वेब से डेटा स्क्रैप करने या हमारे मामले में वेब अनुप्रयोगों का परीक्षण करने के उद्देश्यों के लिए ब्राउज़र पर दोहराए जाने वाले उपयोगकर्ता कार्यों को स्वचालित करने की प्रक्रिया है। WebDriver और Chrome DevTools Protocol (CDP) दो मुख्य ब्राउज़र ऑटोमेशन प्रोटोकॉल हैं जो इस गाइड के लिए प्रासंगिक हैं, क्योंकि वे प्रत्येक WebAuthn वर्चुअल ऑथेंटिकेटर का कार्यान्वयन प्रदान करते हैं।

WebDriver एक रिमोट-नियंत्रित इंटरफ़ेस है जिसे क्लाइंट और ब्राउज़र के बीच संचार में एक बिचौलिए के रूप में देखा जा सकता है। इस प्रोटोकॉल का ध्यान एक प्लेटफ़ॉर्म- और भाषा-तटस्थ इंटरफ़ेस प्रदान करना है जो फ़ायरफ़ॉक्स और सफारी जैसे गैर-क्रोमियम-आधारित ब्राउज़रों सहित सभी प्रमुख ब्राउज़रों का समर्थन करता है। चूंकि WebDriver इंटरफ़ेस को क्लाइंट के साथ-साथ ब्राउज़र के साथ भी एक कनेक्शन प्रबंधित करने की आवश्यकता होती है, यह दृष्टिकोण ब्राउज़र समर्थन की एक विस्तृत श्रृंखला (यानी उच्च अस्थिरता) के बदले में गति और स्थिरता का त्याग करता है। उल्लेखनीय WebDriver क्लाइंट में Selenium और Nightwatch शामिल हैं।

jankaritech से लिया गया

Chrome DevTools Protocol (CDP), दूसरी ओर, क्लाइंट और ब्राउज़र के बीच WebDriver इंटरफ़ेस जैसा कोई बिचौलिया नहीं है। इसके अलावा, क्लाइंट और ब्राउज़र के बीच संचार एक सॉकेट कनेक्शन के माध्यम से होता है, पिछले दृष्टिकोण में क्लाइंट और WebDriver इंटरफ़ेस के बीच धीमे HTTP कनेक्शन के विपरीत। ये बिंदु CDP को WebDriver की तुलना में बहुत तेज़ और कम अस्थिर बनाते हैं। इसका नकारात्मक पक्ष यह है कि यह प्रोटोकॉल केवल क्रोम और एज जैसे क्रोमियम-आधारित ब्राउज़रों के लिए समर्थित है। Playwright और Puppeteer उदाहरण क्लाइंट हैं जो ब्राउज़रों के साथ संवाद करने के लिए CDP का उपयोग करते हैं।

jankaritech से लिया गया

Puppeteer, Playwright के समान, एक E2E ढांचा है जो सीधे CDP पर बनाया गया है। इसका मतलब है कि Puppeteer और Playwright दोनों WebAuthn वर्चुअल ऑथेंटिकेटर के समान कार्यान्वयन का उपयोग करते हैं और सॉकेट कनेक्शन के माध्यम से WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करके API संचार भी समान है।

यह प्रदर्शित करने के लिए, हम getCredentials विधि को कॉल करने के लिए Playwright और Puppeteer दोनों में परीक्षण कोड की तुलना करते हैं जो अब तक वर्चुअल ऑथेंटिकेटर में पंजीकृत सभी क्रेडेंशियल्स की एक सूची लौटाता है। हम credentialAdded ईवेंट के लिए एक साधारण ईवेंट श्रोता भी संलग्न करते हैं जो तब ट्रिगर होता है जब एक पासकी क्रेडेंशियल सफलतापूर्वक पंजीकृत हो जाता है। कार्यान्वयन के विवरण से भयभीत न हों, क्योंकि उन्हें बाद के अनुभागों में समझाया जाएगा। ये उदाहरण केवल यह प्रदर्शित करने के लिए हैं कि दो ढांचों के बीच कार्यान्वयन कितने समान हैं।

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We've written 150+ blog posts on passkeys.

Join Passkeys Community

Playwright:

const client = await page.context().newCDPSession(page);
await client.send('WebAuthn.enable');
const authenticatorId = const result = await client.send('WebAuthn.addVirtualAuthenticator', { options });
 
...
 
// get all credentials registered in the virtual authenticator
const result = await client.send('WebAuthn.getCredentials', { authenticatorId });
console.log(result.credentials);
 
// add a listener to the credentialAdded event to output a log to the console whenever a passkey credential is registered
client.on('WebAuthn.credentialAdded', () => {
  console.log('Credential Added!');
});

Puppeteer:

const client = await page.target().createCDPSession();
await client.send('WebAuthn.enable');
const authenticatorId = const result = await client.send('WebAuthn.addVirtualAuthenticator', { options });
 
...
 
// get all credentials registered in the virtual authenticator
const result = await client.send('WebAuthn.getCredentials', { authenticatorId });
console.log(result.credentials);
 
// add a listener to the credentialAdded event to output a log to the console whenever a passkey credential is registered
client.on('WebAuthn.credentialAdded', () => {
  console.log('Credential Added!');
});

जबकि परीक्षण कोड की शुरुआत में CDP सत्र को प्रारंभ करने के तरीके थोड़े अलग थे, CDP WebAuthn वर्चुअल ऑथेंटिकेटर API में तरीकों को कॉल करना और घटनाओं को संभालना समान है। इसका मतलब है कि यदि आप Puppeteer में WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करना चाहते हैं, तो आप इस गाइड का लाइन-बाय-लाइन पालन कर सकते हैं।

Become part of our Passkeys Community for updates & support.

Join

Selenium और Nightwatch E2E परीक्षण ढांचे हैं जो ब्राउज़र ऑटोमेशन के लिए WebDriver पर निर्भर करते हैं। जबकि WebDriver के लिए WebAuthn वर्चुअल ऑथेंटिकेटर कार्यान्वयन CDP के लिए इसके कार्यान्वयन से अलग है, उनके API विनिर्देश समान हैं। CDP Webauthn वर्चुअल ऑथेंटिकेटर API में लगभग हर विधि के लिए, आप WebDriver WebAuthn वर्चुअल ऑथेंटिकेटर API में एक संबंधित विधि पा सकते हैं। हालांकि, एक बात ध्यान देने योग्य है कि जबकि CDP WebAuthn वर्चुअल ऑथेंटिकेटर API में एक पासकी सफलतापूर्वक जोड़े जाने या प्रमाणित होने पर ईवेंट श्रोताओं को संलग्न करना संभव था, यह WebDriver समकक्ष में संभव नहीं है।

Selenium:

const driver = await new Builder().forBrowser('chrome').build();
const options = new VirtualAuthenticatorOptions();
await driver.addVirtualAuthenticator(options);
 
...
 
// get all credentials registered in the virtual authenticator
const credentials = await driver.getCredentials();

यह स्पष्ट है कि वर्चुअल ऑथेंटिकेटर इंस्टेंस स्थापित करने और API कॉल करने का सिंटैक्स संबंधित CDP कार्यान्वयन से अलग है। हालांकि, चूंकि दो WebAuthn वर्चुअल ऑथेंटिकेटर के API विनिर्देश बहुत समान हैं, इसलिए WebDriver-आधारित E2E परीक्षण ढांचे पर एक संबंधित कार्यान्वयन लिखने के लिए इस गाइड का पालन करना व्यवहार्य होगा।

Cypress एक E2E परीक्षण ढांचा है जो मुख्य रूप से ऊपर उल्लिखित ढांचों की तरह WebDriver या CDP पर नहीं बनाया गया है। यह ब्राउज़र के साथ संवाद करने के लिए नेटिव JavaScript का उपयोग करता है। हालांकि, यह CDP तक निम्न-स्तरीय पहुंच प्रदान करता है, जिसका अर्थ है कि CDP के WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने के लिए कच्चे CDP कमांड भेजना संभव है।

Subscribe to our Passkeys Substack for the latest news.

Subscribe

क्योंकि इस निम्न-स्तरीय पहुंच के लिए सिंटैक्स थकाऊ और उपरोक्त उदाहरणों से बहुत अलग है, हम इस गाइड में विवरण में नहीं जाएंगे। हालांकि, Cypress में CDP कमांड को कैसे कॉल किया जाए, इस पर आगे की जानकारी इस गाइड में समझाई गई है। इस गाइड में प्रस्तुत CDP WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने के लिए बड़ी तस्वीर की अवधारणाएं अभी भी उन लोगों के लिए प्रासंगिक हैं जो Cypress पर पासकीज़ का परीक्षण करना चाहते हैं।

ऐसे कई कारण हैं जिनकी वजह से पासकी कार्यान्वयन का परीक्षण वेब वातावरण में अन्य, सरल उपयोगकर्ता कार्यों की तुलना में स्वाभाविक रूप से अधिक चुनौतीपूर्ण है। बायोमेट्रिक प्रमाणीकरण के साथ शामिल गतिशील उपयोगकर्ता इंटरैक्शन को संभालने की आवश्यकता, जैसे कि फिंगरप्रिंट स्कैनिंग या चेहरे की पहचान, जटिलता की एक परत जोड़ती है जिसे परीक्षण लिखते समय विस्तार से संबोधित करना व्यावहारिक नहीं हो सकता है। चूंकि प्रमाणीकरण के संदर्भ में सुरक्षा स्वाभाविक रूप से एक प्रमुख चिंता का विषय है, इसलिए यह सुनिश्चित करना भी आवश्यक है कि पासकी प्रमाणीकरण सुरक्षा कमजोरियों के लिए जगह के बिना विभिन्न ब्राउज़रों और उपकरणों में निर्बाध रूप से एकीकृत हो।

पासकी संचालन में शामिल गतिशील उपयोगकर्ता इंटरैक्शन की जटिलता को सरल बनाना, साथ ही विभिन्न ब्राउज़रों और उपकरणों में इसके एकीकरण का परीक्षण करना, WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करके आसान बना दिया गया है।

WebAuthn वर्चुअल ऑथेंटिकेटर WebAuthn मानक में निर्दिष्ट ऑथेंटिकेटर मॉडल का एक सॉफ्टवेयर प्रतिनिधित्व है। यह एक भौतिक ऑथेंटिकेटर डिवाइस के व्यवहार का अनुकरण करता है, जैसे कि एक हार्डवेयर सुरक्षा कुंजी (जैसे YubiKey) या बायोमेट्रिक स्कैनर (जैसे फेस आईडी, टच आईडी या विंडोज हैलो में उपयोग किया जाता है), लेकिन पूरी तरह से सॉफ्टवेयर के भीतर काम करता है (इसलिए कोई भौतिक प्रमाणीकरण या बायोमेट्रिक्स की स्कैनिंग शामिल नहीं है)।

WebAuthn वर्चुअल ऑथेंटिकेटर के दो मुख्य लाभ हैं।

चूंकि WebDriver और CDP ब्राउज़र ऑटोमेशन टूल हैं, यह स्पष्ट है कि इन प्रोटोकॉल में WebAuthn वर्चुअल ऑथेंटिकेटर कार्यान्वयन का प्राथमिक उपयोग मामला स्वचालित परीक्षण है। इन प्रोटोकॉल का लाभ उठाते हुए, वर्चुअल ऑथेंटिकेटर नियंत्रित वातावरण जैसे E2E परीक्षण ढांचे (जैसे Playwright, Cypress, Nightwatch) में पासकी कार्यात्मकताओं का सरल लेकिन व्यापक परीक्षण सक्षम करता है।

CDP का WebAuthn वर्चुअल ऑथेंटिकेटर क्रोम ब्राउज़र के DevTools के माध्यम से भी सुलभ है, और इसका उपयोग मैनुअल परीक्षण या बस प्रदर्शन उद्देश्यों के लिए किया जा सकता है। इस सुविधा के साथ आप एक ऐसे उपकरण पर पासकी इनपुट का अनुकरण कर सकते हैं जो मूल रूप से पासकीज़ का समर्थन नहीं करता है। तदनुसार, पासकीज़ का समर्थन करने वाले डिवाइस पर पासकी-असमर्थित वातावरण का अनुकरण करना भी संभव है।

उपरोक्त स्क्रीनशॉट मैनुअल परीक्षण या प्रदर्शन उद्देश्यों के लिए क्रोम में वर्चुअल ऑथेंटिकेटर का उपयोग करने का एक उदाहरण दिखाता है। आप देख सकते हैं कि वर्चुअल ऑथेंटिकेटर के लिए विभिन्न कॉन्फ़िगरेशन विकल्प संभव हैं, और क्रेडेंशियल्स के जोड़ और विलोपन को भी ट्रैक किया जा सकता है। अपने ब्राउज़र में वर्चुअल ऑथेंटिकेटर का उपयोग करने के बारे में अधिक जानकारी के लिए Google से इस गाइड का संदर्भ लें, जिसमें प्रत्येक के लिए कॉन्फ़िगरेशन विकल्प और अनुशंसित मान शामिल हैं।

जबकि WebAuthn वर्चुअल ऑथेंटिकेटर पासकी कार्यान्वयन के परीक्षण के लिए एक सुरुचिपूर्ण समाधान है, कुछ नुकसान ध्यान देने योग्य हैं।

पूरी तरह से सॉफ्टवेयर-आधारित समाधान होने के नाते, WebAuthn वर्चुअल ऑथेंटिकेटर भौतिक ऑथेंटिकेटर की अनूठी हार्डवेयर विशेषताओं और सुरक्षा सुविधाओं की नकल नहीं कर सकता है। विभिन्न प्लेटफ़ॉर्म ऑथेंटिकेटर (जो एक डिवाइस में निर्मित होते हैं, जैसे स्मार्टफोन पर बायोमेट्रिक स्कैनर) और विभिन्न क्रॉस-प्लेटफ़ॉर्म ऑथेंटिकेटर (जो बाहरी डिवाइस हैं, जैसे हार्डवेयर सुरक्षा कुंजी) का उपयोग करने के बीच के अंतर को WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करके अनुकरण नहीं किया जा सकता है। जबकि विभिन्न प्रकार के प्लेटफ़ॉर्म और क्रॉस-प्लेटफ़ॉर्म ऑथेंटिकेटर के साथ शामिल जटिलताओं का ब्लैक-बॉक्स सरलीकरण WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने के फायदों में से एक है, यदि आप विभिन्न प्रकार के ऑथेंटिकेटर की बारीकियों का अनुकरण और परीक्षण करना चाहते हैं, तो अन्य समाधानों का पता लगाया जाना चाहिए।

WebAuthn को अपेक्षाकृत हाल ही में अपनाने और पासकी तकनीक की नवीनता को देखते हुए, वर्चुअल ऑथेंटिकेटर के आसपास का पारिस्थितिकी तंत्र अभी भी परिपक्व हो रहा है। इसके परिणामस्वरूप व्यापक दस्तावेज़ीकरण की कमी और अनसुलझी तकनीकी चुनौतियां हैं, विशेष रूप से स्वचालित परीक्षण ढांचे के साथ वर्चुअल ऑथेंटिकेटर को एकीकृत करने के संदर्भ में। इस गाइड का उद्देश्य एक स्वचालित परीक्षण वातावरण में पासकीज़ के परीक्षण में व्यापक अंतर्दृष्टि प्रदान करके इस मुद्दे को संबोधित करना है, जबकि इन उपकरणों का उपयोग करने में अभी भी मौजूद असुविधाओं को संबोधित करने और इन समस्याओं के लिए वर्कअराउंड प्रस्तुत करने पर भी ध्यान केंद्रित करना है।

Playwright और इसकी निर्भरताओं की सफल स्थापना के बाद, आप निम्नलिखित सामग्री के साथ .spec.ts या .test.ts में समाप्त होने वाले नाम के साथ एक फ़ाइल बनाकर अपना पहला परीक्षण लिखना तुरंत शुरू कर सकते हैं:

import { test, expect } from "@playwright/test";
 
test("my first test", async ({ page }) => {
    await page.goto("https://passkeys.eu");
 
    // start simulating user actions
});

प्लेराइट में WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने के लिए, बस एक CDP सत्र शुरू करना और एक परीक्षण मामले की शुरुआत में एक वर्चुअल ऑथेंटिकेटर संलग्न करना पर्याप्त है, जैसा कि निम्नानुसार है:

test('signup with passkey', async ({ page }) => {
  // Initialize a CDP session for the current page
  const client = await page.context().newCDPSession(page);
 
  // Enable WebAuthn environment in this session
  await client.send('WebAuthn.enable');
 
  // Attach a virtual authenticator with specific options
  const result = await client.send('WebAuthn.addVirtualAuthenticator', {
    options: {
      protocol: 'ctap2',
      transport: 'internal',
      hasResidentKey: true,
      hasUserVerification: true,
      isUserVerified: true,
      automaticPresenceSimulation: false,
    },
  });
  const authenticatorId = result.authenticatorId;
 
  // Further test steps to simulate user interactions and assertions
...
});

WebAuthn वर्चुअल ऑथेंटिकेटर को कॉन्फ़िगर करने के विकल्प:

• protocol: यह विकल्प उस प्रोटोकॉल को निर्दिष्ट करता है जो वर्चुअल ऑथेंटिकेटर बोलता है। संभावित मान "ctap2" और "u2f" हैं।
• transport: यह विकल्प उस ऑथेंटिकेटर के प्रकार को निर्दिष्ट करता है जिसका वर्चुअल ऑथेंटिकेटर अनुकरण करता है। संभावित मान "usb", "nfc", "ble", और "internal" हैं। यदि "internal" पर सेट किया जाता है तो यह एक प्लेटफ़ॉर्म ऑथेंटिकेटर का अनुकरण करता है, जबकि अन्य मान क्रॉस-प्लेटफ़ॉर्म ऑथेंटिकेटर का अनुकरण करते हैं।
• hasResidentKey: इसे true पर सेट करना Resident Key (यानी क्लाइंट-साइड खोज योग्य क्रेडेंशियल) का समर्थन करता है।
• hasUserVerification: इसे true पर सेट करना User Verification का समर्थन करता है। इसे true के रूप में सेट करने की अनुशंसा की जाती है क्योंकि यह सफल और असफल पासकी इनपुट के अनुकरण की अनुमति देता है।
• isUserVerified: इसे true पर सेट करना एक सफल प्रमाणीकरण परिदृश्य का अनुकरण करता है, जबकि false एक प्रमाणीकरण विफलता की नकल करता है, जैसे कि जब कोई उपयोगकर्ता पासकी इनपुट रद्द कर देता है। ध्यान दें कि यह सेटिंग तभी प्रभावी होती है जब hasUserVerification को true पर सेट किया गया हो।
• automaticPresenceSimulation: जब true पर सेट किया जाता है, तो पासकी इनपुट किसी भी प्रमाणीकरण प्रॉम्प्ट पर स्वचालित रूप से और तुरंत होता है। इसके विपरीत, इसे false पर सेट करने के लिए परीक्षण कोड में पासकी प्रमाणीकरण सिमुलेशन की मैन्युअल शुरुआत की आवश्यकता होती है। दो कारणों से मैन्युअल सिमुलेशन (false) का विकल्प चुनने की अनुशंसा की जाती है:
  • परीक्षण कोड पठनीयता बढ़ाना: स्वचालित सिमुलेशन परीक्षण प्रवाह की समझ को अस्पष्ट कर सकता है, क्योंकि प्रमाणीकरण के प्रयास परीक्षण कोड में स्पष्ट ट्रिगर के बिना अनुकरण किए जाते हैं।
  • अनपेक्षित व्यवहार से बचना: स्वचालित सिमुलेशन का मतलब है कि पासकी इनपुट तब भी ट्रिगर होगा जब परीक्षक को यह पता नहीं है कि पासकी को प्रॉम्प्ट किया गया था। यह विशेष रूप से कंडीशनल UI के लिए एक समस्या है जिसे परीक्षक के लिए अनदेखा करना आसान होगा।

इस खंड में, हम सामान्य और फ्रिंज उपयोग-मामलों दोनों के संदर्भ में WebAuthn वर्चुअल ऑथेंटिकेटर विधियों और घटनाओं के उपयोग का पता लगाते हैं।

यह परीक्षण कोड में WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करते समय सबसे महत्वपूर्ण लेकिन भ्रमित करने वाला कार्य हो सकता है, क्योंकि पासकी इनपुट को ट्रिगर करने के लिए कोई स्पष्ट अंतर्निहित विधि नहीं है। समाधान WebAuthn वर्चुअल ऑथेंटिकेटर कॉन्फ़िगरेशन विकल्पों में निहित है, अर्थात्, isUserVerified और automaticPresenceSimulation। इन विकल्पों के साथ हम नीचे वर्णित दो अलग-अलग दृष्टिकोणों के माध्यम से इस उपयोगकर्ता इंटरैक्शन का अनुकरण कर सकते हैं।

केस 1: एक सफल पासकी इनपुट का अनुकरण

test('signup with passkey', async ({ page }) => {
...
 
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
  await page.getByRole('button', { name: 'Login' }).click();
  // successful passkey input is automatically simulated (isUserVerified=true)
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Welcome!');
 
...
});

एक सफल पासकी इनपुट का अनुकरण करने के लिए आमतौर पर परीक्षण कोड में किसी अतिरिक्त लाइन की आवश्यकता नहीं होती है। अंतिम पंक्ति (await expect...) पृष्ठ के बदलने की प्रतीक्षा करती है (जो अंतर्निहित सफल पासकी इनपुट द्वारा ट्रिगर होती है)।

केस 2: एक रद्द किए गए पासकी इनपुट का अनुकरण (जो UI में परिवर्तन को ट्रिगर नहीं करता है)

एक असफल या रद्द किए गए पासकी इनपुट का परीक्षण करना अधिक जटिल है क्योंकि इससे UI में कोई देखने योग्य परिवर्तन नहीं हो सकता है। दूसरे शब्दों में, पिछले उदाहरण की तरह पृष्ठ के बदलने की प्रतीक्षा करना यह सुनिश्चित करने के लिए पर्याप्त नहीं है कि पासकी इनपुट ने प्रसंस्करण पूरा कर लिया है। यह जांचना कि अंतर्निहित पासकी इनपुट के बाद पृष्ठ नहीं बदला है, अर्थहीन है, क्योंकि जांच लगभग निश्चित रूप से पासकी इनपुट के प्रसंस्करण पूरा होने से पहले हो जाएगी। जबकि वर्चुअल ऑथेंटिकेटर एक सफल पासकी इनपुट को संसाधित होने की प्रतीक्षा करने का एक तरीका प्रदान करता है, ईवेंट उत्सर्जन को सुनकर (जैसा कि दृष्टिकोण 2 में चर्चा की जाएगी), वर्तमान में एक असफल या रद्द किए गए पासकी इनपुट का पता लगाने का कोई अंतर्निहित तरीका नहीं है। एक वर्कअराउंड यह होगा कि पासकी ऑपरेशन पूरा होने की प्रतीक्षा करने के लिए बस एक हार्ड टाइमआउट जोड़ा जाए, इससे पहले कि यह जांचा जाए कि UI वास्तव में वही रहा।

test('signup with passkey', async ({ page }) => {
  // Simulate a set of user actions to trigger a passkey prompt
...
 
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
 
  // Simulate passkey input when prompted in the test
  await inputPasskey(async () => {
    await page.waitForTimeout(300);
    await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
  });
 
  // Further test steps
...
});

किसी भी मामले में, परीक्षण कोड की पठनीयता पासकी ऑपरेशन की अंतर्निहितता से सीमित है। जैसा कि पहले उल्लेख किया गया है, यह अनदेखा करना भी आसान होगा कि कंडीशनल UI कब प्रॉम्प्ट किया जा सकता है, जिस स्थिति में पासकी ऑपरेशन परीक्षकों की जानकारी के बिना स्वचालित रूप से पूरा हो जाएगा।

automaticPresenceSimulation विकल्प के मान को स्विच करके मैन्युअल रूप से एक पासकी इनपुट को ट्रिगर करना पिछले दृष्टिकोण में सामना की गई समस्याओं को हल करता है, अर्थात् परीक्षण-कोड पठनीयता के संदर्भ में।

केस 1: एक सफल पासकी इनपुट का अनुकरण

निम्नलिखित कोड स्निपेट एक सफल पासकी इनपुट का अनुकरण करते हैं:

async simulateSuccessfulPasskeyInput(operationTrigger: () => Promise<void>) {
  // initialize event listeners to wait for a successful passkey input event
  const operationCompleted = new Promise<void>(resolve => {
    client.on('WebAuthn.credentialAdded', () => resolve());
    client.on('WebAuthn.credentialAsserted', () => resolve());
  });
 
  // set isUserVerified option to true
  // (so that subsequent passkey operations will be successful)
  await client.send('WebAuthn.setUserVerified', {
    authenticatorId: authenticatorId,
    isUserVerified: true,
  });
 
  // set automaticPresenceSimulation option to true
  // (so that the virtual authenticator will respond to the next passkey prompt)
  await client.send('WebAuthn.setAutomaticPresenceSimulation', {
    authenticatorId: authenticatorId,
            enabled: true,
  });
 
  // perform a user action that triggers passkey prompt
  await operationTrigger();
 
  // wait to receive the event that the passkey was successfully registered or verified
  await operationCompleted;
 
  // set automaticPresenceSimulation option back to false
  await client.send('WebAuthn.setAutomaticPresenceSimulation', {
    authenticatorId,
            enabled: false,
  });
}

test('signup with passkey', async ({ page }) => {
...
 
  // Simulate passkey input with a promise that triggers a passkey prompt as the argument
  await simulateSuccessfulPasskeyInput(() =>
          page.getByRole('button', { name: 'Create account with passkeys' }).click()
  );
 
...
});

जब आप इसे पहली बार देखते हैं तो हेल्पर फ़ंक्शन काफी डरावना हो सकता है। यह समझने में मदद करता है कि पासकी ऑपरेशन के अनुकरण की सभी तकनीकी जटिलताओं को हेल्पर फ़ंक्शन में सारगर्भित किया गया है। इसका मतलब है कि जब इसका उपयोग परीक्षण कोड के अंदर किया जाता है, तो यह कोड को सरल और स्पष्ट बनाता है, जैसा कि ऊपर दूसरे कोड स्निपेट में देखा जा सकता है।

धारा 6.1.1 में अंतर्निहित दृष्टिकोण की तुलना में, यह स्पष्ट दृष्टिकोण कोड की पठनीयता को भी बढ़ाता है। यह विशेष रूप से तब सहायक होगा जब कंडीशनल UI को प्रॉम्प्ट किया जाता है, क्योंकि यह स्पष्ट दृष्टिकोण डेवलपर्स की जागरूकता के बिना पासकी ऑपरेशन के अनजाने, अंतर्निहित समापन को रोकता है।

अब हेल्पर फ़ंक्शन के प्रत्येक भाग को समझते हैं।

सबसे पहले, हम operationCompleted प्रॉमिस को परिभाषित करते हैं जो या तो WebAuthn.credentialAdded ईवेंट या WebAuthn.credentialAsserted ईवेंट की प्रतीक्षा करता है, जो, जैसा कि नाम से पता चलता है, तब उत्सर्जित होता है जब एक पासकी क्रेडेंशियल क्रमशः पंजीकृत या सत्यापित होता है। इस प्रॉमिस का उपयोग बाद में किया जाएगा।

इसके बाद, isUserVerified विकल्प को true पर सेट किया गया है, ताकि WebAuthn वर्चुअल ऑथेंटिकेटर द्वारा बाद का पासकी ऑपरेशन सफल हो। automaticPresenceSimulation को भी true पर सेट किया गया है, ताकि WebAuthn वर्चुअल ऑथेंटिकेटर वेबपेज से अगले पासकी प्रॉम्प्ट का जवाब देगा।

रेस कंडीशन से बचने के लिए operationTrigger प्रॉमिस की प्रतीक्षा करना आवश्यक है। रेस कंडीशन तब होती है जब वेबपेज automaticPresenceSimulation को true पर सेट करने से पहले पासकी को प्रॉम्प्ट करता है। इसे रोकने के लिए, उपयोगकर्ता क्रिया जो पासकी प्रॉम्प्ट को ट्रिगर करती है, उसे automaticPresenceSimulation को true पर सेट करने के बाद किया जाना चाहिए। उपरोक्त उदाहरण में, उपयोगकर्ता पासकी प्रॉम्प्ट को ट्रिगर करने के लिए 'Create account with passkeys' नामक बटन पर क्लिक करता है।

उपयोगकर्ता क्रिया पूरी होने के बाद, हमें सफल पासकी ऑपरेशन के पूरा होने की प्रतीक्षा करनी चाहिए। यह हेल्पर फ़ंक्शन की शुरुआत में हमारे द्वारा परिभाषित प्रॉमिस की प्रतीक्षा करके किया जाता है। सफल पासकी ऑपरेशन का पूरा होना WebAuthn.credentialAdded या WebAuthn.credentialAsserted ईवेंट के उत्सर्जन द्वारा चिह्नित किया जाता है। उपरोक्त उदाहरण में, जैसा कि उपयोगकर्ता एक पासकी पंजीकृत कर रहा है, WebAuthn.credentialAdded ईवेंट उत्सर्जित होगा।

अंत में, automaticPresenceSimulation विकल्प को वापस false पर सेट कर दिया जाता है, ताकि बाद में परीक्षण कोड में अनजाने पासकी संचालन को होने से रोका जा सके।

केस 2: एक रद्द किए गए पासकी इनपुट का अनुकरण

एक रद्द किए गए पासकी इनपुट के लिए, हमें पिछले मामले के लिए कार्यान्वयन में थोड़ा संशोधन करना होगा। एक सफल पासकी इनपुट के मामले में, ईवेंट होते हैं, अर्थात् WebAuthn.credentialAdded और WebAuthn.credentialAsserted, जो ऑपरेशन के पूरा होने पर उत्सर्जित होते हैं। हालांकि, WebAuthn वर्चुअल ऑथेंटिकेटर एक रद्द या असफल पासकी इनपुट के लिए कोई ईवेंट प्रदान नहीं करता है। इस प्रकार, हमें एक रद्द या असफल पासकी ऑपरेशन के पूरा होने की जांच के लिए एक वैकल्पिक तरीके का उपयोग करना चाहिए।

निम्नलिखित कोड स्निपेट एक असफल पासकी इनपुट का अनुकरण करते हैं:

async simulateFailedPasskeyInput(operationTrigger: () => Promise<void>, postOperationCheck: () => Promise<void>) {
  // set isUserVerified option to false
  // (so that subsequent passkey operations will fail)
  await client.send('WebAuthn.setUserVerified', {
    authenticatorId: authenticatorId,
    isUserVerified: false,
  });
 
  // set automaticPresenceSimulation option to true
  // (so that the virtual authenticator will respond to the next passkey prompt)
  await client.send('WebAuthn.setAutomaticPresenceSimulation', {
    authenticatorId: authenticatorId,
            enabled: true,
  });
 
  // perform a user action that triggers passkey prompt
  await operationTrigger();
 
  // wait for an expected UI change that indicates the passkey operation has completed
  await postOperationCheck();
 
  // set automaticPresenceSimulation option back to false
  await client.send('WebAuthn.setAutomaticPresenceSimulation', {
    authenticatorId,
            enabled: false,
  });
}

 
test('signup with passkey', async ({ page }) => {
  // Simulate a set of user actions to trigger a passkey prompt
...
 
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
 
  // Simulate passkey input when prompted in the test
  await inputPasskey(async () => {
    await page.waitForTimeout(300);
    await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
  });
 
  // Further test steps
...
});

हेल्पर फ़ंक्शन में, ईवेंट श्रोताओं को एक प्रॉमिस पैरामीटर postOperationCheck से बदल दिया जाता है जो automaticPresenceSimulation को वापस false पर सेट करने से पहले एक अपेक्षित UI परिवर्तन होने की प्रतीक्षा करता है।

परीक्षण कोड में, एकमात्र अंतर यह है कि हेल्पर फ़ंक्शन को एक अतिरिक्त प्रॉमिस के साथ कॉल किया जाना चाहिए जो इच्छित UI परिवर्तन की जांच करता है। उपरोक्त उदाहरण में, हम जांचते हैं कि वेब एप्लिकेशन सफलतापूर्वक एक ऐसे पृष्ठ पर नेविगेट हो गया है जिसमें हेडर में 'Something went wrong...' टेक्स्ट है।

जैसा कि धारा 6.1.1 में चर्चा की गई थी, पासकी इनपुट को रद्द करने से UI में कोई देखने योग्य परिवर्तन नहीं हो सकता है। उस अनुभाग में दिए गए उदाहरण की तरह, हमें यह जांचने से पहले एक हार्ड प्रतीक्षा जोड़नी होगी कि UI वास्तव में ऐसे मामलों में समान रहा है:

test('signup with passkey', async ({ page }) => {
...
 
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
 
  // Simulate passkey input with a promise that triggers a passkey prompt as the argument
  await simulateFailedPasskeyInput(
          () => page.getByRole('button', { name: 'Create account with passkeys' }).click(),
          async () => {
            await page.waitForTimeout(300);
            await expect(page.getByRole('heading', { level: 1 })).toHaveText('Please log in');
          }
  );
 
...
});

WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने की सुविधा वेब एप्लिकेशन द्वारा पासकी निर्माण या विलोपन की स्थिति में एक वास्तविक ऑथेंटिकेटर की तरह व्यवहार करने की क्षमता से बढ़ जाती है। एक परीक्षण को बस वेब एप्लिकेशन पर पासकी के निर्माण या विलोपन का अनुकरण करने के लिए उपयोगकर्ता क्रियाएं करने की आवश्यकता होती है, और WebAuthn वर्चुअल ऑथेंटिकेटर परीक्षण कोड की ओर से किसी भी अतिरिक्त काम के बिना स्वचालित रूप से अपनी सहेजी गई क्रेडेंशियल जानकारी को संशोधित करता है।

यहां परीक्षण कोड का उदाहरण दिया गया है जो जांचता है कि वेब एप्लिकेशन ऑथेंटिकेटर में एक नया पासकी ठीक से पंजीकृत करता है:

test('signup with passkey', async ({ page }) => {
...
 
  // Confirm there are currently no registered credentials
  const result1 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result1.credentials).toHaveLength(0);
 
  // Perform user actions to simulate creation of a passkey credential (e.g. user registration with passkey input)
...
 
  // Confirm the passkey was successfully registered
  const result2 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result2.credentials).toHaveLength(1);
 
...
});

इस कोड स्निपेट को धारा 6.1 के कोड स्निपेट के साथ मिलाकर, हम अपने डेमो वेबपेज पर साइनअप प्रवाह का परीक्षण कर सकते हैं। निम्नलिखित वीडियो प्लेराइट के UI मोड में परीक्षण का एक विज़ुअलाइज़ेशन है:

WebAuthn वर्चुअल ऑथेंटिकेटर के साथ एक पासकी क्रेडेंशियल को सत्यापित करना एक पासकी बनाने के समान काम करता है, जिसमें वर्चुअल ऑथेंटिकेटर स्वचालित रूप से एक विशेष क्रेडेंशियल का उपयोग करके किए गए सत्यापन की संख्या का ट्रैक रखता है।

test('login with passkey', async ({ page }) => {
...
 
  // Confirm there is only one credential, and save its signCount
  const result1 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result1.credentials).toHaveLength(1);
  const signCount1 = result1.credentials[0].signCount;
 
  // Perform user actions to simulate verification of a passkey credential (e.g. login with passkey input)
...
 
  // Confirm the credential's new signCount is greater than the previous signCount
  const result2 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result2.credentials).toHaveLength(1);
  expect(result2.credentials[0].signCount).toBeGreaterThan(signCount1);
 
...
});

निम्नलिखित वीडियो हमारे डेमो वेबपेज पर लॉगिन प्रवाह के लिए एक परीक्षण प्रदर्शित करता है:

दूसरी ओर, एक वेब एप्लिकेशन से एक पासकी को हटाने से WebAuthn वर्चुअल ऑथेंटिकेटर के भीतर किसी भी जानकारी को संशोधित नहीं करना चाहिए। वेब एप्लिकेशन को केवल अपने स्वयं के सर्वर में सहेजे गए क्रेडेंशियल्स को हटाने में सक्षम होना चाहिए। केवल उपयोगकर्ता स्वयं ही सचेत रूप से और मैन्युअल रूप से WebAuthn वर्चुअल ऑथेंटिकेटर से एक पासकी क्रेडेंशियल को हटाने में सक्षम होना चाहिए।

test('delete a registered passkey credential', async ({ page }) => {
...
 
  // Confirm there is currently one registered credential
  const result1 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result1.credentials).toHaveLength(1);
 
  // Perform user actions to simulate deletion of a passkey credential
...
 
  // Deleting a passkey credential from a website should not remove the credential from the authenticator
  const result2 = await client.send('WebAuthn.getCredentials', { authenticatorId });
  expect(result2.credentials).toHaveLength(1);
 
...
});

निम्नलिखित वीडियो हमारे डेमो वेबपेज पर एक पासकी क्रेडेंशियल के विलोपन के लिए एक परीक्षण प्रदर्शित करता है:

दूसरे डिवाइस से क्रॉस-डिवाइस प्रमाणीकरण का अनुकरण करने का सबसे सहज तरीका (जिसमें अभी तक पंजीकृत पासकी नहीं है) बस CDP कमांड के माध्यम से WebAuthn वर्चुअल ऑथेंटिकेटर का एक नया उदाहरण जोड़ना है, जैसे:

test('signup with passkey', async ({ page }) => {
...
 
  // add a virtual authenticator for the first device
  const authenticatorId1 = await client.send('WebAuthn.addVirtualAuthenticator', { options });
 
  // perform test actions of the first device
...
 
  // add a virtual authenticator for the second device
  const authenticatorId2 = await client.send('WebAuthn.addVirtualAuthenticator', { options });
 
  // perform test actions of the second device
..
});

कई वर्चुअल ऑथेंटिकेटर की आईडी प्रबंधित करने की जटिलता से बचने के लिए, एक नए डिवाइस का अनुकरण करना भी संभव है, बस एक ही ऑथेंटिकेटर से क्रेडेंशियल्स को हटाकर, और जरूरत पड़ने पर इसे वापस जोड़कर:

 
test('signup with passkey', async ({ page }) => {
...
 
  const result = await client.send('WebAuthn.getCredentials', { authenticatorId });
  const credential = result.credentials[0]; // assuming only one registered passkey
  const credentialId = credential.credentialId;
  await client.send('WebAuthn.removeCredential', { authenticatorId, credentialId });
 
  // Perform test actions of the second device which doesn't have a registered passkey
...
 
  // Call if it's necessary to simulate the first device which has a registered passkey
  await client.send('WebAuthn.addCredential', { credential });
 
  // Perform test actions of the first device
...
});

यह दृष्टिकोण विशेष रूप से उस मामले में कार्यान्वयन को सरल बना सकता है जहां एक नए डिवाइस का अनुकरण करने की आवश्यकता होती है, लेकिन पुराने डिवाइस का अब और उपयोग करने की आवश्यकता नहीं होती है। इस मामले में, आपको बस वर्चुअल ऑथेंटिकेटर से क्रेडेंशियल्स को साफ़ करना होगा और इसके क्रेडेंशियल्स को पूरी तरह से त्यागना होगा:

test('signup with passkey', async ({ page }) => {
...
 
  const result = await client.send('WebAuthn.getCredentials', { authenticatorId });
  const credential = result.credentials[0]; // assuming only one registered passkey
  const credentialId = credential.credentialId;
  await client.send('WebAuthn.clearCredentials', { authenticatorId });
 
  // Perform test actions of the second device which doesn't have a registered passkey
...
});

WebAuthn वर्चुअल ऑथेंटिकेटर के विकल्पों की खोज करने से परियोजनाओं के भीतर पासकी / WebAuthn प्रमाणीकरण प्रक्रियाओं का परीक्षण कैसे किया जाता है, इसमें लचीलापन मिल सकता है।

मॉक सेवाओं या एंडपॉइंट्स को विकसित करना प्रभावी रूप से प्रमाणीकरण व्यवहार का अनुकरण कर सकता है, वास्तविक प्रमाणीकरण तंत्र की पेचीदगियों को सारगर्भित करके परीक्षणों को सरल बना सकता है। यह दृष्टिकोण विशेष रूप से तब फायदेमंद होता है जब बाहरी प्रमाणीकरण सेवाओं का उपयोग किया जा रहा हो, जिससे प्रमाणीकरण की बारीकियों में जाने के बिना सिस्टम घटकों के एकीकरण और कार्यक्षमता पर ध्यान केंद्रित किया जा सके।

प्रमाणीकरण कार्यात्मकताओं की गहन जांच के लिए, एकीकरण परीक्षण के लिए वास्तविक ऑथेंटिकेटर का उपयोग करना हार्डवेयर सुरक्षा कुंजी (जैसे YubiKeys) या बायोमेट्रिक उपकरणों (जैसे फेस आईडी, टच आईडी या विंडोज हैलो में उपयोग किया जाता है) के साथ बातचीत में एक विस्तृत अंतर्दृष्टि प्रदान करता है। हालांकि आमतौर पर स्वचालित परीक्षणों में वास्तविक दुनिया के उपकरणों को एकीकृत करने की जटिल प्रकृति के कारण मैन्युअल रूप से आयोजित किया जाता है, कस्टम ऑटोमेशन स्क्रिप्ट विकसित करना संभव है। ये स्क्रिप्ट वास्तविक ऑथेंटिकेटर को एंड-टू-एंड परीक्षण ढांचे के साथ जोड़ सकती हैं, जो वास्तविक उपयोगकर्ता परिदृश्यों के करीब एक सन्निकटन प्रदान करती हैं और लाइव वातावरण में प्रमाणीकरण प्रक्रिया की विश्वसनीयता को बढ़ाती हैं।

विभिन्न विकल्पों को प्रदर्शित करने और प्लेराइट के साथ पासकी / WebAuthn के E2E परीक्षण के लिए विशिष्ट कोड स्निपेट दिखाने के बाद, हम अतिरिक्त रूप से इस विषय में नए डेवलपर्स के लिए कुछ और सामान्य सिफारिशें प्रदान करना चाहते हैं।

पासकीज़ या किसी अन्य प्रमाणीकरण तंत्र का परीक्षण करने में गोता लगाने से पहले, उपलब्ध E2E परीक्षण ढांचे का आकलन करना और अपनी परियोजना की आवश्यकताओं के अनुसार सबसे उपयुक्त विकल्प चुनना आवश्यक है। प्लेराइट और पपेटियर जैसे CDP-आधारित ढांचे द्वारा दी जाने वाली गति और स्थिरता, और सेलेनियम और नाइटवॉच जैसे WebDriver-आधारित ढांचे द्वारा प्रदान की गई क्रॉस-ब्राउज़र संगतता के बीच के ट्रेडऑफ पर विचार करें। जबकि CDP-आधारित ढांचे तेज़ और अधिक स्थिर ब्राउज़र ऑटोमेशन प्रदान करते हैं, वे क्रोमियम-आधारित ब्राउज़रों तक सीमित हैं। इसके विपरीत, WebDriver-आधारित ढांचे व्यापक क्रॉस-ब्राउज़र संगतता प्रदान करते हैं, जिसमें फ़ायरफ़ॉक्स और सफारी जैसे गैर-क्रोमियम ब्राउज़रों के लिए समर्थन शामिल है, यद्यपि संभावित रूप से धीमे और कम स्थिर प्रदर्शन के साथ। इन ट्रेडऑफ को समझने से आपको एक सूचित निर्णय लेने और उस ढांचे का चयन करने में मदद मिलेगी जो आपकी परियोजना की जरूरतों के लिए सबसे उपयुक्त है।

जबकि WebAuthn वर्चुअल ऑथेंटिकेटर पासकी कार्यान्वयन के परीक्षण की प्रक्रिया को सरल बनाता है, डेवलपर्स के लिए WebAuthn मानक और पासकीज़ के पीछे की अंतर्निहित अवधारणाओं की ठोस समझ होना महत्वपूर्ण है। WebAuthn वर्चुअल ऑथेंटिकेटर के लिए उपलब्ध विभिन्न कॉन्फ़िगरेशन से खुद को परिचित करें, जैसे कि प्रोटोकॉल, ट्रांसपोर्ट, हैज़रेसिडेंटकी, हैज़यूज़रवेरिफिकेशन, और इज़यूज़रवेरिफाइड। इन कॉन्फ़िगरेशन को समझने से आप विभिन्न प्रमाणीकरण परिदृश्यों का सटीक अनुकरण करने के लिए वर्चुअल ऑथेंटिकेटर को ठीक-ठीक करने में सक्षम होंगे। इसके अतिरिक्त, पासकी प्रमाणीकरण की पेचीदगियों में तल्लीन हों, जिसमें विभिन्न ब्राउज़रों और उपकरणों के साथ इसका एकीकरण, साथ ही संभावित सुरक्षा विचार शामिल हैं। यह मूलभूत ज्ञान आपको अपने वेब अनुप्रयोगों में पासकी प्रमाणीकरण के लिए व्यापक और प्रभावी परीक्षण रणनीतियों को डिजाइन करने के लिए सशक्त करेगा।

इस गाइड ने प्लेराइट के साथ CDP WebAuthn वर्चुअल ऑथेंटिकेटर का उपयोग करने में गहराई से जानकारी दी, उन्नत अवधारणाओं पर प्रकाश डाला और आधिकारिक दस्तावेज़ीकरण में शामिल नहीं किए गए मुद्दों को संबोधित किया। हमने प्लेराइट और अन्य E2E परीक्षण ढांचे के भीतर CDP के विकल्पों का भी पता लगाया। विभिन्न कार्यान्वयनों के बावजूद, मानकीकृत WebAuthn वर्चुअल ऑथेंटिकेटर विनिर्देश विभिन्न वेब ऑटोमेशन प्रोटोकॉल और एंड-टू-एंड परीक्षण ढांचे में इस गाइड की प्रासंगिकता सुनिश्चित करते हैं। पासकीज़ के बारे में विभिन्न अवधारणाओं के बारे में गहराई से जानने के लिए, प्रासंगिक शब्दावली की हमारी शब्दावली का संदर्भ लें जो आपकी आवश्यकताओं के आधार पर WebAuthn वर्चुअल ऑथेंटिकेटर को ठीक करने में आपकी मदद कर सकती है।