استفاده محدود از نشانه های دسترسی
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
توکنهای دسترسی با استفاده محدود از جعل درخواست و حملات تکراری محافظت میکنند و اطمینان میدهند که این عمل توسط کاربری که پیام به آن ارسال شده انجام میشود. حفاظت با افزودن یک پارامتر رمز منحصر به فرد به پارامترهای درخواست و تأیید آن هنگام فراخوانی عمل به دست می آید.
پارامتر توکن باید به عنوان کلیدی تولید شود که فقط برای یک اقدام خاص و یک کاربر خاص قابل استفاده باشد. قبل از انجام عمل درخواستی، باید بررسی کنید که نشانه معتبر است و با آنچه که برای کاربر ایجاد کرده اید مطابقت دارد. اگر توکن مطابقت داشته باشد، این عمل می تواند انجام شود و نشانه برای درخواست های بعدی نامعتبر می شود.
نشانه های دسترسی باید به عنوان بخشی از ویژگی 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 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده 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."]]