چگونه تب Chrome DevTools WebAuthn را ساختیم

Fawaz Mohammad

Nina Satragno

Web Authentication API که به عنوان WebAuthn نیز شناخته می شود، به سرورها اجازه می دهد تا از رمزنگاری کلید عمومی - به جای رمز عبور - برای ثبت نام و احراز هویت کاربران استفاده کنند. این کار را با فعال کردن ادغام بین این سرورها و احراز هویت قوی انجام می دهد. این احراز هویت‌ها ممکن است دستگاه‌های فیزیکی اختصاصی (مانند کلیدهای امنیتی) یا ادغام شده با پلتفرم‌ها (مثلاً خوانندگان اثر انگشت) باشند. می توانید اطلاعات بیشتری درباره WebAuthn در اینجا در webauthn.guide بخوانید.

نقاط درد توسعه دهنده

قبل از این پروژه، WebAuthn فاقد پشتیبانی اشکال زدایی بومی در کروم بود. توسعه‌دهنده‌ای که اپلیکیشنی را می‌سازد که از WebAuth استفاده می‌کند، نیاز به دسترسی به احراز هویت فیزیکی دارد. این امر به ویژه به دو دلیل دشوار بود:

1. انواع مختلفی از احراز هویت وجود دارد. اشکال زدایی وسعت پیکربندی ها و قابلیت ها مستلزم دسترسی توسعه دهنده به بسیاری از احراز هویت های مختلف و گاهی گران قیمت است.

2. احراز هویت فیزیکی، بنا به طراحی، ایمن هستند. بنابراین، بازرسی وضعیت آنها معمولا غیرممکن است.

ما می‌خواستیم با افزودن پشتیبانی از اشکال‌زدایی درست در ابزار توسعه کروم، این کار را آسان‌تر کنیم.

راه حل: یک برگه WebAuthn جدید

تب WebAuthn DevTools با اجازه دادن به توسعه دهندگان برای تقلید از این احراز هویت، سفارشی کردن قابلیت های آنها و بازرسی وضعیت آنها، اشکال زدایی WebAuthn را بسیار آسان می کند.

پیاده سازی

افزودن پشتیبانی از اشکال زدایی به WebAuthn یک فرآیند دو قسمتی بود.

بخش 1: افزودن دامنه WebAuthn به پروتکل Chrome DevTools

ابتدا، یک دامنه جدید در پروتکل Chrome DevTools (CDP) پیاده‌سازی کردیم که به کنترل‌کننده‌ای متصل می‌شود که با Backend WebAuthn ارتباط برقرار می‌کند.

CDP DevTools Front-end را به Chromium متصل می کند. در مورد ما، ما از اعمال دامنه WebAuthn برای ایجاد پل بین تب WebAuthn DevTools و اجرای Chromium از WebAuthn استفاده کردیم.

دامنه WebAuthn امکان فعال و غیرفعال کردن Virtual Authenticator Environment را می دهد، که مرورگر را از Authenticator Discovery واقعی جدا می کند و به جای آن یک Virtual Discovery را وصل می کند.

همچنین روش‌هایی را در دامنه که به‌عنوان یک لایه نازک عمل می‌کنند در معرض واسط‌های Virtual Authenticator و Virtual Discovery موجود قرار می‌دهیم که بخشی از اجرای WebAuthn Chromium هستند. این روش ها شامل افزودن و حذف احراز هویت و همچنین ایجاد، دریافت و پاک کردن اعتبار ثبت شده آنها است.

( کد را بخوانید)

بخش 2: ساخت برگه رو به روی کاربر

دوم، ما یک برگه رو به کاربر در DevTools frontend ایجاد کردیم. برگه از یک نما و یک مدل تشکیل شده است. یک عامل تولید خودکار دامنه را با برگه متصل می کند.

در حالی که 3 جزء ضروری مورد نیاز است، ما فقط باید نگران دو مورد از آنها باشیم: مدل و نمای . جزء سوم - عامل ، پس از افزودن دامنه به طور خودکار تولید می شود. به طور خلاصه، Agent لایه ای است که تماس ها را بین front end و CDP انجام می دهد.

مدل

مدل لایه جاوا اسکریپت است که عامل و view را به هم متصل می کند. برای مورد ما، مدل بسیار ساده است. دستورات را از نما می گیرد، درخواست ها را طوری می سازد که توسط CDP قابل مصرف باشند و سپس آنها را از طریق عامل ارسال می کند. این درخواست ها معمولاً یک طرفه هستند و هیچ اطلاعاتی به نمایش ارسال نمی شود.

با این حال، گاهی اوقات پاسخی را از مدل پس می‌دهیم تا یک شناسه برای احراز هویت جدید ایجاد شده ارائه کنیم یا اعتبار ذخیره‌شده در یک احراز هویت موجود را برگردانیم.

( کد را بخوانید)

نمای

ما از view برای ارائه رابط کاربری استفاده می کنیم که یک توسعه دهنده می تواند هنگام دسترسی به DevTools پیدا کند. شامل:

1. نوار ابزار برای فعال کردن محیط احراز هویت مجازی.
2. بخشی برای افزودن احراز هویت.
3. بخشی برای احراز هویت ایجاد شده.

( کد را بخوانید)

نوار ابزار برای فعال کردن محیط احراز هویت مجازی

از آنجایی که بیشتر تعاملات کاربر به جای کل برگه با یک تأیید کننده در یک زمان انجام می شود، تنها عملکردی که در نوار ابزار ارائه می دهیم روشن و خاموش کردن محیط مجازی است.

چرا این لازم است؟ مهم است که کاربر باید به صراحت محیط را تغییر دهد زیرا انجام این کار باعث قطع ارتباط مرورگر با Authenticator Discovery واقعی می شود. بنابراین، در حالی که روشن است، احراز هویت فیزیکی متصل مانند یک خواننده اثر انگشت شناسایی نخواهند شد.

ما تصمیم گرفتیم که تغییر واضح به معنای تجربه کاربری بهتر است، به خصوص برای کسانی که در برگه WebAuthn سرگردان هستند بدون اینکه انتظار داشته باشند کشف واقعی غیرفعال شود.

افزودن بخش Authenticators

پس از فعال کردن محیط احراز هویت مجازی، یک فرم درون خطی به توسعه‌دهنده ارائه می‌دهیم که به آنها اجازه می‌دهد یک احراز هویت مجازی اضافه کنند. در این فرم، گزینه‌های سفارشی‌سازی را ارائه می‌کنیم که به کاربر اجازه می‌دهد پروتکل و روش‌های انتقال احراز هویت، و همچنین اینکه آیا احراز هویت از کلیدهای مقیم و تأیید کاربر پشتیبانی می‌کند، تصمیم بگیرد.

هنگامی که کاربر روی Add کلیک می کند، این گزینه ها دسته بندی می شوند و به مدلی ارسال می شوند که برای ایجاد یک احراز هویت تماس برقرار می کند. پس از تکمیل، بخش جلویی پاسخی دریافت می‌کند و سپس UI را طوری تغییر می‌دهد که احراز هویت جدید ایجاد شده را شامل شود.

نمای Authenticator

هر بار که یک authenticator شبیه سازی می شود، بخشی را به نمای authenticator اضافه می کنیم تا آن را نشان دهد. هر بخش احراز هویت شامل یک نام، شناسه، گزینه‌های پیکربندی، دکمه‌هایی برای حذف احراز هویت یا تنظیم آن فعال و یک جدول اعتبار است.

نام Authenticator

