منتشر شده: ۱۳ آگوست ۲۰۲۶
نسخه آزمایشی تأیید ایمیل در کروم ۱۵۰ آغاز شد. بر اساس بازخورد شما، ما چندین اصلاح و بهبود انجام دادهایم. این پست مروری بر تغییرات و اقداماتی که باید در سایت یا سرویس خود انجام دهید، ارائه میدهد.
ابتدا، خلاصهای از عملکرد تأیید ایمیل (یا برای جزئیات بیشتر به اطلاعیه قبلی مراجعه کنید). یک الگوی رایج در سایتها این است که کاربر آدرس ایمیل را به عنوان بخشی از ثبت نام، ورود به سیستم، بازیابی حساب و موارد دیگر وارد میکند و سپس باید به ایمیل خود مراجعه کند تا روی یک لینک جادویی کلیک کند یا یک رمز یکبار مصرف (OTP) دریافت کند. تأیید ایمیل با تأیید آدرس ایمیل توسط ارائه دهنده مستقیماً در مرورگر، پیشرفت فزایندهای نسبت به این ارائه میدهد. سپس سایت یک توکن از مرورگر دریافت میکند که میتواند آن را با ارائه دهنده ایمیل تأیید کند و از ارسال آن ایمیل به طور کلی صرف نظر کند.
بهروزرسانیهای کاربرپسند
تغییرات در رابط کاربری یا رفتار کاربر در مواجهه با آن.
ورود ایمیل
پیش از این، کاربران مجبور بودند برای وارد کردن آدرس ایمیل از تکمیل خودکار یا تکمیل خودکار استفاده کنند. اکنون، وارد کردن آدرس ایمیل در فیلد به هر روشی (مثلاً تایپ کردن یا چسباندن) پس از خروج کاربر از عنصر input ، فرآیند تأیید را آغاز میکند، مشابه یک رویداد change . این بدان معناست که تأیید ایمیل باید به طور مؤثر برای هر ورودی آدرس ایمیل فعال شود.
نشانگر پیشرفت
ما همچنین در حال آزمایش یک نشانگر پیشرفت برای فرآیند تأیید در کروم ۱۵۲+ هستیم. اگرچه فرآیند تأیید سریع است، اما هنوز هم کاربر میتواند فرم را قبل از تکمیل فرآیند ارسال کند. نشانگر پیشرفت هنگام تأیید، یک چرخنده و سپس یک علامت تیک در انتهای درونخطی (سمت راست برای زبان LTR) فیلد ورودی نشان میدهد.
اگر این باعث بروز هرگونه مشکلی شد یا رفتار غیرمنتظرهای مشاهده کردید، اشکال (bug) را مطرح کنید .
فقط دسکتاپ
تأیید ایمیل فقط در نسخه دسکتاپ تا کروم ۱۵۲ در دسترس است. ما به طور فعال در حال بررسی پشتیبانی از آن در اندروید نیز هستیم و در آینده بهروزرسانیهایی در اینجا ارائه خواهیم داد.
بهروزرسانیهای تأییدکننده
تغییرات برای سایتهایی که ایمیلها را جمعآوری و تأیید میکنند.
اعتبارسنجی توکن
توکن تأیید ایمیل در قالب افشای انتخابی برای توکنهای وب JSON (SD-JWT) ارائه میشود. در شکل خام خود، این به این شکل است، یک JWT امضا شده توسط صادرکننده، به دنبال آن صفر یا چند افشای اطلاعات، و در نهایت یک JWT اتصال کلید که هر جزء با یک علامت تیلدا از هم جدا شده است:
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
توکن تأیید ایمیل، در شکل فعلی خود، فقط JWT امضا شده توسط صادرکننده و JWT اتصال کلید را بدون هیچ گونه افشای اطلاعاتی برمیگرداند. پست وبلاگ اصلی و اولین نسخه آزمایشی، فقط توکن را به دو قسمت تقسیم کرده و دو JWT را تجزیه میکردند. این روش شکننده است و اگر افشای انتخابی در آینده اضافه شود، از کار خواهد افتاد.
به جای تکیه بر این ویژگی طرح پیشنهادی فعلی، باید اطمینان حاصل کنید که پیادهسازی شما به درستی توکن SD-JWT را مطابق با مشخصات آن تجزیه میکند، که در حالت ایدهآل با استفاده از کتابخانههای مخصوص پلتفرم شما انجام میشود. به عنوان مثال، کد تأیید نسخه آزمایشی اکنون از @sd-jwt/core برای تجزیه توکن و اعتبارسنجی اتصال کلید (مخاطب، nonce و هش) استفاده میکند و سپس برای تأیید امضاها برای EVT صادرکننده و JWT اتصال کلید مرورگر، jose .
آزمایشهای منشأ شخص ثالث
از ماه آگوست ، نسخههای آزمایشی شخص ثالث برای تأیید ایمیل پشتیبانی نمیشوند. نسخههای آزمایشی شخص ثالث به یک شخص ثالث اجازه میدهند تا قابلیت آزمایشی را در سایتی که در آن قرار دارد، فعال کند، به عنوان مثال، یک وابستگی جاوا اسکریپت بینمنبعی. اگر این مورد برای مورد استفاده شما در اولویت است، در مورد اشکال ردیابی نظر دهید یا آن را دنبال کنید.
مقایسه ایمیل بدون حساسیت به حروف بزرگ و کوچک
یادآوری میشود که ارائهدهندگان ایمیل ممکن است آدرس ایمیل استاندارد را با حروف بزرگ برگردانند، برای مثال، Demo.User@example.com حتی اگر demo.user@example.com در فرم ارائه شده باشد. مطمئن شوید که مقایسهای بدون حساسیت به حروف بزرگ و کوچک با آدرس ایمیل دریافتی انجام میدهید. ما همچنین اشکالی را در صفحه تنظیمات برطرف کردهایم که در آن ممکن است شاهد تغییرات حساس به حروف بزرگ و کوچک در یک آدرس ایمیل مشابه بوده باشید.
بهروزرسانیهای ارائهدهنده
تغییرات برای ارائه دهندگان ایمیل.
امضای پیام HTTP برای درخواستهای صدور
ما در حال معرفی یک تغییر اساسی در کروم ۱۵۳ هستیم که در آن درخواست صدور، فقط email را با فرمت application/json و با امضاهای پیام HTTP ارسال میکند.
- کروم ۱۵۲ (و قبل از آن): نقطه پایانی صدور، یک درخواست
POSTباapplication/x-www-form-urlencodedبه همراهrequest_tokenدر بدنه دریافت میکند. - کروم ۱۵۳ (و بعد از آن): نوع محتوا به
application/jsonبا هدرهایSignature،Signature-InputوSignature-Keyو بدنه ای که فقط حاوی کلیدemailاست، تغییر میکند.
بسته به سطح ترافیک فعلی و اهدافتان در آزمایش، میتوانید یکی از موارد زیر را انجام دهید:
- از هر دو قالب پشتیبانی کنید و بر اساس نوع محتوا تغییر دهید. به محض اینکه کروم ۱۵۳ در پایان ماه آگوست به نسخه پایدار برسد، میتوانید ترافیک خود را ارزیابی کنید تا عملکرد قدیمی را حذف کنید.
- فقط کافیست به فرمت جدید تغییر دهید، به این معنی که تأیید برای کاربرانی که از نسخههای قبلی کروم استفاده میکنند، انجام نخواهد شد.
نقطه پایانی صدور در کد آزمایشی بهروزرسانی شده است تا هر دو جریان را با استفاده از structured-headers و http-message-sig مدیریت کند.
فرمت کامل درخواست:
POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"
{email: "demo@example.com"}
قالب پاسخ ثابت میماند: یک issuance_token در بدنه application/json .
شما میتوانید نظرات و پیشنهادات خود را در مخازن پیشنهادها بخوانید و مطرح کنید: WICG/email-verification و dickhardt/email-verification . پاسخ جامعه تاکنون بسیار مفید بوده است، بنابراین میتوانید انتظار داشته باشید که بهروزرسانیها و بهبودها ادامه یابد.