כתובות URL חתומות

בדף הזה אפשר לקרוא סקירה כללית של כתובות URL חתומות, שמשתמשות בחתימות כדי לתת גישה מוגבלת בזמן למשאב ספציפי של Cloud Storage. כל מי שיש לו את כתובת ה-URL החתומה יכול להשתמש בה בזמן שהיא פעילה, גם אם יש לו חשבון תקין וגם אם לא. למידע נוסף על יצירת כתובת URL חתומה, ראו תהליך חתימת V4 באמצעות כלים של Cloud Storage ותהליך חתימת V4 באמצעות תוכנית משלכם. למידע על דרכים אחרות לשליטה בגישה לקטגוריות ולאובייקטים, ראו סקירה כללית על בקרת גישה.

סקירה כללית

כתובת URL חתומה היא כתובת URL עם הרשאה וזמן מוגבלים לשליחת בקשה. כתובות URL חתומות מכילות פרטי אימות, כולל חתימה, במחרוזת השאילתה, ומאפשרות למשתמשים ללא הרשאות לבצע פעולות מסוימות במשאב.

  • כשיוצרים כתובת URL חתומה, צריך לציין חשבון שיש לו את ההרשאה הדרושה כדי לשלוח את הבקשה מכתובת ה-URL החתומה.

    • ברוב המקרים, החשבון הוא חשבון שירות.

    • במקרים שבהם אתם יוצרים תוכנה משלכם כדי ליצור כתובות URL חתומות, אפשר להשתמש בחשבון משתמש אם משויך אליו מפתח HMAC.

אחרי שיוצרים כתובת URL חתומה, כל מי שיש לו את הכתובת יכול להשתמש בכתובת ה-URL החתומה כדי לבצע פעולות מסוימות, כמו קריאת אובייקט, בפרק זמן מוגדר.

מתי צריך להשתמש בכתובת URL חתומה?

בתרחישים מסוימים, יכול להיות שלא תרצו לדרוש מהמשתמשים חשבון משלהם כדי שיוכלו לגשת ל-Cloud Storage, אבל תרצו לשלוט בגישה באמצעות הלוגיקה הספציפית לאפליקציה. הדרך הטיפוסית לטפל בתרחיש לדוגמה הזה היא לספק למשתמש כתובת URL חתומה, שנותנת למשתמש גישה לקריאה, לכתיבה או למחיקה של משאב למשך זמן מוגבל. כשיוצרים כתובת URL חתומה, מציינים מועד תפוגה. כל מי שיודע את כתובת ה-URL יכול לגשת למשאב עד למועד התפוגה של כתובת ה-URL, או עד שהמפתח לחתימה על כתובת ה-URL מוחלף.

השימושים הנפוצים ביותר של כתובות URL חתומות הם העלאות והורדות, כי בבקשות כאלה נתוני אובייקטים מועברים בין מגישי הבקשות לבין Cloud Storage. ברוב המקרים האחרים, כמו העתקת אובייקטים, כתיבת אובייקטים, מחיקת אובייקטים או עריכת מטא-נתונים, יצירת כתובת URL חתומה ושליחה של כתובת ה-URL החתומה למישהו כדי לאפשר את השימוש בה היא שלב נוסף מיותר. במקום זאת, כדאי להשתמש בתכנון שבו הישות שאחראית ליצירת כתובת ה-URL החתומה שולחת את הבקשה הרצויה ישירות ל-Cloud Storage.

דוגמה לכתובת URL חתומה

לפניכם דוגמה לכתובת URL חתומה שנוצרה באמצעות תהליך חתימת V4 באמצעות אימות של חשבון שירות:

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=
GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com
%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T18
1309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f16
9edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa849
6def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dc
c1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c2058
0e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a
66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823
a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b13344703
2ea7abedc098d2eb14a7