نام Authenticator قابل تنظیم است و پیش‌فرض روی "Authenticator" است که با 5 نویسه آخر شناسه آن ترکیب شده است. در اصل، نام احراز هویت شناسه کامل آن بود و غیرقابل تغییر بود. ما نام‌های قابل تنظیم را پیاده‌سازی کردیم تا کاربر بتواند احراز هویت را بر اساس قابلیت‌های آن، احراز هویت فیزیکی که قرار است شبیه‌سازی کند، یا هر نام مستعاری که هضم آن کمی آسان‌تر از شناسه ۳۶ کاراکتری است، برچسب‌گذاری کند.

جدول اعتبار

ما یک جدول به هر بخش احراز هویت اضافه کردیم که تمام اعتبارنامه های ثبت شده توسط یک احراز هویت را نشان می دهد. در هر ردیف، اطلاعاتی درباره یک اعتبارنامه و همچنین دکمه‌هایی برای حذف یا صادر کردن اعتبار ارائه می‌کنیم.

در حال حاضر، ما اطلاعات را برای پر کردن این جداول با نظرسنجی از CDP جمع‌آوری می‌کنیم تا اعتبار ثبت‌شده برای هر احراز هویت را دریافت کنیم. در آینده، ما قصد داریم یک رویداد برای ایجاد اعتبار اضافه کنیم.

دکمه Active

ما همچنین یک دکمه رادیویی فعال به هر بخش احراز هویت اضافه کردیم. احراز هویتی که در حال حاضر فعال است، تنها کسی است که به اعتبارنامه ها گوش می دهد و آن را ثبت می کند. بدون این، ثبت اعتبارنامه‌هایی که چندین احراز هویت داده می‌شوند، غیر قطعی است که هنگام تلاش برای آزمایش WebAuthn با استفاده از آنها، یک نقص مهلک خواهد بود.

ما وضعیت فعال را با استفاده از روش SetUserPresence روی احراز هویت مجازی پیاده سازی کردیم. روش SetUserPresence تعیین می‌کند که آیا آزمایش‌های حضور کاربر برای یک احراز هویت معین موفق هستند یا خیر. اگر آن را خاموش کنیم، یک احراز هویت نمی‌تواند به اعتبارنامه‌ها گوش دهد. بنابراین، با اطمینان از روشن بودن آن حداکثر برای یک احراز هویت (یکی که به عنوان فعال تنظیم شده است)، و غیرفعال کردن حضور کاربر برای بقیه، می‌توانیم رفتار قطعی را مجبور کنیم.

چالش جالبی که هنگام اضافه کردن دکمه فعال با آن مواجه شدیم، اجتناب از شرایط مسابقه بود. سناریوی زیر را در نظر بگیرید:

1. کاربر روی دکمه رادیویی فعال برای Authenticator X کلیک می‌کند و درخواستی را برای تنظیم X به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی Active برای X انتخاب شده است و سایر موارد از حالت انتخاب خارج می شوند.

2. بلافاصله پس از آن، کاربر روی دکمه رادیویی فعال برای Authenticator Y کلیک می‌کند و درخواستی را برای تنظیم Y به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی فعال برای Y انتخاب شده است، و بقیه، از جمله برای X، از حالت انتخاب خارج می شوند.

3. در باطن، فراخوانی برای تنظیم Y به عنوان فعال تکمیل و حل می شود. Y اکنون فعال است و همه احراز هویت‌کنندگان دیگر فعال نیستند.

4. در باطن، تماس برای تنظیم X به عنوان فعال تکمیل و حل می شود. X اکنون فعال است و سایر احراز هویت، از جمله Y، فعال نیستند.

حال، وضعیت حاصل به شرح زیر است: X احراز هویت فعال است . با این حال، دکمه رادیویی فعال برای X انتخاب نشده است . Y احراز هویت فعال نیست . با این حال، دکمه رادیویی فعال برای Y انتخاب شده است . بین قسمت جلویی و وضعیت واقعی احراز هویت‌کنندگان اختلاف نظر وجود دارد. بدیهی است که این یک مشکل است.

راه حل ما: برقراری ارتباط شبه دو طرفه بین دکمه های رادیویی و احراز هویت فعال. ابتدا، ما یک متغیر activeId در نمای نگه می داریم تا شناسه احراز هویت فعال فعلی را پیگیری کنیم. سپس، منتظر می‌شویم تا تماس، یک Authenticator فعال را تنظیم کند تا برگردد، سپس activeId به شناسه آن authenticator تنظیم کنید. در نهایت، ما از طریق هر بخش authenticator حلقه می زنیم. اگر شناسه آن بخش برابر با activeId باشد، دکمه را انتخاب می کنیم. در غیر این صورت، دکمه را در حالت انتخاب نشده قرار می دهیم.

در اینجا به نظر می رسد:

 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

معیارهای استفاده

ما می خواستیم استفاده از این ویژگی را ردیابی کنیم. در ابتدا با دو گزینه روبرو شدیم.

1. هر بار که برگه WebAuthn در DevTools باز شد، بشمارید . این گزینه به طور بالقوه می تواند منجر به شمارش بیش از حد شود، زیرا ممکن است شخصی بدون استفاده از آن برگه را باز کند.

2. ردیابی تعداد دفعاتی که کادر انتخاب "فعال کردن محیط احراز هویت مجازی" در نوار ابزار تغییر کرده است . این گزینه همچنین یک مشکل بالقوه شمارش بیش از حد داشت زیرا ممکن است برخی از آنها در یک جلسه چندین بار محیط را روشن و خاموش کنند.

در نهایت، ما تصمیم گرفتیم با دومی پیش برویم، اما با بررسی اینکه آیا محیط قبلاً در جلسه فعال شده است، شمارش را محدود کنیم . بنابراین، صرف نظر از اینکه توسعه‌دهنده چند بار محیط را تغییر داده است، فقط تعداد را 1 افزایش می‌دهیم. این کار به این دلیل کار می‌کند که هر بار که برگه باز می‌شود، یک جلسه جدید ایجاد می‌شود، بنابراین بررسی مجدد تنظیم می‌شود و امکان افزایش مجدد متریک وجود دارد.

خلاصه

با تشکر از شما برای خواندن! اگر پیشنهادی برای بهبود برگه WebAuthn دارید، با ثبت یک اشکال به ما اطلاع دهید.

اگر مایلید در مورد WebAuthn بیشتر بیاموزید، در اینجا چند منبع آورده شده است:

• سند طراحی جلویی WebAuthn DevTools
• سند طراحی API آزمایش احراز هویت وب
• مشخصات Web Authentication API (WebAuthn).
• توضیح و راهنمای WebAuthn

کانال های پیش نمایش را دانلود کنید

استفاده از Chrome Canary ، Dev یا Beta را به عنوان مرورگر توسعه پیش‌فرض خود در نظر بگیرید. این کانال‌های پیش‌نمایش به شما امکان دسترسی به جدیدترین ویژگی‌های DevTools را می‌دهند، به شما اجازه می‌دهند APIهای پلتفرم وب پیشرفته را آزمایش کنید و به شما کمک می‌کنند تا قبل از کاربران، مشکلات سایت خود را پیدا کنید!

با تیم Chrome DevTools در تماس باشید

از گزینه‌های زیر برای بحث در مورد ویژگی‌های جدید، به‌روزرسانی‌ها یا هر چیز دیگری مربوط به DevTools استفاده کنید.

• بازخورد و درخواست های ویژگی را برای ما در crbug.com ارسال کنید.
• یک مشکل DevTools را با استفاده از more_vert گزینه های بیشتر > راهنما > گزارش مشکل DevTools در DevTools گزارش کنید.
• توییت در @ChromeDevTools .
• نظرات خود را در مورد موارد جدید در ویدیوهای DevTools YouTube یا DevTools Tips ویدیوهای YouTube بگذارید.

Fawaz Mohammad

Nina Satragno

