תאריך הפרסום: 13 באוגוסט 2026, תאריך העדכון האחרון: 5 באוקטובר 2026
גרסת המקור לניסיון של אימות כתובות אימייל התחילה ב-Chrome 150. על סמך המשוב שלכם, ביצענו כמה תיקונים ושיפורים. במאמר הזה נסביר מה השינויים הצפויים ומה אתם צריכים לעשות באתר או בשירות שלכם.
קודם כל, נסביר בקצרה על הפונקציונליות של אימות כתובת האימייל (או שתוכלו לעיין בהודעה הקודמת לקבלת פרטים נוספים). בתבנית נפוצה באתרים, המשתמש מזין כתובת אימייל כחלק מתהליך ההרשמה, הכניסה, שחזור החשבון ועוד, ואז הוא צריך לעבור לאימייל שלו כדי ללחוץ על קישור קסם או לקבל סיסמה חד-פעמית. אימות כתובת האימייל הוא שיפור מתקדם של התהליך הזה, כי הוא מאמת את כתובת האימייל ישירות בדפדפן מול הספק. לאחר מכן האתר מקבל מהדפדפן טוקן שאפשר לאמת מול ספק האימייל, וכך אפשר לדלג על שליחת האימייל הזה לגמרי.
עדכונים שגלויים למשתמשים
שינויים בממשק המשתמש או בהתנהגות שגלויים למשתמשים.
שדה להזנת כתובת האימייל
בעבר, משתמשים היו צריכים להשתמש בהשלמה אוטומטית או במילוי אוטומטי כדי להזין כתובת אימייל. עכשיו, הזנת כתובת אימייל בשדה בכל דרך (למשל, הקלדה או הדבקה) מפעילה את תהליך האימות ברגע שהמשתמש יוצא מרכיב input, בדומה לאירוע change. כלומר, אימות האימייל אמור להיות מופעל באופן אוטומטי כשמזינים כתובת אימייל.
מחוון התקדמות
בנוסף, אנחנו בודקים בגרסה 152 ואילך של Chrome את האפשרות להציג אינדיקטור התקדמות לתהליך האימות. תהליך האימות מהיר, אבל עדיין יכול להיות שמשתמש יגיש את הטופס לפני שהתהליך יסתיים. במהלך האימות מוצג אינדיקטור התקדמות בצורת סמל טעינה, ולאחר מכן סימן וי בסיום האימות בסוף השורה (בצד שמאל בשפה שקוראים מימין לשמאל) של שדה להזנת קלט.
אם הפעולה הזו גורמת לבעיות או שאתם מבחינים בהתנהגות לא צפויה, דווחו על באג.
מחשבים בלבד
חובת האימות באימייל זמינה במחשב בלבד עד Chrome 152. אנחנו בודקים אפשרות להוסיף תמיכה גם ב-Android, ונעדכן כאן בעתיד.
עדכונים לגבי הגורם המאמת
שינויים באתרים שבהם נאספות ומאומתות כתובות אימייל.
אימות טוקן
אסימון אימות כתובת האימייל מסופק בפורמט Selective Disclosure for JSON Web Tokens (SD-JWT). במצב הגולמי שלו, זה נראה כך: אסימון JWT בחתימת מנפיק, שאחריו אפס או יותר גילויים, ומסתיים באסימון JWT של שיוך מפתח, כאשר כל רכיב מופרד באמצעות סימן הטילדה:
<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>
האסימון לאימות כתובת האימייל, בצורתו הנוכחית, מחזיר רק את ה-JWT החתום על ידי המנפיק ואת ה-JWT של שיוך המפתח, ללא גילוי נאות. בפוסט המקורי בבלוג ובאיטרציה הראשונה של ההדגמה, הטוקן פוצל לשניים ושני ה-JWT נותחו. השיטה הזו לא יציבה והיא תפסיק לפעול אם בעתיד יתווספו חשיפות סלקטיביות.
במקום להסתמך על התכונה הזו בהצעה הנוכחית, כדאי לוודא שההטמעה מנתחת את אסימון ה-SD-JWT בצורה נכונה בהתאם למפרט שלו, רצוי באמצעות ספריות לפלטפורמה שלכם. לדוגמה, קוד האימות של ההדגמה משתמש עכשיו ב-@sd-jwt/core כדי לנתח את הטוקן ולאמת את שיוך המפתח (קהל, צופן חד-פעמי וגיבוב), ואז ב-jose כדי לאמת את החתימות של ה-EVT של המנפיק ואת ה-JWT של שיוך המפתח של הדפדפן.
תקופות ניסיון של תכונות ממקורות צד שלישי
החל מאוגוסט, אין תמיכה בניסויים של צד שלישי לאימות אימייל. גרסאות מקור לניסיון של צד שלישי מאפשרות למקור של צד שלישי להפעיל את הפונקציונליות של הניסיון באתר שבו הוא נכלל, לדוגמה, תלות ב-JavaScript ממקורות שונים. אם זה חשוב לתרחיש השימוש שלכם, אתם יכולים להוסיף תגובה או לעקוב אחרי הבאג הזה.
השוואה של כתובות אימייל ללא תלות באותיות רישיות
תזכורת: ספקי אימייל עשויים להחזיר את כתובת האימייל הקנונית באותיות רישיות, לדוגמה, Demo.User@example.com גם אם demo.user@example.com צוינה בטופס. חשוב לוודא שאתם מבצעים השוואה לא תלוית-אותיות רישיות עם כתובת האימייל שהתקבלה. בנוסף, תיקנו באג בדף ההגדרות שגרם לכך שרשימת כתובות האימייל כללה וריאציות של אותה כתובת אימייל, שבהן האותיות היו שונות (גדולות או קטנות).
עדכונים מספקים
שינויים לספקי אימייל.
חתימת HTTP על הודעות לבקשות הנפקה
אנחנו מציגים שינוי שעלול לשבור תאימות ב-Chrome 153, שבו בקשת ההנפקה תשלח רק את email בפורמט application/json עם חתימות של הודעות HTTP.
- Chrome 152 (ובגרסאות קודמות): נקודת הקצה של הנפקת האישורים מקבלת בקשת
application/x-www-form-urlencodedPOSTעםrequest_tokenבגוף הבקשה. - Chrome 153 (ואילך): סוג התוכן משתנה ל-
application/jsonעם הכותרותSignature,Signature-Inputו-Signature-Key, וגוף שמכיל רק את המפתחemail.
בהתאם לרמות התנועה הנוכחיות וליעדים שלכם בבדיקה, אתם יכולים:
- תמיכה בשני הפורמטים ומעבר ביניהם בהתאם לסוג התוכן. אחרי שגרסה 153 של Chrome תגיע לגרסה יציבה בסוף אוגוסט, תוכלו להעריך את התנועה כדי להסיר את הפונקציונליות מדור קודם.
- פשוט עוברים לפורמט החדש, כלומר האימות ייכשל אצל משתמשים בגרסאות קודמות של Chrome.
נקודת הקצה (endpoint) להנפקת כרטיסים בקוד ההדגמה עודכנה כדי לטפל בשני התהליכים באמצעות 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. התגובות מהקהילה עד כה היו מועילות מאוד, ולכן אפשר לצפות להמשך עדכונים ושיפורים.