אתרים מסוימים טוענים כי האפשרות למשתמשים להדביק סיסמאות מפחיתה את רמת האבטחה. עם זאת, הדבקת הסיסמאות משפרת את האבטחה כי היא מאפשרת להשתמש במנהלי סיסמאות.
מנהלי סיסמאות בדרך כלל יוצרים סיסמאות חזקות למשתמשים, שומרים אותן באופן מאובטח ומדביקים אותן באופן אוטומטי בשדות של סיסמאות כשהמשתמשים צריכים להתחבר. הגישה הזו בדרך כלל מאובטחת יותר מאשר לאלץ את המשתמשים להקליד סיסמאות קצרות מספיק כדי לזכור אותן.
באופן כללי, אין למנוע מהמשתמשים להדביק ברכיבי <input>
.
איך הבדיקה הזו ב-Lighthouse נכשלת
ב-Lighthouse מסומן קוד שמונע ממשתמשים להדביק בשדות להזנת קלט שאינם לקריאה בלבד:
![ביקורת Lighthouse מראה שהמשתמשים לא יכולים להדביק דפים בשדה של סיסמה](https://developer.chrome.com/static/docs/lighthouse/best-practices/paste-preventing-inputs/image/lighthouse-audit-shows-pa-37a53608e65b1.png?authuser=5&hl=he)
מערכת Lighthouse אוספת את כל רכיבי <input>
שהם לא לקריאה בלבד, מדביקה טקסט מסוים בכל רכיב ולאחר מכן מאמתת שאירוע paste
לא נמנע על ידי handler בהתאמה אישית של אירועים.
אפשר גם למנוע הדבקה מחוץ ל-event listener של paste
.
מערכת Lighthouse לא מזהה את התרחיש הזה.
איך מפעילים הדבקה בשדות של סיסמאות
מאתרים את הקוד שמונע את ההדבקה
כדי למצוא ולבדוק במהירות את הקוד שמונע הדבקה:
- מרחיבים את החלונית Event Listener Breakpoints.
- מרחיבים את הרשימה לוח.
- מסמנים את התיבה
paste
. - מדביקים טקסט בשדה סיסמה בדף.
- צריך להשהות את כלי הפיתוח בשורת הקוד הראשונה ב-event listener הרלוונטי של
paste
.
מסירים את הקוד שמונע את ההדבקה
מקור הבעיה הוא בדרך כלל קריאה ל-preventDefault()
בתוך ה-event listener של paste
שמשויך לרכיב הקלט של הסיסמה:
let input = document.querySelector('input');
input.addEventListener('paste', (e) => {
e.preventDefault(); // This is what prevents pasting.
});
אם אתם רק מקשיבים להדבקת אירועים כדי למנוע אותם, עליכם להסיר את כל ה-event listener.