Web Authentication API که به عنوان WebAuthn نیز شناخته می شود، به سرورها اجازه می دهد تا از رمزنگاری کلید عمومی - به جای رمز عبور - برای ثبت نام و احراز هویت کاربران استفاده کنند. این کار را با فعال کردن ادغام بین این سرورها و احراز هویت قوی انجام می دهد. این احراز هویت‌ها ممکن است دستگاه‌های فیزیکی اختصاصی (مانند کلیدهای امنیتی) یا ادغام شده با پلتفرم‌ها (مثلاً خوانندگان اثر انگشت) باشند. می توانید اطلاعات بیشتری درباره WebAuthn در اینجا در webauthn.guide بخوانید.

نقاط درد توسعه دهنده

قبل از این پروژه، WebAuthn فاقد پشتیبانی اشکال زدایی بومی در کروم بود. توسعه‌دهنده‌ای که اپلیکیشنی را می‌سازد که از WebAuth استفاده می‌کند، نیاز به دسترسی به احراز هویت فیزیکی دارد. این امر به ویژه به دو دلیل دشوار بود:

1. انواع مختلفی از احراز هویت وجود دارد. اشکال زدایی وسعت پیکربندی ها و قابلیت ها مستلزم دسترسی توسعه دهنده به بسیاری از احراز هویت های مختلف و گاهی گران قیمت است.

2. احراز هویت فیزیکی، بنا به طراحی، ایمن هستند. بنابراین، بازرسی وضعیت آنها معمولا غیرممکن است.

ما می‌خواستیم با افزودن پشتیبانی از اشکال‌زدایی درست در ابزار توسعه کروم، این کار را آسان‌تر کنیم.

راه حل: یک برگه WebAuthn جدید

تب WebAuthn DevTools با اجازه دادن به توسعه دهندگان برای تقلید از این احراز هویت، سفارشی کردن قابلیت های آنها و بازرسی وضعیت آنها، اشکال زدایی WebAuthn را بسیار آسان می کند.

پیاده سازی

افزودن پشتیبانی از اشکال زدایی به WebAuthn یک فرآیند دو قسمتی بود.

بخش 1: افزودن دامنه WebAuthn به پروتکل Chrome DevTools

ابتدا، یک دامنه جدید در پروتکل Chrome DevTools (CDP) پیاده‌سازی کردیم که به کنترل‌کننده‌ای متصل می‌شود که با Backend WebAuthn ارتباط برقرار می‌کند.

CDP DevTools Front-end را به Chromium متصل می کند. در مورد ما، ما از اعمال دامنه WebAuthn برای ایجاد پل بین تب WebAuthn DevTools و اجرای Chromium از WebAuthn استفاده کردیم.

دامنه WebAuthn امکان فعال و غیرفعال کردن Virtual Authenticator Environment را می دهد، که مرورگر را از Authenticator Discovery واقعی جدا می کند و به جای آن یک Virtual Discovery را وصل می کند.

همچنین روش‌هایی را در دامنه که به‌عنوان یک لایه نازک عمل می‌کنند در معرض واسط‌های Virtual Authenticator و Virtual Discovery موجود قرار می‌دهیم که بخشی از اجرای WebAuthn Chromium هستند. این روش ها شامل افزودن و حذف احراز هویت و همچنین ایجاد، دریافت و پاک کردن اعتبار ثبت شده آنها است.

( کد را بخوانید)

بخش 2: ساخت برگه رو به روی کاربر

دوم، ما یک برگه رو به کاربر در DevTools frontend ایجاد کردیم. برگه از یک نما و یک مدل تشکیل شده است. یک عامل تولید خودکار دامنه را با برگه متصل می کند.

در حالی که 3 جزء ضروری مورد نیاز است، ما فقط باید نگران دو مورد از آنها باشیم: مدل و نمای . جزء سوم - عامل ، پس از افزودن دامنه به طور خودکار تولید می شود. به طور خلاصه، Agent لایه ای است که تماس ها را بین front end و CDP انجام می دهد.

مدل

مدل لایه جاوا اسکریپت است که عامل و view را به هم متصل می کند. برای مورد ما، مدل بسیار ساده است. دستورات را از نما می گیرد، درخواست ها را طوری می سازد که توسط CDP قابل مصرف باشند و سپس آنها را از طریق عامل ارسال می کند. این درخواست ها معمولاً یک طرفه هستند و هیچ اطلاعاتی به نمایش ارسال نمی شود.

با این حال، گاهی اوقات پاسخی را از مدل پس می‌دهیم تا یک شناسه برای احراز هویت جدید ایجاد شده ارائه کنیم یا اعتبار ذخیره‌شده در یک احراز هویت موجود را برگردانیم.

( کد را بخوانید)

نمای

ما از view برای ارائه رابط کاربری استفاده می کنیم که یک توسعه دهنده می تواند هنگام دسترسی به DevTools پیدا کند. شامل:

1. نوار ابزار برای فعال کردن محیط احراز هویت مجازی.
2. بخشی برای افزودن احراز هویت.
3. بخشی برای احراز هویت ایجاد شده.

( کد را بخوانید)

نوار ابزار برای فعال کردن محیط احراز هویت مجازی

از آنجایی که بیشتر تعاملات کاربر به جای کل برگه با یک تأیید کننده در یک زمان انجام می شود، تنها عملکردی که در نوار ابزار ارائه می دهیم روشن و خاموش کردن محیط مجازی است.

چرا این لازم است؟ مهم است که کاربر باید به صراحت محیط را تغییر دهد زیرا انجام این کار باعث قطع ارتباط مرورگر با Authenticator Discovery واقعی می شود. بنابراین، در حالی که روشن است، احراز هویت فیزیکی متصل مانند یک خواننده اثر انگشت شناسایی نخواهند شد.

ما تصمیم گرفتیم که تغییر واضح به معنای تجربه کاربری بهتر است، به خصوص برای کسانی که در برگه WebAuthn سرگردان هستند بدون اینکه انتظار داشته باشند کشف واقعی غیرفعال شود.

افزودن بخش Authenticators

پس از فعال کردن محیط احراز هویت مجازی، یک فرم درون خطی به توسعه‌دهنده ارائه می‌دهیم که به آنها اجازه می‌دهد یک احراز هویت مجازی اضافه کنند. در این فرم، گزینه‌های سفارشی‌سازی را ارائه می‌کنیم که به کاربر اجازه می‌دهد پروتکل و روش‌های انتقال احراز هویت، و همچنین اینکه آیا احراز هویت از کلیدهای مقیم و تأیید کاربر پشتیبانی می‌کند، تصمیم بگیرد.

هنگامی که کاربر روی Add کلیک می کند، این گزینه ها دسته بندی می شوند و به مدلی ارسال می شوند که برای ایجاد یک احراز هویت تماس برقرار می کند. پس از تکمیل، بخش جلویی پاسخی دریافت می‌کند و سپس UI را طوری تغییر می‌دهد که احراز هویت جدید ایجاد شده را شامل شود.

نمای Authenticator

هر بار که یک authenticator شبیه سازی می شود، بخشی را به نمای authenticator اضافه می کنیم تا آن را نشان دهد. هر بخش احراز هویت شامل یک نام، شناسه، گزینه‌های پیکربندی، دکمه‌هایی برای حذف احراز هویت یا تنظیم آن فعال و یک جدول اعتبار است.

نام Authenticator

نام Authenticator قابل تنظیم است و پیش‌فرض روی "Authenticator" است که با 5 نویسه آخر شناسه آن ترکیب شده است. در اصل، نام احراز هویت شناسه کامل آن بود و غیرقابل تغییر بود. ما نام‌های قابل تنظیم را پیاده‌سازی کردیم تا کاربر بتواند احراز هویت را بر اساس قابلیت‌های آن، احراز هویت فیزیکی که قرار است شبیه‌سازی کند، یا هر نام مستعاری که هضم آن کمی آسان‌تر از شناسه ۳۶ کاراکتری است، برچسب‌گذاری کند.