כתובת ה-URL החתומה הזו מספקת גישה לקריאת האובייקט cat.jpeg בקטגוריה example-bucket. הפרמטרים של השאילתה שהופכים את כתובת ה-URL הזו לכתובת URL חתומה הם:

  • ‫X-Goog-Algorithm: האלגוריתם שמשמש לחתימה של כתובת ה-URL.

  • ‫X-Goog-Credential: מידע על פרטי הכניסה שמשמשים ליצירת כתובת ה-URL החתומה.

  • ‫X-Goog-Date: התאריך והשעה שבהם אפשר להתחיל את השימוש בכתובת ה-URL החתומה בפורמט הבסיסי YYYYMMDD'T'HHMMSS'Z' של ISO 8601.

  • ‫X-Goog-Expires: משך הזמן שכתובת ה-URL החתומה נשארה בתוקף, שנמדד בשניות מהערך ב-X-Goog-Date. בדוגמה הזו, התוקף של כתובת ה-URL החתומה יפוג בתוך 15 דקות. ערך התפוגה הארוך ביותר הוא 604,800 שניות (7 ימים).

  • ‫X-Goog-SignedHeaders: כותרות שצריך לכלול כחלק מכל בקשה המשתמשת בכתובת ה-URL החתומה.

  • ‫X-Goog-Signature: מחרוזת האימות שמאפשרת לבקשות שמשתמשות בכתובת ה-URL החתומה הזו לגשת אל cat.jpeg.

שימוש בכתובות URL חתומות בהעלאות שניתן להמשיך

בדרך כלל, אין צורך ליצור כתובות URL חתומות עבור העלאות שניתן להמשיך, כי אחרי הבקשה להתחלת ההעלאה, בקשות ה-PUT הבאות להעלאת נתוני האובייקט משתמשות ב-URI של סשן, שמשמש כאסימון אימות. כלומר, בקשות PUT לא משתמשות בכתובות URL חתומות.

אפשר ליצור כתובת URL חתומה ולהשתמש בה לבקשת POST הראשונית כדי להתחיל את ההעלאה, אבל ברוב המקרים השרת יכול להתחיל את ההעלאה שניתן להמשיך במקום זאת. לאחר מכן השרת שולח את ה-URI של הסשן ללקוח כדי לבצע את ההעלאה. כך נמנעים מהמורכבות של יצירת כתובת URL חתומה על ידי השרת, וגם מהמורכבות של טיפול בכתובת ה-URL החתומה על ידי הלקוח והפעלת העלאה שניתן להמשיך.

בדומה לכתובות URL חתומות, כל מי שיש לו את ה-URI של הסשן יכול להשתמש בו כדי להעלות נתונים. חשוב לשדר את ה-URI של הסשן ב-HTTPS כשנותנים אותו ללקוח.

שיקולים בנוגע לכתובות URL חתומות

כשעובדים עם כתובות URL חתומות, חשוב לזכור את הדברים הבאים:

  • אפשר להשתמש בכתובות URL חתומות כדי לגשת למשאבי Cloud Storage רק דרך נקודות קצה של API בפורמט XML.

  • כשמציינים את פרטי הכניסה, מומלץ לזהות את חשבון השירות באמצעות כתובת האימייל שלו, אבל אפשר גם להשתמש במזהה של חשבון השירות.

בקשות רשמיות (קנוניות)

כתובות URL חתומות משתמשות בבקשות קנוניות כחלק מהמידע שמקודד בפרמטר X-Goog-Signature של מחרוזת השאילתה. כשמבצעים יצירה של כתובת URL חתומה באמצעות הכלים של Cloud Storage, הבקשה הקנונית הנדרשת נוצרת ומשולבת באופן אוטומטי. עם זאת, כשמבצעים יצירה של כתובת URL חתומה באמצעות תוכנה משלכם, עליכם להגדיר בעצמכם את הבקשה הקנונית ולהשתמש בה כדי לבצע יצירת חתימה.

היקף פרטי הכניסה

היקף פרטי הכניסה מופיע גם במחרוזת לחתימה וגם בפרמטר X-Goog-Credential של מחרוזת השאילתה.

המאמרים הבאים