Mã thông báo truy cập giới hạn
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Mã thông báo truy cập bị hạn chế sử dụng giúp bảo vệ khỏi giả mạo yêu cầu và tấn công phát lại, đảm bảo rằng hành động được thực hiện bởi người dùng đã gửi thư. Bạn có thể bảo vệ bằng cách thêm một tham số mã xác minh riêng biệt vào các tham số yêu cầu và xác minh tham số đó khi gọi hành động.
Bạn nên tạo thông số mã thông báo dưới dạng khóa chỉ có thể dùng cho một hành động cụ thể và một người dùng cụ thể. Trước khi thực hiện hành động được yêu cầu, bạn nên kiểm tra xem mã thông báo có hợp lệ và khớp với mã bạn đã tạo cho người dùng hay không. Nếu mã thông báo khớp, thì hành động có thể thực hiện và mã thông báo sẽ trở nên không hợp lệ đối với các yêu cầu trong tương lai.
Mã truy cập phải được gửi đến người dùng dưới dạng một phần của thuộc tính url của HttpActionHandler. Ví dụ: nếu ứng dụng của bạn xử lý các yêu cầu phê duyệt tại http://www.example.com/approve?requestId=123, bạn nên xem xét thêm một thông số accessToken vào ứng dụng và theo dõi các yêu cầu được gửi đến http://www.example.com/approve?requestId=123&accessToken=xyz.
Kết hợp requestId=123 và accessToken=xyz là kết hợp bạn phải tạo trước, đảm bảo rằng accessToken không thể được suy luận từ requestId. Bất kỳ yêu cầu phê duyệt nào với requestId=123 và không có accessToken hoặc với accessToken không bằng xyz đều phải bị từ chối. Sau khi yêu cầu này được thực hiện, mọi yêu cầu trong tương lai có cùng mã nhận dạng và mã truy cập cũng sẽ bị từ chối.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[null,null,["Cập nhật lần gần đây nhất: 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."]]