جدول اعتبار

ما یک جدول به هر بخش احراز هویت اضافه کردیم که تمام اعتبارنامه های ثبت شده توسط یک احراز هویت را نشان می دهد. در هر ردیف، اطلاعاتی درباره یک اعتبارنامه و همچنین دکمه‌هایی برای حذف یا صادر کردن اعتبار ارائه می‌کنیم.

در حال حاضر، ما اطلاعات را برای پر کردن این جداول با نظرسنجی از CDP جمع‌آوری می‌کنیم تا اعتبار ثبت‌شده برای هر احراز هویت را دریافت کنیم. در آینده، ما قصد داریم یک رویداد برای ایجاد اعتبار اضافه کنیم.

دکمه Active

ما همچنین یک دکمه رادیویی فعال به هر بخش احراز هویت اضافه کردیم. احراز هویتی که در حال حاضر فعال است، تنها کسی است که به اعتبارنامه ها گوش می دهد و آن را ثبت می کند. بدون این، ثبت اعتبارنامه‌هایی که چندین احراز هویت داده می‌شوند، غیر قطعی است که هنگام تلاش برای آزمایش WebAuthn با استفاده از آنها، یک نقص مهلک خواهد بود.

ما وضعیت فعال را با استفاده از روش SetUserPresence روی احراز هویت مجازی پیاده سازی کردیم. روش SetUserPresence تعیین می‌کند که آیا آزمایش‌های حضور کاربر برای یک احراز هویت معین موفق هستند یا خیر. اگر آن را خاموش کنیم، یک احراز هویت نمی‌تواند به اعتبارنامه‌ها گوش دهد. بنابراین، با اطمینان از روشن بودن آن حداکثر برای یک احراز هویت (یکی که به عنوان فعال تنظیم شده است)، و غیرفعال کردن حضور کاربر برای بقیه، می‌توانیم رفتار قطعی را مجبور کنیم.

چالش جالبی که هنگام اضافه کردن دکمه فعال با آن مواجه شدیم، اجتناب از شرایط مسابقه بود. سناریوی زیر را در نظر بگیرید:

1. کاربر روی دکمه رادیویی فعال برای Authenticator X کلیک می‌کند و درخواستی را برای تنظیم X به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی Active برای X انتخاب شده است و سایر موارد از حالت انتخاب خارج می شوند.

2. بلافاصله پس از آن، کاربر روی دکمه رادیویی فعال برای Authenticator Y کلیک می‌کند و درخواستی را برای تنظیم Y به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی فعال برای Y انتخاب شده است، و بقیه، از جمله برای X، از حالت انتخاب خارج می شوند.

3. در باطن، فراخوانی برای تنظیم Y به عنوان فعال تکمیل و حل می شود. Y اکنون فعال است و همه احراز هویت‌کنندگان دیگر فعال نیستند.

4. در باطن، تماس برای تنظیم X به عنوان فعال تکمیل و حل می شود. X اکنون فعال است و سایر احراز هویت، از جمله Y، فعال نیستند.

حال، وضعیت حاصل به شرح زیر است: X احراز هویت فعال است . با این حال، دکمه رادیویی فعال برای X انتخاب نشده است . Y احراز هویت فعال نیست . با این حال، دکمه رادیویی فعال برای Y انتخاب شده است . بین قسمت جلویی و وضعیت واقعی احراز هویت‌کنندگان اختلاف نظر وجود دارد. بدیهی است که این یک مشکل است.

راه حل ما: برقراری ارتباط شبه دو طرفه بین دکمه های رادیویی و احراز هویت فعال. ابتدا، ما یک متغیر activeId در نمای نگه می داریم تا شناسه احراز هویت فعال فعلی را پیگیری کنیم. سپس، منتظر می‌شویم تا تماس، یک Authenticator فعال را تنظیم کند تا برگردد، سپس activeId به شناسه آن authenticator تنظیم کنید. در نهایت، ما از طریق هر بخش authenticator حلقه می زنیم. اگر شناسه آن بخش برابر با activeId باشد، دکمه را انتخاب می کنیم. در غیر این صورت، دکمه را در حالت انتخاب نشده قرار می دهیم.

در اینجا به نظر می رسد:

 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

معیارهای استفاده

ما می خواستیم استفاده از این ویژگی را ردیابی کنیم. در ابتدا با دو گزینه روبرو شدیم.

1. هر بار که برگه WebAuthn در DevTools باز شد، بشمارید . این گزینه به طور بالقوه می تواند منجر به شمارش بیش از حد شود، زیرا ممکن است شخصی بدون استفاده از آن برگه را باز کند.

2. ردیابی تعداد دفعاتی که کادر انتخاب "فعال کردن محیط احراز هویت مجازی" در نوار ابزار تغییر کرده است . این گزینه همچنین یک مشکل بالقوه شمارش بیش از حد داشت زیرا ممکن است برخی از آنها در یک جلسه چندین بار محیط را روشن و خاموش کنند.

در نهایت، ما تصمیم گرفتیم با دومی پیش برویم، اما با بررسی اینکه آیا محیط قبلاً در جلسه فعال شده است، شمارش را محدود کنیم . بنابراین، صرف نظر از اینکه توسعه‌دهنده چند بار محیط را تغییر داده است، فقط تعداد را 1 افزایش می‌دهیم. این کار به این دلیل کار می‌کند که هر بار که برگه باز می‌شود، یک جلسه جدید ایجاد می‌شود، بنابراین بررسی مجدد تنظیم می‌شود و امکان افزایش مجدد متریک وجود دارد.

خلاصه

با تشکر از شما برای خواندن! اگر پیشنهادی برای بهبود برگه WebAuthn دارید، با ثبت یک اشکال به ما اطلاع دهید.

اگر مایلید در مورد WebAuthn بیشتر بیاموزید، در اینجا چند منبع آورده شده است:

• سند طراحی جلویی WebAuthn DevTools
• سند طراحی API آزمایش احراز هویت وب
• مشخصات Web Authentication API (WebAuthn).
• توضیح و راهنمای WebAuthn

کانال های پیش نمایش را دانلود کنید

استفاده از Chrome Canary ، Dev یا Beta را به عنوان مرورگر توسعه پیش‌فرض خود در نظر بگیرید. این کانال‌های پیش‌نمایش به شما امکان دسترسی به جدیدترین ویژگی‌های DevTools را می‌دهند، به شما اجازه می‌دهند APIهای پلتفرم وب پیشرفته را آزمایش کنید و به شما کمک می‌کنند تا قبل از کاربران، مشکلات سایت خود را پیدا کنید!

با تیم Chrome DevTools در تماس باشید

از گزینه‌های زیر برای بحث در مورد ویژگی‌های جدید، به‌روزرسانی‌ها یا هر چیز دیگری مربوط به DevTools استفاده کنید.

• بازخورد و درخواست های ویژگی را برای ما در crbug.com ارسال کنید.
• یک مشکل DevTools را با استفاده از more_vert گزینه های بیشتر > راهنما > گزارش مشکل DevTools در DevTools گزارش کنید.
• توییت در @ChromeDevTools .
• نظرات خود را در مورد موارد جدید در ویدیوهای DevTools YouTube یا DevTools Tips ویدیوهای YouTube بگذارید.

Fawaz Mohammad

Nina Satragno

