אסימוני גישה לשימוש מוגבל
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
אסימוני גישה לשימוש מוגבל מספקים הגנה מפני זיוף בקשות ומתקפות הפעלה מחדש, כדי לוודא שהפעולה אכן נשלחה על ידי המשתמש שאליו נשלחה ההודעה. כדי להגן על החשבון, מוסיפים פרמטר אסימון ייחודי לפרמטרים של הבקשה ומאמתים אותו כשמתבצעת פעולה.
את אסימון האסימון יש ליצור כמפתח, שיכול לשמש רק לפעולה ספציפית ולמשתמש ספציפי. לפני ביצוע הפעולה המבוקשת, יש לוודא שהאסימון תקף ותואם לאסימון שיצרת עבור המשתמש. אם האסימון תואם, ניתן לבצע את הפעולה ואסימון לא יהיה תקף לבקשות עתידיות.
יש לשלוח אסימוני גישה למשתמש כחלק מהנכס url ב-HttpActionHandler. לדוגמה, אם הבקשה שלך מטפלת בבקשות אישור בכתובת http://www.example.com/approve?requestId=123, מומלץ לכלול בפרמטר accessToken פרמטר נוסף ולהאזין לבקשות שנשלחות אל http://www.example.com/approve?requestId=123&accessToken=xyz.
השילוב requestId=123 וaccessToken=xyz הם השילוב שצריך ליצור מראש, כדי שניתן יהיה להסיק את accessToken מהrequestId. כל בקשת אישור עם requestId=123 וללא accessToken או עם accessToken לא שווה ל-xyz תידחה. אחרי שהבקשה הזו עוברת, כל בקשה עתידית עם אותו מזהה ואסימון גישה תידחה גם היא.
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-25 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-25 (שעון UTC)."],[],[],null,["# Limited Use Access Tokens\n\nLimited-Use Access Tokens provide protection from request spoofing and [replay attacks](http://en.wikipedia.org/wiki/Replay_attack), ensuring that the action is performed by the user the message was sent to. Protection is achieved by adding a unique token parameter to the request parameters and verifying it when the action is invoked.\n\nThe token parameter should be generated as a key that can only be used for a specific action and a specific user. Before the requested action is performed, you should check that the token is valid and matches the one you generated for the user. If the token matches then the action can be performed and the token becomes invalid for future requests.\n\nAccess tokens should be sent to the user as part of the `url` property of the [HttpActionHandler](/workspace/gmail/markup/reference/types/HttpActionHandler). For instance, if your application handles approval requests at `http://www.example.com/approve?requestId=123`, you should consider including an additional `accessToken` parameter to it and listen to requests sent to `http://www.example.com/approve?requestId=123&accessToken=xyz`.\n\nThe combination `requestId=123` and `accessToken=xyz` is the one that you have to generate in advance, making sure that the `accessToken` cannot be deduced from the `requestId`. Any approval request with `requestId=123` and no `accessToken` or with a `accessToken` not equal to `xyz` should be rejected. Once this request gets through, any future request with the same id and access token should be rejected too."]]
