رموز الدخول ذات الاستخدام المحدود
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توفِّر رموز الدخول المحدودة الاستخدام حماية من الطلبات من الانتحال وإعادة تشغيل الهجمات، ما يضمن تنفيذ الإجراء الذي أرسله المستخدم. ويتم تحقيق الحماية عن طريق إضافة معلمة رمز مميز فريدة إلى معلمات الطلب والتحقق منها عند استدعاء الإجراء.
يجب إنشاء معلمة الرمز المميّز كمفتاح لا يمكن استخدامه إلا لإجراء معيّن ولمستخدم محدّد فقط. قبل تنفيذ الإجراء المطلوب، يجب أن تتحقق من صلاحية الرمز المميز وأنه يطابق الرمز الذي أنشأته للمستخدم. وفي حال تطابق الرمز المميّز، يمكن تنفيذ الإجراء ويصبح الرمز المميّز غير صالح للطلبات المستقبلية.
يجب إرسال رموز الدخول إلى المستخدم كجزء من السمة 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 (حسب التوقيت العالمي المتفَّق عليه)
[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."]]