Web Authentication API که به عنوان WebAuthn نیز شناخته می شود، به سرورها اجازه می دهد تا از رمزنگاری کلید عمومی - به جای رمز عبور - برای ثبت نام و احراز هویت کاربران استفاده کنند. این کار را با فعال کردن ادغام بین این سرورها و احراز هویت قوی انجام می دهد. این احراز هویت‌ها ممکن است دستگاه‌های فیزیکی اختصاصی (مانند کلیدهای امنیتی) یا ادغام شده با پلتفرم‌ها (مثلاً خوانندگان اثر انگشت) باشند. می توانید اطلاعات بیشتری درباره WebAuthn در اینجا در webauthn.guide بخوانید.

نقاط درد توسعه دهنده

قبل از این پروژه، WebAuthn فاقد پشتیبانی اشکال زدایی بومی در کروم بود. توسعه‌دهنده‌ای که اپلیکیشنی را می‌سازد که از WebAuth استفاده می‌کند، نیاز به دسترسی به احراز هویت فیزیکی دارد. این امر به ویژه به دو دلیل دشوار بود:

1. انواع مختلفی از احراز هویت وجود دارد. اشکال زدایی وسعت پیکربندی ها و قابلیت ها مستلزم دسترسی توسعه دهنده به بسیاری از احراز هویت های مختلف و گاهی گران قیمت است.

2. احراز هویت فیزیکی، بنا به طراحی، ایمن هستند. بنابراین، بازرسی وضعیت آنها معمولا غیرممکن است.

ما می‌خواستیم با افزودن پشتیبانی از اشکال‌زدایی درست در ابزار توسعه کروم، این کار را آسان‌تر کنیم.

راه حل: یک برگه WebAuthn جدید

تب WebAuthn DevTools با اجازه دادن به توسعه دهندگان برای تقلید از این احراز هویت، سفارشی کردن قابلیت های آنها و بازرسی وضعیت آنها، اشکال زدایی WebAuthn را بسیار آسان می کند.

پیاده سازی

افزودن پشتیبانی از اشکال زدایی به WebAuthn یک فرآیند دو قسمتی بود.

بخش 1: افزودن دامنه WebAuthn به پروتکل Chrome DevTools

ابتدا، یک دامنه جدید در پروتکل Chrome DevTools (CDP) پیاده‌سازی کردیم که به کنترل‌کننده‌ای متصل می‌شود که با Backend WebAuthn ارتباط برقرار می‌کند.

CDP DevTools Front-end را به Chromium متصل می کند. در مورد ما، ما از اعمال دامنه WebAuthn برای ایجاد پل بین تب WebAuthn DevTools و اجرای Chromium از WebAuthn استفاده کردیم.

دامنه WebAuthn امکان فعال و غیرفعال کردن Virtual Authenticator Environment را می دهد، که مرورگر را از Authenticator Discovery واقعی جدا می کند و به جای آن یک Virtual Discovery را وصل می کند.

همچنین روش‌هایی را در دامنه که به‌عنوان یک لایه نازک عمل می‌کنند در معرض واسط‌های Virtual Authenticator و Virtual Discovery موجود قرار می‌دهیم که بخشی از اجرای WebAuthn Chromium هستند. این روش ها شامل افزودن و حذف احراز هویت و همچنین ایجاد، دریافت و پاک کردن اعتبار ثبت شده آنها است.

( کد را بخوانید)

بخش 2: ساخت برگه رو به روی کاربر

دوم، ما یک برگه رو به کاربر در DevTools frontend ایجاد کردیم. برگه از یک نما و یک مدل تشکیل شده است. یک عامل تولید خودکار دامنه را با برگه متصل می کند.

در حالی که 3 جزء ضروری مورد نیاز است، ما فقط باید نگران دو مورد از آنها باشیم: مدل و نمای . جزء سوم - عامل ، پس از افزودن دامنه به طور خودکار تولید می شود. به طور خلاصه، Agent لایه ای است که تماس ها را بین front end و CDP انجام می دهد.

مدل

مدل لایه جاوا اسکریپت است که عامل و view را به هم متصل می کند. برای مورد ما، مدل بسیار ساده است. دستورات را از نما می گیرد، درخواست ها را طوری می سازد که توسط CDP قابل مصرف باشند و سپس آنها را از طریق عامل ارسال می کند. این درخواست ها معمولاً یک طرفه هستند و هیچ اطلاعاتی به نمایش ارسال نمی شود.

با این حال، گاهی اوقات پاسخی را از مدل پس می‌دهیم تا یک شناسه برای احراز هویت جدید ایجاد شده ارائه کنیم یا اعتبار ذخیره‌شده در یک احراز هویت موجود را برگردانیم.

( کد را بخوانید)

نمای

ما از view برای ارائه رابط کاربری استفاده می کنیم که یک توسعه دهنده می تواند هنگام دسترسی به DevTools پیدا کند. شامل:

1. نوار ابزار برای فعال کردن محیط احراز هویت مجازی.
2. بخشی برای افزودن احراز هویت.
3. بخشی برای احراز هویت ایجاد شده.

( کد را بخوانید)

نوار ابزار برای فعال کردن محیط احراز هویت مجازی

از آنجایی که بیشتر تعاملات کاربر به جای کل برگه با یک تأیید کننده در یک زمان انجام می شود، تنها عملکردی که در نوار ابزار ارائه می دهیم روشن و خاموش کردن محیط مجازی است.

چرا این لازم است؟ مهم است که کاربر باید به صراحت محیط را تغییر دهد زیرا انجام این کار باعث قطع ارتباط مرورگر با Authenticator Discovery واقعی می شود. بنابراین، در حالی که روشن است، احراز هویت فیزیکی متصل مانند یک خواننده اثر انگشت شناسایی نخواهند شد.

ما تصمیم گرفتیم که تغییر واضح به معنای تجربه کاربری بهتر است، به خصوص برای کسانی که در برگه WebAuthn سرگردان هستند بدون اینکه انتظار داشته باشند کشف واقعی غیرفعال شود.

افزودن بخش Authenticators

پس از فعال کردن محیط احراز هویت مجازی، یک فرم درون خطی به توسعه‌دهنده ارائه می‌دهیم که به آنها اجازه می‌دهد یک احراز هویت مجازی اضافه کنند. در این فرم، گزینه‌های سفارشی‌سازی را ارائه می‌کنیم که به کاربر اجازه می‌دهد پروتکل و روش‌های انتقال احراز هویت، و همچنین اینکه آیا احراز هویت از کلیدهای مقیم و تأیید کاربر پشتیبانی می‌کند، تصمیم بگیرد.

هنگامی که کاربر روی Add کلیک می کند، این گزینه ها دسته بندی می شوند و به مدلی ارسال می شوند که برای ایجاد یک احراز هویت تماس برقرار می کند. پس از تکمیل، بخش جلویی پاسخی دریافت می‌کند و سپس UI را طوری تغییر می‌دهد که احراز هویت جدید ایجاد شده را شامل شود.

نمای Authenticator

هر بار که یک authenticator شبیه سازی می شود، بخشی را به نمای authenticator اضافه می کنیم تا آن را نشان دهد. هر بخش احراز هویت شامل یک نام، شناسه، گزینه‌های پیکربندی، دکمه‌هایی برای حذف احراز هویت یا تنظیم آن فعال و یک جدول اعتبار است.

نام Authenticator

نام Authenticator قابل تنظیم است و پیش‌فرض روی "Authenticator" است که با 5 نویسه آخر شناسه آن ترکیب شده است. در اصل، نام احراز هویت شناسه کامل آن بود و غیرقابل تغییر بود. ما نام‌های قابل تنظیم را پیاده‌سازی کردیم تا کاربر بتواند احراز هویت را بر اساس قابلیت‌های آن، احراز هویت فیزیکی که قرار است شبیه‌سازی کند، یا هر نام مستعاری که هضم آن کمی آسان‌تر از شناسه ۳۶ کاراکتری است، برچسب‌گذاری کند.

