סקירה
ה-API והפרוטוקול של Digital Asset Links מאפשרים לאפליקציה או לאתר לפרסם הצהרות ציבוריות וניתנות לאימות לגבי אפליקציות או אתרים אחרים. לדוגמה, אתר יכול להצהיר שהוא משויך לאפליקציה ספציפית ל-Android, או להצהיר שהוא רוצה לשתף את פרטי הכניסה של המשתמש עם אתר אחר.
לפניכם כמה שימושים אפשריים בקישורים לנכסים דיגיטליים:
- אתר א' מצהיר שהקישורים לאתר שלו צריכים להיפתח באפליקציה ייעודית במכשירים ניידים, אם היא מותקנת.
- אתר א' מצהיר שהוא יכול לשתף את פרטי הכניסה של משתמש Chrome עם אתר ב' כדי שהמשתמש לא יצטרך להתחבר לאתר ב' אם הוא מחובר לאתר א'.
- אפליקציה א' מצהירה שהיא יכולה לשתף עם אתר ב' את הגדרות המכשיר, כמו המיקום.
מונחי מפתח
- חשבון משתמש: חשבון המשתמש הוא האפליקציה או האתר שמהם מוגשת ההצהרה. בקישורים לנכסים דיגיטליים, חשבון המשתמש הוא תמיד האפליקציה או האתר שמארחים את רשימת דפי החשבון.
- רשימת דפי חשבון: ההצהרות נכללות ברשימת דפי חשבון שמכילה הצהרה אחת או יותר. רשימת הצהרות היא טקסט ברור ונגישה לכולם, במיקום בשליטת חשבון המשתמש וקשה לזייף אותו או לשנות אותו. הקובץ יכול להיות קובץ עומד או קטע של פריט אחר גדול יותר. לדוגמה, באתר אינטרנט, זהו קובץ שלם. באפליקציה ל-Android, זהו קטע בקובץ המניפסט של האפליקציה. כל אחד יכול לראות ולאמת הצהרות בשיטות לא קנייניות. מידע נוסף זמין במסמכי התיעוד של רשימת דפי החשבון.
- הצהרה: הצהרה היא מבנה JSON מובנה היטב שמורכב מrelation (מה שנאמר בהצהרה, לדוגמה: הפעלת שיתוף פרטי כניסה) וrelation (האתר או האפליקציה שעליהם חל הקשר). לכן, כל הצהרה דומה למשפט, כאשר principal מציין את הקשר לגבי target.
- צרכן דפי חשבון: צרכן של הצהרה מבקש להציג רשימת דפי חשבון מחשבון משתמש, בודק אם קיימת הצהרה כנגד חשבון משתמש מסוים, ואם הוא קיים, יכול לבצע את הפעולה שצוינה. מידע נוסף זמין במסמכי התיעוד בנושא כתיבת התנאים.
דוגמה לשימוש מהיר
דוגמה פשוטה מאוד לאופן שבו האתר www.example.com יכול להשתמש ב-Digital Asset Links כדי לציין שכל קישור לכתובות URL באתר הזה צריך להיפתח באפליקציה ייעודית ולא בדפדפן:
- האתר www.example.com מפרסם רשימת הצהרות בכתובת
https://www.example.com/.well-known/assetlinks.json. אלה
השם והמיקום הרשמיים של רשימת הצהרות באתר. רשימות של דפי חשבון בנק
במיקום אחר או בכל שם אחר לא תקפות לאתר הזה. בדוגמה שלנו, רשימת ההצהרות מורכבת מהצהרה אחת, שמעניקה
לאפליקציית Android שלה את ההרשאה לפתוח קישורים באתר שלה:
[{ "relation": ["delegate_permission/common.handle_all_urls"], "target" : { "namespace": "android_app", "package_name": "com.example.app", "sha256_cert_fingerprints": ["hash_of_app_certificate"] } }]
רשימת הצהרות תומכת במערך של הצהרות בתוך הסימונים [ ], אבל הקובץ לדוגמה שלנו מכיל רק הצהרה אחת.sha256_cert_fingerprints
הוא טביעות האצבע מסוג SHA256 של אישור החתימה של האפליקציה. פרטים נוספים זמינים במסמכי התיעוד בנושא קישורים לאפליקציות ל-Android. - באפליקציה ל-Android שמופיעה בהצהרה שלמעלה יש מסנן Intent שמציין את הסכמה, המארח ודפוס הנתיב של כתובות ה-URL שבהן היא רוצה לטפל: במקרה הזה, https://www.example.com. מסנן Intent כולל מאפיין מיוחד
android:autoVerify
, חדש ב-Android M, שמציין שמערכת Android צריכה לאמת את ההצהרה באתר שמתואר במסנן Intent כשהאפליקציה מותקנת. - משתמש מתקין את האפליקציה. מערכת Android רואה את מסנן Intent עם המאפיין
autoVerify
ובודקת את נוכחות רשימת דפי החשבון באתר שצוין. אם היא קיימת, מערכת Android בודקת אם הקובץ כולל הצהרה שמעניקה טיפול בקישורים לאפליקציה, ומאמתת את האפליקציה מול ההצהרה באמצעות גיבוב (hash) של אישור. אם לא נמצאו שגיאות, מערכת Android תעביר כל Intent של https://www.example.com לאפליקציית example.com. - המשתמש לוחץ על קישור לכתובת https://www.example.com/puPPes במכשיר שלו. הקישור הזה יכול להיות בכל מקום: בדפדפן, בהצעה של Google Search Appliance או בכל מקום אחר. מערכת Android מעבירה את הכוונה לאפליקציית example.com.
- האפליקציה example.com מקבלת את הכוונה ובוחרת לטפל בה, ולפתוח את הדף של הגורים באפליקציה. אם מסיבה כלשהי האפליקציה סירבה לטפל בקישור, או אם האפליקציה לא נמצאת במכשיר, הקישור היה נשלח ל-handler הבא שמוגדר כברירת מחדל ותואם לדפוס הכוונה הזה (בדרך כלל הדפדפן).
שיקולים ומגבלות חשובים:
- הפרוטוקול לא מאמת את חשבון המשתמש שמבצע את ההצהרה, אבל ההצהרה נמצאת במיקום ספציפי שמשויך אליו מאוד, ונמצאת בשליטת חשבון המשתמש.
- הפרוטוקול לא מאמת את היעד שצוין בהצהרה, אבל הוא מספק אמצעי לאימות היעד (לדוגמה, ההצהרה מזהה יעדים של אפליקציות לנייד לפי גיבוב האישור ושם החבילה).
- הפרוטוקול לא מבצע במקור פעולות כלשהן בהצהרה. במקום זאת, הוא מאפשר לחשוף הצהרות, שאפליקציה צורכת הצהרות צריכה לאמת ולאחר מכן להחליט אם לפעול לגביהן ואיך. מערכת Android M מבצעת באופן מקורי את השלבים האלה. לדוגמה, אם האתר מעניק גישה לטיפול בקישורים לאפליקציה ספציפית, מערכת Android בודקת ומאמתת את ההצהרה, מאמתת את אפליקציית היעד ואז מציעה לאפליקציה את האפשרות לטפל בקישור הנתון.
- הפרוטוקול לא מאפשר להצהיר הצהרות בנוגע לשני צדדים שלישיים: כלומר, אתר א' יכול להצהיר הצהרה לגבי אתר ב', אבל אתר א' לא יכול להצהיר הצהרה לגבי הקשר של אתר ב' לאתר ג'. עם זאת, אם אתר ב' סומכים על אתר א', הוא יכול לבדוק באתר א' אם יש הצהרה שמעניקה הרשאה לאתר ג', ולהחליט ליישם את ההצהרה הזו.