限定用途的存取權杖
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
限定存取存取憑證可以防範要求假冒和重播攻擊,確保動作是由使用者寄出。如要獲得保護措施,請在要求參數中加入專屬權杖參數,並在叫用動作時驗證該參數。
符記參數只能用於特定動作以及特定使用者的金鑰。在執行要求的動作之前,您應檢查憑證是否有效,且與您為使用者產生的憑證相符。如果權杖相符,就能執行該動作,而且日後請求將失效。
存取存取憑證應做為 HttpActionHandler 的 url
屬性的一部分傳送給使用者。例如,如果您的應用程式在 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
的核准要求都應遭到拒絕。這項要求處理完畢後,日後也應拒絕所有具有相同 ID 和存取憑證的請求。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-07-25 (世界標準時間)。
[null,null,["上次更新時間:2025-07-25 (世界標準時間)。"],[],[],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."]]