جدول اعتبار

ما یک جدول به هر بخش احراز هویت اضافه کردیم که تمام اعتبارنامه های ثبت شده توسط یک احراز هویت را نشان می دهد. در هر ردیف، اطلاعاتی درباره یک اعتبارنامه و همچنین دکمه‌هایی برای حذف یا صادر کردن اعتبار ارائه می‌کنیم.

در حال حاضر، ما اطلاعات را برای پر کردن این جداول با نظرسنجی از CDP جمع‌آوری می‌کنیم تا اعتبار ثبت‌شده برای هر احراز هویت را دریافت کنیم. در آینده، ما قصد داریم یک رویداد برای ایجاد اعتبار اضافه کنیم.

دکمه Active

ما همچنین یک دکمه رادیویی فعال به هر بخش احراز هویت اضافه کردیم. احراز هویتی که در حال حاضر فعال است، تنها کسی است که به اعتبارنامه ها گوش می دهد و آن را ثبت می کند. بدون این، ثبت اعتبارنامه‌هایی که چندین احراز هویت داده می‌شوند، غیر قطعی است که هنگام تلاش برای آزمایش WebAuthn با استفاده از آنها، یک نقص مهلک خواهد بود.

ما وضعیت فعال را با استفاده از روش SetUserPresence روی احراز هویت مجازی پیاده سازی کردیم. روش SetUserPresence تعیین می‌کند که آیا آزمایش‌های حضور کاربر برای یک احراز هویت معین موفق هستند یا خیر. اگر آن را خاموش کنیم، یک احراز هویت نمی‌تواند به اعتبارنامه‌ها گوش دهد. بنابراین، با اطمینان از روشن بودن آن حداکثر برای یک احراز هویت (یکی که به عنوان فعال تنظیم شده است)، و غیرفعال کردن حضور کاربر برای بقیه، می‌توانیم رفتار قطعی را مجبور کنیم.

چالش جالبی که هنگام اضافه کردن دکمه فعال با آن مواجه شدیم، اجتناب از شرایط مسابقه بود. سناریوی زیر را در نظر بگیرید:

1. کاربر روی دکمه رادیویی فعال برای Authenticator X کلیک می‌کند و درخواستی را برای تنظیم X به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی Active برای X انتخاب شده است و سایر موارد از حالت انتخاب خارج می شوند.

2. بلافاصله پس از آن، کاربر روی دکمه رادیویی فعال برای Authenticator Y کلیک می‌کند و درخواستی را برای تنظیم Y به عنوان فعال به CDP ارسال می‌کند. دکمه رادیویی فعال برای Y انتخاب شده است، و بقیه، از جمله برای X، از حالت انتخاب خارج می شوند.

3. در باطن، فراخوانی برای تنظیم Y به عنوان فعال تکمیل و حل می شود. Y اکنون فعال است و همه احراز هویت‌کنندگان دیگر فعال نیستند.

4. در باطن، تماس برای تنظیم X به عنوان فعال تکمیل و حل می شود. X اکنون فعال است و سایر احراز هویت، از جمله Y، فعال نیستند.

حال، وضعیت حاصل به شرح زیر است: X احراز هویت فعال است . با این حال، دکمه رادیویی فعال برای X انتخاب نشده است . Y احراز هویت فعال نیست . با این حال، دکمه رادیویی فعال برای Y انتخاب شده است . بین قسمت جلویی و وضعیت واقعی احراز هویت‌کنندگان اختلاف نظر وجود دارد. بدیهی است که این یک مشکل است.

راه حل ما: برقراری ارتباط شبه دو طرفه بین دکمه های رادیویی و احراز هویت فعال. ابتدا، ما یک متغیر activeId در نمای نگه می داریم تا شناسه احراز هویت فعال فعلی را پیگیری کنیم. سپس، منتظر می‌شویم تا تماس، یک Authenticator فعال را تنظیم کند تا برگردد، سپس activeId به شناسه آن authenticator تنظیم کنید. در نهایت، ما از طریق هر بخش authenticator حلقه می زنیم. اگر شناسه آن بخش برابر با activeId باشد، دکمه را انتخاب می کنیم. در غیر این صورت، دکمه را در حالت انتخاب نشده قرار می دهیم.

در اینجا به نظر می رسد:

 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

معیارهای استفاده

ما می خواستیم استفاده از این ویژگی را ردیابی کنیم. در ابتدا با دو گزینه روبرو شدیم.

1. هر بار که برگه WebAuthn در DevTools باز شد، بشمارید . این گزینه به طور بالقوه می تواند منجر به شمارش بیش از حد شود، زیرا ممکن است شخصی بدون استفاده از آن برگه را باز کند.

2. ردیابی تعداد دفعاتی که کادر انتخاب "فعال کردن محیط احراز هویت مجازی" در نوار ابزار تغییر کرده است . این گزینه همچنین یک مشکل بیش از حد احتمالی داشت زیرا برخی ممکن است در همان جلسه چندین بار محیط را روشن و خاموش کنند.

در نهایت ، ما تصمیم گرفتیم که با دومی برویم اما شمارش را با داشتن یک چک محدود کنیم تا ببینیم آیا محیط قبلاً در جلسه فعال شده است یا خیر . بنابراین ، ما فقط تعداد 1 را بدون توجه به چند بار توسعه دهنده محیط زیست را افزایش می دهیم. این امر به این دلیل است که هر بار که برگه باز می شود ، یک جلسه جدید ایجاد می شود ، بنابراین مجدداً چک را تنظیم می کند و اجازه می دهد تا مجدداً متریک افزایش یابد.

خلاصه

با تشکر از شما برای خواندن! اگر پیشنهادی برای بهبود برگه WebAuthn دارید ، با تشکیل یک اشکال به ما اطلاع دهید.

اگر می خواهید در مورد WebAuthn اطلاعات بیشتری کسب کنید ، در اینجا برخی از منابع وجود دارد:

• WebAuthn Devtools Design Design Doc
• تست احراز هویت وب Doc طراحی API
• API تأیید هویت وب (WebAuthn) مشخصات
• توضیح و راهنمای WebAuthn

کانال های پیش نمایش را بارگیری کنید

استفاده از کروم قناری ، دیو یا بتا را به عنوان مرورگر توسعه پیش فرض خود در نظر بگیرید. این کانال های پیش نمایش به شما امکان دسترسی به آخرین ویژگی های DevTools را می دهد ، به شما امکان می دهد API های پلت فرم وب برش را آزمایش کنید و به شما در یافتن مشکلات در سایت خود قبل از کاربران کمک کنید!

با تیم Chrome Devtools در تماس باشید

برای بحث در مورد ویژگی های جدید ، به روزرسانی ها یا هر چیز دیگری که مربوط به DevTools است ، از گزینه های زیر استفاده کنید.

• بازخورد و درخواست های ویژگی را در Crbug.com به ما ارسال کنید.
• با استفاده از گزینه های More_vert بیشتر ، یک مسئله DevTools را گزارش دهید> راهنما > گزارش یک مسئله DevTools در DevTools.
• توییت در chromedevtools .
• در مورد فیلم های YouTube DevTools یا نکات DevTools ، فیلم های YouTube را در مورد فیلم های YouTube DevTools جدید بگذارید.

Fawaz Mohammad

Nina Satragno

API تأیید هویت وب ، که به عنوان WebAuthn نیز شناخته می شود ، به سرورها اجازه می دهد تا از رمزنگاری کلید عمومی - به جای رمزهای عبور - استفاده کنند تا کاربران را ثبت و تأیید کنند. این کار را با فعال کردن ادغام بین این سرورها و معتادان قوی انجام می دهد. این معتبر ممکن است دستگاه های فیزیکی اختصاصی (به عنوان مثال کلیدهای امنیتی) یا با سیستم عامل (به عنوان مثال خوانندگان اثر انگشت) یکپارچه شوند. می توانید اطلاعات بیشتر در مورد WebAuthn را در اینجا در WebAuthn.Guide بخوانید.

