תוספים יכולים לאחסן קובצי Cookie ולגשת לממשקי API של אחסון אינטרנט באופן דומה לאתר רגיל. עם זאת, במקרים מסוימים, ההתנהגות שלהם שונה בתוספים.
מידע על ה-API של התוסף זמין במאמר browser.storage.
אחסון
לעתים קרובות כדאי להשתמש בממשקי API של אחסון בפלטפורמת האינטרנט בתוספים. בקטע הזה נסביר על ההתנהגות של ממשקי ה-API האלה בהקשר של תוסף, שלפעמים שונה מההתנהגות שלהם באינטרנט.
התמדה
האחסון של התוסף לא מתנקה כשמשתמש מנקה את נתוני הגלישה. ההגדרה הזו חלה על כל הנתונים שמאוחסנים באמצעות ממשקי API של אחסון באינטרנט (כמו Local Storage ו-IndexedDB).
כברירת מחדל, התוספים כפופים למגבלות הרגילות של מכסת האחסון, שאפשר לבדוק אותן באמצעות קריאה ל-navigator.storage.estimate(). במקרים נדירים, יכול להיות שגם נפח האחסון יפונה בגלל עומס זיכרון כבד. כדי להימנע מכך:
- מבקשים את ההרשאה
"unlimitedStorage", שמשפיעה על ממשקי API של אחסון תוספים ואחסון אתרים, ופוטרת את התוספים מהגבלות מכסה ומפינוי. - כדאי להתקשר למספר
navigator.storage.persist()כדי לקבל הגנה מפני פינוי.
נפח האחסון של התוסף משותף למקור של התוסף, כולל קובץ השירות (service worker) של התוסף, כל הדפים של התוסף (כולל חלונות קופצים וחלונית הצד) ומסמכים מחוץ למסך. בסקריפטים של תוכן, קריאה ל-API של אחסון אינטרנט מאפשרת גישה לנתונים מדף המארח שהוחדר אליו הסקריפט של התוכן, ולא מהתוסף.
גישה בקובצי שירות (service worker)
אפשר לגשת לממשקי ה-API IndexedDB ו-Cache Storage ב-service workers. עם זאת, Local Storage ו-Session Storage לא נכללים.
אם אתם צריכים לגשת ל-Local Storage או ל-Session Storage מתוך service worker, אתם יכולים להשתמש במסמך מחוץ למסך.
חלוקה למחיצות
בחלוקה למחיצות, מציגים מפתחות לנתונים מאוחסנים כדי להגביל את הגישה אליהם. בעבר, האחסון היה מבוסס על מפתח לפי מקור.
החל מ-Chrome 115, חלוקה למחיצות באחסון מציגה שינויים באופן ההגדרה של מפתחות החלוקה למחיצות, כדי למנוע סוגים מסוימים של מעקב באתרים שונים. בפועל, המשמעות היא שאם אתר א' מטמיע iframe שמכיל את אתר ב', לא תהיה לאתר ב' גישה לאותו אחסון שהיה לו בדרך כלל כשעוברים אליו ישירות.
כדי לצמצם את ההשפעה של השינוי הזה בתוספים, יש שני חריגים:
- אם דף עם סכימת
chrome-extension://מוטמע באתר כלשהו, חלוקת האחסון למחיצות לא תחול, ולהרחבה תהיה גישה למחיצה ברמה העליונה. - אם דף עם סכימת
chrome-extension://כולל iframe, ולתוסף יש הרשאות מארח לאתר שהוא מטמיע, לאתר הזה תהיה גם גישה למחיצה ברמה העליונה שלו.
קובצי Cookie
קובצי Cookie מאפשרים לאחסן צמדי מפתח/ערך שמשויכים לדומיין ולנתיב ספציפיים. הערך שלהם בתוספים מוגבל, אבל הבנת ההתנהגות שלהם יכולה להיות שימושית אם יש לכם תרחיש שימוש ספציפי או אם צרפתם סקריפט של צד שלישי שמשתמש בהם בהטמעה שלו.
קובצי Cookie מאובטחים
מאפיין הקובץ ה-Cookie Secure נתמך רק בסכימה https://. לכן, דפי chrome-extension:// לא יכולים להגדיר קובצי Cookie עם המאפיין הזה.
המשמעות היא שבדפי תוספים אי אפשר להשתמש במאפייני Cookie אחרים שבהם נדרש המאפיין Secure:
חלוקה למחיצות (partitioning) והתנהגות של SameSite
קובצי Cookie שמוגדרים בדפים chrome-extension:// תמיד משתמשים ב-SameSite=Lax.
לכן, אף פעם אי אפשר לגשת לקובצי Cookie שמוגדרים על ידי תוסף במקור שלו בתוך מסגרות, והחלוקה למחיצות לא רלוונטית.
קובצי Cookie שמשויכים לאתרים של צד שלישי, למשל לאתר של צד שלישי שנטען ב-iframe בדף של תוסף, או לבקשה שנשלחת מדף של תוסף למקור של צד שלישי, מתנהגים כמו קובצי Cookie באינטרנט, למעט בשני מקרים:
- קובצי Cookie של צד שלישי אף פעם לא נחסמים, גם לא במסגרות משנה, אם הדף ברמה העליונה בכרטיסייה נתונה הוא דף
chrome-extension://. - בקשות מתוסף לצד שלישי נחשבות כבקשות מאותו אתר אם לתוסף יש הרשאות מארח לצד השלישי. כלומר,
SameSite=Strictאפשר לשלוח קובצי Cookie. הערה: ההרשאה הזו חלה רק על בקשות לרשת, ולא על גישה דרךdocument.cookieב-JavaScript. היא גם לא חלה אם קובצי Cookie של צד שלישי חסומים.
חשוב לדעת שההגדרות שקשורות לקובצי Cookie של צד שלישי מושפעות מהעבודה על ארגז החול לפרטיות, ושהן משתנות בהתאם ללוח הזמנים שלו.
API browser.cookies מאפשר לשלוט במפתח החלוקה שבו משתמשים בכל method של API. מידע נוסף מופיע במאמרי העזרה של ה-API.