מפתחי אתרים צריכים לתכנן את האפליקציות שלהם באמצעות מודל האבטחה עם רמת האמון הכי נמוכה שאפשר, כמו Progressive Web App (PWA). הגישה הזו ממקסמת את פוטנציאל החשיפה, מצמצמת את התקורה של האבטחה שאתם צריכים לנהל ומציעה את הגמישות הגדולה ביותר למפתחים ולמשתמשים. עם זאת, האינטרנט מתוכנן להיות בטוח כברירת מחדל, ולכן מודל האבטחה השמרני שלו מגביל באופן טבעי את הגישה למערכת ההפעלה ולממשקי API מסוימים רבי עוצמה במכשיר.
אפליקציות אינטרנט מבודדות (IWA) פותרות את הבעיה הזו באמצעות מודל אפליקציות מבודד, מאוגד, עם גרסאות, חתום ומהימן מאוד, שמבוסס על פלטפורמת האינטרנט. עם זאת, לפני שמתקדמים ל-IWA, כדאי לשקול שלב הדרגתי יותר: חיבור של PWA לתוסף ל-Chrome. הטכניקה הזו זמינה בסביבות מנוהלות של ChromeOS – כמו סשנים מנוהלים של משתמשים, סשנים מנוהלים של גלישה כאורח (MGS) או מצב קיוסק – והיא מאפשרת לאפליקציה להשתמש בממשקי API של תוספים ברמה נמוכה יותר באמצעות העברת הודעות מאובטחת. התרשים הבא ממחיש את הגישה ההדרגתית הזו: מתחילים עם אפליקציית אינטרנט רגילה, מוסיפים את היכולות כדי להפוך אותה ל-PWA שניתן להתקינה, ולבסוף בודקים את ה-PWA ואת התוסף ל-Chrome כדי להפעיל ממשקי API נוספים.
אם האפליקציה שלכם דורשת יכולות מתקדמות שלא זמינות גם עם ממשקי API של תוספי Chrome – כמו Controlled Frame או Direct Sockets API – המעבר לאפליקציית אינטרנט מבודדת (IWA) הוא הפתרון הטוב ביותר. עם זאת, למרות שאפליקציות אינטרנט מתקדמות מאפשרות להשתמש בתכונות חדשות ומתקדמות באינטרנט, יכול להיות שעדיין תצטרכו ממשקי API ספציפיים ברמת המכשיר שזמינים רק בתוספי Chrome, כמו chrome.runtime.restart() להפעלה מחדש של מכשיר ChromeOS במצב קיוסק.
למזלכם, אתם יכולים לחבר IWA לתוסף Chrome באותה דרך שבה מחברים PWA. הטכניקה הזו מוסברת בשלבים הבאים.
הטמעה שלב אחר שלב
פריסת התוסף הנלווה
הפריסה של התוספים מתבצעת דרך מסוף Admin של Chrome. בהתאם לסביבת היעד, מגדירים את ההגדרה הזו בקטע המתאים (לדוגמה, עוברים אל מכשירים > Chrome > אפליקציות ותוספים > קיוסקים למצב קיוסק, או לכרטיסיות המתאימות של משתמשים ודפדפנים או סשנים מנוהלים של גלישה כאורח). אפשר לארח את התוסף בקישור שנגיש לכולם או לארח אותו ישירות בחנות האינטרנט של Chrome. הוראות מפורטות יותר לניהול תוספים מופיעות במאמרי העזרה הרשמיים.
הטמעה של העברת הודעות
הגדרת התוסף
כדי לקבל הודעות מאפליקציית האינטרנט ולענות עליהן, צריך לחשוף סקריפט ברקע שמקשיב להודעות שמגיעות מהלקוח (אפליקציית האינטרנט) ואז מעביר את הבקשות האלה לקריאה ל-API תואמת. בדוגמה הבאה, בקשה מועברת דרך שרת proxy להפעלה מחדש של מכשיר ChromeOS כשאפליקציית האינטרנט שולחת אובייקט הודעה מותאם אישית שמכיל methodName עם הערך callRestart.
Background.js
// message handler - extension code
chrome.runtime.onMessageExternal.addListener(function (request, sender, sendResponse) {
if (request.methodName == 'callRestart') {
chrome.runtime.restart();
}
});
אפשר להגדיר את קובץ המניפסט של התוסף כך שיאפשר קריאות לפונקציות חיצוניות לתוסף באמצעות המפתח externally_connectable, שמציין לאילו אתרים ותוספים מותר לקרוא לשיטות בתוסף. מידע נוסף על תוספים ל-Chrome ומניפסט v3 זמין במסמכי התיעוד הרשמיים.
אם אתם מתחברים מאפליקציית אינטרנט מתקדמת (PWA), תציינו את דומיין ה-HTTPS הרגיל שבו מתארחת האפליקציה במערך התאמות. לפניכם דוגמה למניפסט שהוגדר ל-PWA שפועל במצב קיוסק:
Manifest.json
{
"manifest_version": 3,
"name": "Restart your kiosk app",
"version": "1.0",
"description": "This restarts your ChromeOS device.",
"background": {
"service_worker": "background.js"
},
"externally_connectable": {
"accepts_tls_channel_id": false,
"matches": [
"*://developer.chrome.com/*"
]
}
}
אם אתם מתחברים מאפליקציית אינטרנט מבודדת (IWA), המנגנון זהה לחלוטין, אבל סכמת כתובת ה-URL משתנה. אפליקציות IWA ארוזות בצורה מאובטחת והן לא פועלות בשרתי אינטרנט רגילים, ולכן הן משתמשות בפרוטוקול משלהן. צריך להוסיף את המקור של ה-IWA באמצעות הסכימה isolated-app://.
Manifest.json
{
"manifest_version": 3,
"name": "IWA Companion Extension",
"version": "1.1",
"description": "Companion extension for the IWA",
"background": {
"service_worker": "/scripts/background.js"
},
"externally_connectable": {
"matches": [
"isolated-app://*/*"
]
}
}
זו הכמות המינימלית של קוד שנדרשת בתוסף כדי להאזין להודעות מאפליקציית PWA או IWA.
הגדרה של PWA ו-IWA
כדי להתקשר לתוסף מאפליקציית אינטרנט, צריך לדעת את מזהה התוסף הסטטי.
אפשר למצוא את המזהה הזה בדף chrome://extensions שמוצג כשמתקינים את התוסף ל-Chrome, או בחנות האינטרנט של Chrome אחרי שהתוסף הועלה. כך אפליקציית האינטרנט יכולה לציין את התוסף המדויק שאיתו היא רוצה לתקשר. אחרי זה, מתקשרים אל
chrome.runtime.sendMessage
ומעבירים את מזהה התוסף עם הודעה לשליחה לתוסף.
const STATIC_EXTENSION_ID = 'abcdefghijklmnopqrstuvwxyz';
// found from chrome extensions page of chrome web store.
const callExtensionAPI = function (method) {
chrome.runtime.sendMessage(STATIC_EXTENSION_ID, {
methodName: method,
});
};
callExtensionAPI('callRestart');
מידע נוסף על קישור אפליקציות אינטרנט לתוספים להעברת הודעות זמין במאמרי העזרה בנושא תוספים.
הדגמה (דמו)
כדי לראות את ההטמעה הזו בפעולה, אפשר לעיין במאגר IWA Kitchen Sink.
הפרויקט הזה משמש כסביבת בדיקה מקיפה למגוון יכולות של IWA, עם הדגמות של ממשקי API שדורשים רמת אמון גבוהה, כמו Direct Sockets ו-Controlled Frame.
הוא גם מספק דוגמה מלאה ופעילה של החיבור בין IWA לתוסף Chrome. המאגר כולל תוסף לדוגמה וממשק אינטרנט ייעודי שמדגים איך להשתמש בהעברת הודעות מאובטחת כדי להפעיל שיטות שזמינות רק לתוסף. לדוגמה, אתם יכולים לבדוק אם אפשר לאחזר את פרטי הפרופיל של המשתמש באמצעות chrome.identity.getProfileUserInfo() API ישירות מאפליקציית האינטרנט המבודדת.
סיכום
חיבור אפליקציות האינטרנט שלכם לתוסף Chrome מאפשר לכם להגיע בצורה בטוחה ומתקדמת ליכולות של המכשיר שדומות לאפליקציות מקומיות. כשמתכננים את הארכיטקטורה של האפליקציה, חשוב לזכור את הנקודות העיקריות הבאות:
- מתחילים עם האינטרנט: כדאי להגדיר כברירת מחדל אפליקציית PWA כדי להגיע למספר הגדול ביותר של משתמשים ולצמצם את העומס על האבטחה.
- מגשרים על הפער באמצעות תוספים: כדי להשתמש בתכונות משולבות עמוקות ברמת מערכת ההפעלה (כמו הפעלה מחדש של המכשיר במצב קיוסק), צריך לפרוס תוסף Chrome נלווה ולחבר אותו לאפליקציה באמצעות העברת הודעות מאובטחת.
- שדרוג לאפליקציות אינטרנט מבודדות רק אם צריך: כדאי להשתמש באפליקציות אינטרנט מבודדות כשנדרשים ממשקי API עם רמת אמון גבוהה, כמו Direct Sockets, Controlled Frame או כל אחד מממשקי ה-API האחרים שזמינים רק באפליקציות אינטרנט מבודדות.