نقاط درد توسعه دهنده

پیش از این پروژه ، Webauthn فاقد پشتیبانی از اشکال زدایی بومی در Chrome بود. توسعه دهنده ای که از WebAuth استفاده می کرد ، نیاز به دسترسی به تأیید کنندگان فیزیکی داشت. این به ویژه به دو دلیل دشوار بود:

1. بسیاری از طعم های مختلف معتبر وجود دارد. اشکال زدایی از وسعت پیکربندی ها و قابلیت ها ضروری است که توسعه دهنده به بسیاری از معتادان مختلف ، گاه گران قیمت دسترسی داشته باشد.

2. تأیید کنندگان فیزیکی ، با طراحی ، ایمن هستند. بنابراین ، بازرسی از وضعیت آنها معمولاً غیرممکن است.

ما می خواستیم با اضافه کردن پشتیبانی اشکال زدایی درست در Devtools Chrome ، این کار را آسانتر کنیم.

راه حل: یک برگه جدید WebAuthn

برگه Webauthn Devtools با اجازه دادن به توسعه دهندگان برای تقلید از این معتادان ، سفارشی کردن توانایی های خود و بازرسی از ایالات خود ، اشکال زدایی Webauthn را بسیار آسانتر می کند.

پیاده سازی

اضافه کردن پشتیبانی اشکال زدایی به Webauthn یک فرآیند دو بخشی بود.

قسمت 1: افزودن دامنه WebAuthn به پروتکل Chrome Devtools

اول ، ما یک دامنه جدید را در پروتکل Chrome Devtools (CDP) اجرا کردیم که به یک کنترل کننده که با Backend WebAuthn ارتباط برقرار می کند ، وصل می شود.

CDP DevTools را با کروم متصل می کند. در مورد ما ، ما از اقدامات دامنه WebAuthn برای عبور از برگه Webauthn Devtools و اجرای Chromium از WebAuthn استفاده کردیم.

دامنه WebAuthn امکان فعال و غیرفعال کردن محیط تأیید کننده مجازی را فراهم می کند ، که مرورگر را از کشف واقعی تأیید کننده جدا می کند و به جای آن در یک کشف مجازی وصل می شود.

ما همچنین روش هایی را در دامنه قرار می دهیم که به عنوان یک لایه نازک به رابط های مجازی موجود و رابط های کشف مجازی ، که بخشی از اجرای WebAuthn Chromium هستند ، عمل می کنند. این روش ها شامل افزودن و حذف معتبر و همچنین ایجاد ، دریافت و پاکسازی اعتبار ثبت شده آنها است.

( کد را بخوانید)

قسمت 2: ساخت برگه کاربر

دوم ، ما یک برگه کاربر در جلوی DevTools ساختیم. این برگه از یک نمای و یک مدل ساخته شده است. یک عامل تولید شده خودکار دامنه را با برگه متصل می کند.

در حالی که 3 مؤلفه لازم لازم است ، ما فقط باید در مورد دو مورد از آنها نگران باشیم: مدل و نمای . مؤلفه 3 - عامل ، پس از افزودن دامنه به صورت اتوژنری می شود. به طور خلاصه ، عامل لایه ای است که تماس های بین قسمت جلویی و CDP را حمل می کند.

مدل

مدل لایه جاوا اسکریپت است که عامل و نمای را به هم متصل می کند. برای مورد ما ، مدل بسیار ساده است. این دستورات را از نظر می گیرد ، درخواست ها را به گونه ای می سازد که توسط CDP قابل مصرف هستند و سپس آنها را از طریق عامل ارسال می کنند. این درخواست ها معمولاً یک جهته هستند و هیچ اطلاعاتی به نمای ارسال نمی شود.

با این حال ، ما گاهی اوقات پاسخی از مدل را پس می گیریم تا یک شناسه را برای تأیید کننده تازه ایجاد شده ارائه دهیم یا اعتبارنامه های ذخیره شده در یک تأیید کننده موجود را برگردانیم.

( کد را بخوانید)

نمای

ما از این نمایش استفاده می کنیم تا رابط کاربری را که یک توسعه دهنده می تواند هنگام دسترسی به DevTools پیدا کند ، ارائه دهد. شامل:

1. نوار ابزار برای فعال کردن محیط تأیید کننده مجازی.
2. بخشی برای افزودن تأیید اعتبار.
3. بخشی برای تأیید کنندگان ایجاد شده.

( کد را بخوانید)

نوار ابزار برای فعال کردن محیط تأیید کننده مجازی

از آنجا که بیشتر تعامل کاربر با یک تأیید کننده به طور هم زمان و نه کل برگه وجود دارد ، تنها عملکردی که ما در نوار ابزار ارائه می دهیم ، تغییر و خاموش کردن محیط مجازی است.

چرا این لازم است؟ این مهم است که کاربر مجبور باشد به صراحت محیط را تغییر دهد زیرا انجام این کار مرورگر را از کشف واقعی تأیید کننده جدا می کند. بنابراین ، در حالی که این کار روشن است ، تأیید کنندگان فیزیکی متصل مانند یک خواننده اثر انگشت تشخیص داده نمی شوند.

ما تصمیم گرفتیم که ضامن صریح به معنای تجربه کاربری بهتر باشد ، به خصوص برای کسانی که بدون انتظار کشف واقعی در برگه WebAuthn سرگردان می شوند.

افزودن بخش تأیید کنندگان

پس از فعال کردن محیط تأیید کننده مجازی ، ما توسعه دهنده را با یک شکل درون خطی ارائه می دهیم که به آنها امکان می دهد یک تأیید کننده مجازی اضافه کنند. در این فرم ، ما گزینه های سفارشی سازی را ارائه می دهیم که به کاربر امکان می دهد پروتکل و روش های حمل و نقل تأیید کننده را تصمیم بگیرد ، و همچنین اینکه تأیید کننده از کلیدهای مقیم و تأیید کاربر پشتیبانی می کند.

پس از افزودن کاربر ، این گزینه ها به صورت بسته بندی شده و به مدل ارسال می شوند که باعث می شود تماس برای ایجاد یک تأیید کننده باشد. پس از اتمام این کار ، قسمت جلویی پاسخی دریافت می کند و سپس UI را اصلاح می کند تا تأیید کننده تازه ایجاد شده را در بر بگیرد.

نمای تأیید کننده

هر بار که یک تأیید کننده تقلید می شود ، ما بخشی را به نمای تأیید کننده اضافه می کنیم تا آن را نشان دهد. هر بخش معتبر شامل یک نام ، شناسه ، گزینه های پیکربندی ، دکمه ها برای حذف تأیید اعتبار یا تنظیم آن فعال و یک جدول اعتبار است.

نام معتبر

نام Authenticator قابل تنظیم و پیش فرض برای "تأیید اعتبار" است که با 5 کاراکتر آخر شناسه آن همراه است. در ابتدا ، نام معتبر شناسه کامل آن و غیرقابل تغییر بود. ما نامهای قابل تنظیم را پیاده سازی کردیم تا کاربر بتواند تأیید کننده را بر اساس قابلیت های خود ، تأیید کننده فیزیکی که برای تقلید است ، یا هر نام مستعار که هضم کمی آسانتر از یک شناسه 36 شخصیت است ، برچسب گذاری کند.

جدول اعتبارنامه

ما یک جدول را به هر بخش معتبر اضافه کردیم که تمام اعتبارنامه های ثبت شده توسط یک تأیید کننده را نشان می دهد. در هر ردیف ، ما اطلاعاتی در مورد اعتبار و همچنین دکمه هایی برای حذف یا صادرات اعتبار ارائه می دهیم.

