שינוי של בקשות רשת ב-Manifest V3
ב-Manifest V3 יש שינוי באופן שבו התוספים מטפלים בשינוי של בקשות רשת. במקום ליירט בקשות רשת ולשנות אותן בסביבת זמן הריצה באמצעות chrome.webRequest, התוסף מציין כללים שמתארים פעולות לביצוע כשמתקיימים קבוצת תנאים נתונה. אפשר לעשות זאת באמצעות Declarative Net Request API.
יש הבדלים משמעותיים בין Web Request API לבין ממשקי ה-API של בקשות רשת דקלרטיביות. במקום להחליף קריאה לפונקציה אחת בקריאה אחרת, צריך לכתוב מחדש את הקוד בהתאם לתרחישי שימוש. בקטע הזה נסביר איך עושים את זה.
ב-Manifest V2, חסימה של בקשות אינטרנט עלולה לפגוע באופן משמעותי בביצועים של התוספים ובביצועים של הדפים שבהם הם פועלים. מרחב השמות webRequest תומך בתשעה אירועים שעשויים לחסום, וכל אחד מהם יכול לקבל מספר בלתי מוגבל של פונקציות טיפול באירועים. גרוע מכך, כל דף אינטרנט עשוי להיות חסום על ידי כמה תוספים, וההרשאות הנדרשות לכך פולשניות. כדי למנוע את הבעיה הזו, מניפסט V3 מחליף קריאות חזרה (callbacks) בכללים דמוקרטיביים.
זהו הקטע השני מתוך שלושה שמתארים את השינויים הנדרשים בקוד שאינו חלק מ-service worker של התוסף. במאמר הזה מוסבר איך להמיר בקשות חסימה לאינטרנט, שבהן נעשה שימוש במניפסט V2, לבקשות רשת מוצהרניות, שבהן נעשה שימוש במניפסט V3. בשני החלקים האחרים מוסבר על עדכון הקוד הנדרש להעברה ל-Manifest V3 ועל שיפור האבטחה.
עדכון ההרשאות
מבצעים את השינויים הבאים בשדה "permissions" ב-manifest.json.
- אם כבר אין צורך לעקוב אחרי בקשות רשת, מסירים את ההרשאה
"webRequest". - מעבירים את התבניות להתאמה מ-
"permissions"אל"host_permissions".
תצטרכו להוסיף הרשאות נוספות, בהתאם לתרחיש השימוש שלכם. ההרשאות האלה מתוארות יחד עם תרחיש לדוגמה שבו הן נתמכות.
יצירת כללים דקלרטיביים לבקשות רשת
כדי ליצור כללי בקשה רשמיים של רשת, צריך להוסיף אובייקט "declarative_net_request" ל-manifest.json. הבלוק "declarative_net_request" מכיל מערך של אובייקטים מסוג "rule_resource" שמפנים לקובץ כללים. קובץ הכללים מכיל מערך של אובייקטים שמציינים פעולה ואת התנאים שבהם הפעולות האלה מופעלות.
תרחישים נפוצים לדוגמה
בקטעים הבאים מתוארים תרחישים נפוצים לשימוש בבקשות רשת מוצהר. ההוראות שבהמשך הן רק סקירה כללית קצרה. מידע נוסף על כל המידע שמופיע כאן מפורט במאמר 'הפניית API' בקטע chrome.declarativeNetRequest
חסימה של כתובת URL יחידה
תרחיש לדוגמה נפוץ ב-Manifest V2 היה חסימה של בקשות אינטרנט באמצעות האירוע onBeforeRequest בסקריפט הרקע.
chrome.webRequest.onBeforeRequest.addListener((e) => {
return { cancel: true };
}, { urls: ["https://www.example.com/*"] }, ["blocking"]);
לגרסה Manifest V3, יוצרים כלל declarativeNetRequest חדש באמצעות סוג הפעולה "block". שימו לב לאובייקט "condition" בכלל לדוגמה. הערך של "urlFilter" מחליף את האפשרות urls שהועברה למאזין webRequest. מערך "resourceTypes" מציין את קטגוריית המשאבים שרוצים לחסום. בדוגמה הזו חסום רק דף ה-HTML הראשי, אבל אפשר, למשל, לחסום רק גופנים.
[
{
"id" : 1,
"priority": 1,
"action" : { "type" : "block" },
"condition" : {
"urlFilter" : "||example.com",
"resourceTypes" : ["main_frame"]
}
}
]
כדי שהפעולה הזו תפעל, תצטרכו לעדכן את ההרשאות של התוסף. ב-manifest.json מחליפים את ההרשאה "webRequestBlocking" בהרשאה "declarativeNetRequest". שימו לב שכתובת ה-URL הוסרה מהשדה "permissions" כי חסימת תוכן לא דורשת הרשאות מארח. כפי שמוצג למעלה, קובץ הכללים מציין את המארח או המארחים שעליהם חלה בקשת רשת דקלרטיבית.
כדי לנסות את זה, הקוד שבהמשך זמין במאגר הדוגמאות שלנו.
"permissions": [
"webRequestBlocking",
"https://*.example.com/*"
]
"permissions": [
"declarativeNetRequest",
]
הפניה לכמה כתובות URL
תרחיש לדוגמה נוסף ב-Manifest V2 היה שימוש באירוע BeforeRequest כדי להפנות אוטומטית בקשות אינטרנט.
chrome.webRequest.onBeforeRequest.addListener((e) => {
console.log(e);
return { redirectUrl: "https://developer.chrome.com/docs/extensions/mv3/intro/" };
}, {
urls: [
"https://developer.chrome.com/docs/extensions/mv2/"
]
},
["blocking"]
);
ב-Manifest V3, משתמשים בסוג הפעולה "redirect". כמו קודם, הערך "urlFilter" מחליף את האפשרות url שהועברה למאזין webRequest. שימו לב שבדוגמה הזו, האובייקט "action" בקובץ הכללים מכיל שדה "redirect" שמכיל את כתובת ה-URL להחזרה במקום את כתובת ה-URL שעברה סינון.
[
{
"id" : 1,
"priority": 1,
"action": {
"type": "redirect",
"redirect": { "url": "https://developer.chrome.com/docs/extensions/mv3/intro/" }
},
"condition": {
"urlFilter": "https://developer.chrome.com/docs/extensions/mv2/",
"resourceTypes": ["main_frame"]
}
}
בתרחיש הזה נדרשים גם שינויים בהרשאות של התוסף. כמו קודם, מחליפים את ההרשאה "webRequestBlocking" בהרשאה "declarativeNetRequest". כתובות ה-URL מועברות שוב מהקובץ manifest.json לקובץ כללים. שימו לב: כדי לבצע הפניה אוטומטית, נדרשת גם ההרשאה "declarativeNetRequestWithHostAccess" בנוסף להרשאת המארח.
כדי לנסות את זה, הקוד הבא זמין במאגר הדוגמאות שלנו.
"permissions": [
"webRequestBlocking",
"https://developer.chrome.com/docs/extensions/*",
"https://developer.chrome.com/docs/extensions/reference"
]
"permissions": [
"declarativeNetRequestWithHostAccess"
],
"host_permissions": [
"https://developer.chrome.com/*"
]
חסימת קובצי cookie
כדי לחסום קובצי cookie ב-Manifest V2, צריך ליירט את כותרות הבקשות מהאינטרנט לפני שהן נשלחות ולהסיר כותרת ספציפית.
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
removeHeader(details.requestHeaders, 'cookie');
return {requestHeaders: details.requestHeaders};
},
// filters
{urls: ['https://*/*', 'http://*/*']},
// extraInfoSpec
['blocking', 'requestHeaders', 'extraHeaders']);
גם ב-Manifest V3 אפשר לעשות זאת באמצעות כלל בקובץ כללים. הפעם סוג הפעולה הוא "modifyHeaders". הקובץ מקבל מערך של אובייקטים מסוג "requestHeaders" שמציינים את הכותרות שרוצים לשנות ואת אופן השינוי שלהן. שימו לב שהאובייקט "condition" מכיל רק מערך "resourceTypes". הוא תומך באותם ערכים כמו בדוגמאות הקודמות.
כדי לנסות את זה, הקוד שבהמשך זמין במאגר הדוגמאות שלנו.
[
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [
{ "header": "cookie", "operation": "remove" }
]
},
"condition": {
"urlFilter": "|*?no-cookies=1",
"resourceTypes": ["main_frame"]
}
}
]
בתרחיש הזה נדרשים גם שינויים בהרשאות של התוסף. כמו קודם, מחליפים את ההרשאה "webRequestBlocking" בהרשאה "declarativeNetRequest".
"permissions": [
"webRequest",
"webRequestBlocking",
"https://*/*",
"http://*/*"
],
"permissions": [
"declarativeNetRequest",
],
"host_permissions": [
""
]