در حال حاضر ، ما اطلاعات را برای پر کردن این جداول با نظرسنجی CDP جمع آوری می کنیم تا اعتبار ثبت شده برای هر معتبر را بدست آوریم. در آینده ، ما قصد داریم رویدادی را برای ایجاد اعتبار اضافه کنیم.

دکمه فعال

ما همچنین یک دکمه رادیویی فعال را به هر بخش معتبر اضافه کردیم. تأیید کننده که در حال حاضر فعال است ، تنها کسی خواهد بود که اعتبار خود را می شنود و ثبت می کند. بدون این ، ثبت اعتبار اعتبارنامه به چندین تأیید کننده غیر قطعی است که می تواند هنگام تلاش برای آزمایش WebAuthn با استفاده از آنها ، یک نقص مهلک باشد.

ما وضعیت فعال را با استفاده از روش setUserPresence در تأیید کنندگان مجازی پیاده سازی کردیم. روش SetUserPresence تعیین می کند که آیا تست های حضور کاربر برای یک تأیید کننده خاص موفق می شوند. اگر آن را خاموش کنیم ، یک تأیید کننده قادر به گوش دادن به اعتبار نیست. بنابراین ، با اطمینان از این که حداکثر یک تأیید کننده (یک مجموعه به عنوان فعال) و غیرفعال کردن حضور کاربر برای همه دیگران است ، می توانیم رفتار قطعی را مجبور کنیم.

یک چالش جالب که هنگام افزودن دکمه فعال با آن روبرو شدیم ، جلوگیری از شرایط مسابقه بود. سناریوی زیر را در نظر بگیرید:

1. کاربر بر روی دکمه رادیو فعال برای تأیید کننده X کلیک می کند ، و یک درخواست به CDP ارسال می کند تا X را به عنوان فعال تنظیم کند. دکمه رادیویی فعال برای X انتخاب شده است و سایر موارد دیگر از بین می روند.

2. بلافاصله پس از آن ، کاربر روی دکمه رادیو فعال برای تأیید اعتبار Y کلیک می کند و درخواست را به CDP ارسال می کند تا Y را به عنوان فعال تنظیم کند. دکمه رادیویی فعال برای y انتخاب شده است و سایر موارد دیگر ، از جمله برای X ، انتخاب نشده اند.

3. در باطن ، فراخوانی برای تنظیم Y به عنوان فعال و حل شده است. y اکنون فعال است و همه معتبر دیگر نیستند.

4. در باطن ، فراخوان تنظیم X به عنوان فعال و حل و فصل شده است. X اکنون فعال است و سایر معتادان دیگر ، از جمله Y ، نیستند.

اکنون ، وضعیت حاصل به شرح زیر است: X تأیید کننده فعال است . با این حال ، دکمه رادیویی فعال برای X انتخاب نشده است . y تأیید کننده فعال نیست . با این حال ، دکمه رادیویی فعال برای y انتخاب شده است . اختلاف بین قسمت جلویی و وضعیت واقعی تأیید کنندگان وجود دارد. بدیهی است که این یک مشکل است.

راه حل ما: برقراری ارتباط شبه دو طرفه بین دکمه های رادیویی و تأیید کننده فعال. ابتدا ، ما یک متغیر activeId در نمای حفظ می کنیم تا شناسه تأیید کننده فعال فعلی را پیگیری کنیم. سپس ، ما منتظر هستیم تا تماس یک تأیید کننده را فعال کند تا برگردد و سپس activeId بر روی شناسه آن تأیید کننده تنظیم کند. در آخر ، ما از طریق هر بخش معتبر حلقه می کنیم. اگر شناسه آن بخش برابر activeId باشد ، ما دکمه را روی انتخاب قرار می دهیم. در غیر این صورت ، ما دکمه را انتخاب کردیم.

در اینجا به نظر می رسد:

 async _setActiveAuthenticator(authenticatorId) {
   await this._clearActiveAuthenticator();
   await this._model.setAutomaticPresenceSimulation(authenticatorId, true);
   this._activeId = authenticatorId;
   this._updateActiveButtons();
 }
 
 _updateActiveButtons() {
   const authenticators = this._authenticatorsView.getElementsByClassName('authenticator-section');
   Array.from(authenticators).forEach(authenticator => {
     authenticator.querySelector('input.dt-radio-button').checked =
         authenticator.getAttribute('data-authenticator-id') === this._activeId;
   });
 }
 
 async _clearActiveAuthenticator() {
   if (this._activeId) {
     await this._model.setAutomaticPresenceSimulation(this._activeId, false);
   }
   this._activeId = null;
 }

معیارهای استفاده

ما می خواستیم استفاده از این ویژگی را ردیابی کنیم. در ابتدا ، ما با دو گزینه روبرو شدیم.

1. هر بار که برگه WebAuthn در Devtools باز شد ، حساب کنید . این گزینه به طور بالقوه می تواند منجر به بیش از حد شود ، زیرا ممکن است کسی بدون استفاده از آن ، برگه را باز کند.

2. تعداد دفعاتی که کادر انتخاب "Enable Virtual Authenticator Environment" را در نوار ابزار انجام داده است ، پیگیری کنید . این گزینه همچنین یک مشکل بیش از حد احتمالی داشت زیرا برخی ممکن است در همان جلسه چندین بار محیط را روشن و خاموش کنند.

در نهایت ، ما تصمیم گرفتیم که با دومی برویم اما شمارش را با داشتن یک چک محدود کنیم تا ببینیم آیا محیط قبلاً در جلسه فعال شده است یا خیر . بنابراین ، ما فقط تعداد 1 را بدون توجه به چند بار توسعه دهنده محیط زیست را افزایش می دهیم. این امر به این دلیل است که هر بار که برگه باز می شود ، یک جلسه جدید ایجاد می شود ، بنابراین مجدداً چک را تنظیم می کند و اجازه می دهد تا مجدداً متریک افزایش یابد.

خلاصه

با تشکر از شما برای خواندن! اگر پیشنهادی برای بهبود برگه WebAuthn دارید ، با تشکیل یک اشکال به ما اطلاع دهید.

اگر می خواهید در مورد WebAuthn اطلاعات بیشتری کسب کنید ، در اینجا برخی از منابع وجود دارد:

• WebAuthn Devtools Design Design Doc
• تست احراز هویت وب Doc طراحی API
• API تأیید هویت وب (WebAuthn) مشخصات
• توضیح و راهنمای WebAuthn

کانال های پیش نمایش را بارگیری کنید

استفاده از کروم قناری ، دیو یا بتا را به عنوان مرورگر توسعه پیش فرض خود در نظر بگیرید. این کانال های پیش نمایش به شما امکان دسترسی به آخرین ویژگی های DevTools را می دهد ، به شما امکان می دهد API های پلت فرم وب برش را آزمایش کنید و به شما در یافتن مشکلات در سایت خود قبل از کاربران کمک کنید!

با تیم Chrome Devtools در تماس باشید

برای بحث در مورد ویژگی های جدید ، به روزرسانی ها یا هر چیز دیگری که مربوط به DevTools است ، از گزینه های زیر استفاده کنید.

• بازخورد و درخواست های ویژگی را در Crbug.com به ما ارسال کنید.
• با استفاده از گزینه های More_vert بیشتر ، یک مسئله DevTools را گزارش دهید> راهنما > گزارش یک مسئله DevTools در DevTools.
• توییت در chromedevtools .
• در مورد فیلم های YouTube DevTools یا نکات DevTools ، فیلم های YouTube را در مورد فیلم های YouTube DevTools جدید بگذارید.