المصادقة والتفويض في بروتوكول بيانات Google

تحذير: تتعلق هذه الصفحة بواجهات برمجة التطبيقات القديمة من Google، وهي واجهات برمجة التطبيقات لبيانات Google؛ وهي مرتبطة فقط بواجهات برمجة التطبيقات المدرجة في دليل Google Data APIs، والتي تم استبدال العديد منها بواجهات برمجة تطبيقات أحدث. للحصول على معلومات حول واجهة برمجة تطبيقات جديدة، اطلع على وثائق واجهة برمجة التطبيقات الجديدة. للحصول على معلومات حول تفويض الطلبات باستخدام واجهة برمجة تطبيقات أحدث، اطلع على مصادقة حسابات Google وتفويضها.

غالبًا ما تتطلب تطبيقات الجهات الخارجية الدخول المحدود إلى حساب المستخدم على Google لأنواع معينة من النشاط. لضمان عدم إساءة استخدام بيانات المستخدم، يجب أن يوافق صاحب الحساب على جميع طلبات الوصول. يتضمن التحكم في الدخول مكونين، وهما المصادقة والتفويض.

تتيح خدمات المصادقة للمستخدمين تسجيل الدخول إلى تطبيقك باستخدام حساب Google.

تتيح خدمات التفويض للمستخدمين تزويد تطبيقك بإمكانية الدخول إلى البيانات التي خزنوها في تطبيقات Google. تتعامل Google مع الخصوصية بجدية، ويجب أن يسمح المستخدم بأي تطبيق يتطلب الوصول إلى بيانات المستخدم.

وغالبًا ما تتم الإشارة إلى خدمات المصادقة والتفويض بشكل جماعي باسم auth.

تتيح المصادقة والتصريح لـ Google APIs للتطبيقات التابعة لجهات خارجية الحصول على إمكانية دخول محدودة إلى حساب Google للمستخدم لأنواع معينة من الأنشطة. يقدم هذا المستند آليات المصادقة المتوفرة ويشرح ما تقدمه كل أداة لتطبيقك.

  • يوفر تسجيل الدخول بحساب Google طريقة بسيطة للسماح للأشخاص باستخدام بيانات اعتماد Google لتسجيل الدخول إلى موقعك. حيث يتضمن مجموعة من الأدوات التي يسهل دمجها عبر الأجهزة المختلفة.
  • يعتبر OAuth 2.0 بروتوكول مصادقة لجميع واجهات برمجة تطبيقات Google. يعتمد OAuth 2.0 على طبقة المقابس الآمنة (SSL) للأمان بدلاً من مطالبة التطبيق بإجراء توقيع مشفر مباشرة. يتيح هذا البروتوكول لتطبيقك طلب الدخول إلى البيانات المقترنة بحساب Google للمستخدم.
  • يعمل تسجيل الدخول باستخدام OAuth 2.0 (OpenID Connect) على مصادقة المستخدمين من خلال مطالبتهم بتسجيل الدخول باستخدام حساباتهم على Google. وهذا بديل عن OpenID، وعلى مستخدمي OpenID التخطيط للترحيل إلى "تسجيل الدخول باستخدام OAuth 2.0".

إذا كان تطبيقك هو أداة (للاستخدام في iGoogle أو حاويات OpenSocial الأخرى)، فراجع القسم مصادقة الأدوات.

ملاحظة: يهدف هذا المستند إلى تقديم نظرة عامة عن كل طريقة مصادقة. للحصول على معلومات تفصيلية حول كل طريقة، اطلع على وثائق واجهات برمجة تطبيقات مصادقة حساب Google الكاملة.

اطلع أيضًا على مجموعة واجهة برمجة تطبيقات حسابات Google للمناقشة حول استخدام واجهات برمجة تطبيقات حسابات Google.

OAuth - تفويض للويب والتطبيقات المثبتة

تسمح العديد من خدمات Google بوصول الجهات الخارجية إلى البيانات التي ينشئها المستخدم، مثل بيانات "تقويم Google" أو "مستندات Google"، طالما كان الوصول إليها مُصرّحًا به. تتيح هذه الميزة للمستخدمين مشاركة البيانات وتبادلها بين تطبيقات Google وتطبيقات الجهات الخارجية لأغراض متنوعة.

يتوافق Google مع إصدارين من OAuth للحصول على إذن دخول مُعتمَد إلى بيانات المستخدم على Google وهما: OAuth 1.0 وOAuth 2.0، وكلاهما يقدم إمكانية الدخول إلى كل من تطبيقات الويب والتطبيقات المثبتة.

OAuth 2.0 للويب والتطبيقات المثبتة

يمكن لتطبيقات الويب أو التطبيقات المثبتة استخدام بروتوكول OAuth 2.0 الجديد والمبسّط للسماح بالوصول إلى البيانات المرتبطة بحساب Google. للحصول على تفاصيل وأمثلة على كيفية تنفيذ بروتوكول OAuth 2.0 مع Google، يمكنك الاطّلاع على مستنداتنا حول OAuth 2.0.

OAuth 1.0 لتطبيقات الويب

يمكن لتطبيقات الويب التي تحتاج إلى دخول مصرح به إلى البيانات المقترنة بحساب Google أو بحساب Google Apps استخدام تنفيذ واجهة برمجة تطبيقات OAuth. للحصول على معلومات كاملة حول تنفيذ بروتوكول OAuth للتطبيقات المستندة إلى الويب، بما في ذلك الأمثلة، راجع دليل OAuth لتطبيقات الويب، أو اطلع على نظرة عامة في هذا المستند.

OAuth 1.0 للتطبيقات المثبّتة

يمكن للتطبيقات المثبتة على أجهزة كمبيوتر المستخدمين وأجهزة الجوّال استخدام OAuth لتفويض الوصول إلى البيانات المرتبطة بحساب Google. للحصول على معلومات كاملة حول تنفيذ بروتوكول OAuth للتطبيقات المثبتة، اطلع على دليل OAuth للتطبيقات المثبتة، أو اطلع على نظرة عامة في هذا المستند.

استخدام OAuth مع تطبيقات الويب

تدعم جميع واجهات برمجة التطبيقات لبيانات Google بروتوكول OAuth وهو معيار مفتوح لتفويض استخدام البيانات في تطبيقات الويب. يجب على جميع تطبيقات الويب التي ترسل طلبات OAuth تحميل شهادة أمان والتسجيل في Google. راجع التسجيل للتطبيقات المستندة إلى الويب لمزيد من المعلومات.

توفر مكتبات عميل Google Data APIs طرقًا لمساعدتك في استخدام OAuth في تطبيق الويب. وعلى وجه التحديد، هناك طرق لإنشاء رمز الطلب المميز وتفويض الرمز المميز للطلب وتبادل رمز الطلب المميز مع رمز الدخول. تعالج المكتبات أيضًا خوارزميات التوقيع الضرورية عند تقديم طلبات إلى خدمة بيانات Google. للحصول على أمثلة شاملة عن كيفية استخدام بروتوكول OAuth مع مكتبات برامج "واجهة برمجة التطبيقات لبيانات Google"، يُرجى الاطِّلاع على استخدام OAuth مع مكتبات برامج "واجهات برمجة التطبيقات لبيانات Google".

عملية تفويض OAuth

تتضمن عملية تفويض OAuth سلسلة من التفاعلات بين تطبيق الويب وخوادم تفويض Google والمستخدم.

على المستوى الأساسي، تتم العملية على النحو التالي:

  1. يطلب تطبيقك الوصول ويحصل على رمز طلب غير مصرح به من خادم تفويض Google.
  2. تطلب Google من المستخدم أن يمنحك إمكانية الوصول إلى البيانات المطلوبة.
  3. يحصل تطبيقك على رمز مميّز لطلب مُعتمَد من خادم التفويض.
  4. يمكنك استبدال رمز الطلب المصرح به برمز دخول.
  5. يمكنك استخدام رمز الدخول المميز لطلب البيانات من خوادم الوصول إلى خدمات Google.

عندما يطلب تطبيقك في البداية الوصول إلى بيانات المستخدم، يصدر Google رمز طلب مميز غير مصرح به إلى تطبيقك.

إذا لم يسبق للمستخدم تسجيل الدخول، ستطلب من المستخدم تسجيل الدخول. يعرض Google بعد ذلك صفحة تفويض تتيح للمستخدم معرفة بيانات خدمة Google التي يطلب تطبيقك الوصول إليها.

إذا وافق المستخدم على طلب الوصول إلى تطبيقك، تصدر Google رمزًا مميزًا للطلب مُصرَّح به. ويكون رمز كل طلب مميز صالحًا لمدة ساعة واحدة فقط. لا يمكن استبدال سوى رمز الطلب المميز برمز دخول، ولا يمكن إجراء هذا التبادل سوى مرة واحدة فقط لكل رمز مميز المميز للطلب.

حسب الإعدادات التلقائية، تكون رموز الدخول طويلة الأجل. ويكون كل رمز دخول مخصصًا لحساب المستخدم المحدد في طلب التفويض الأصلي، كما يمنح حق الدخول إلى الخدمات المحددة في هذا الطلب فقط. يجب أن يخزن التطبيق رمز الدخول بشكل آمن، نظرًا لأنه مطلوب لجميع عمليات الدخول إلى بيانات المستخدم.

الاستعداد لاستخدام OAuth

قبل أن تتمكن من إعداد تطبيقك لاستخدام خدمة تفويض Google مع OAuth، يجب إكمال المهام التالية.

تحديد ما إذا كان سيتم تسجيل تطبيق الويب أم لا

لتزويد المستخدمين بضمانات إضافية لأمان بياناتهم، يمكنك اختيار تسجيل تطبيق الويب لدى Google وتوقيع طلباتك باستخدام شهادة الأمان المسجّلة. تتوفّر بعض خلاصات Google Data API للتطبيقات المسجّلة فقط. اطلع على وثائق واجهة برمجة تطبيقات بيانات Google التي تهتم بها لتحديد ما إذا كانت واجهة برمجة التطبيقات هذه تعمل فقط مع التطبيقات المسجلة أم لا.

يجب أن يوقّع التطبيق على كل طلب OAuth يجريه. إذا اخترت استخدام توقيع RSA-SHA1 لتوقيع طلباتك، عليك تحميل شهادة أمان كجزء من عملية التسجيل.

بدلاً من ذلك، يمكنك استخدام توقيع HMAC-SHA1 لتوقيع طلباتك. ولا يلزم استخدام شهادة لتوقيعات HMAC-SHA1. بدلاً من ذلك، تنشئ Google قيمة OAuth consumer secret، والتي يتم عرضها على صفحة تسجيل نطاقك بعد إتمام التسجيل.

لمزيد من المعلومات عن عملية التسجيل، يمكنك الاطّلاع على التسجيل في تطبيقات الويب.

تحديد نطاق البيانات التي سيصل إليها تطبيقك

تضع كل خدمة من خدمات Google حدودًا على إذن الوصول الذي تسمح به من خلال Google Data APIs. ويتم التعبير عن إمكانية الوصول هذه كقيمة للنطاق. وتوفر بعض الخدمات مجموعة متنوعة من قيم النطاق، للسماح للمستخدم باختيار التطبيقات التي يجب أن يكون لديها حق الوصول إلى البيانات. للحصول على معلومات عن قيم النطاق المتاحة لخدمة Google التي تريد الوصول إليها، يمكنك الاطّلاع على مستندات الخدمة.

وبوجه عام، يجب عليك طلب رمز مميز للنطاق الأضيق الذي يتضمن البيانات التي تحتاج إليها. على سبيل المثال، إذا كان تطبيقك يتطلب الوصول إلى خلاصة "كل التقاويم" للمستخدم، عليك طلب رمز مميز للنطاق http://www.google.com/calendar/feeds/default/allcalendars/full.

إعداد آلية لإدارة الرموز المميزة لـ OAuth

عند الحصول على رمز الدخول المميز عبر OAuth لبيانات المستخدم، يجب استخدام رمز الدخول هذا لجميع التفاعلات المستقبلية مع خدمة Google المحددة نيابةً عن المستخدم.

يجب أن يدير تطبيقك مساحة تخزين الرمز المميّز بشكل آمن، بما في ذلك تتبُّع خدمة Google التي يكون كل رمز مميّز صالحًا لها. إذا كنت بحاجة إلى الوصول إلى أكثر من خدمة واحدة من خدمات Google، يمكنك الحصول على رموز دخول متعدّدة، ولكن لا يمكن أن يكون هناك أكثر من عشرة رموز دخول لكل مستخدم وتطبيق يمكن الاستفادة منها في أي وقت.

إذا كان تطبيقك يتيح استخدام عدة حسابات مستخدمين، يجب تتبع الحساب الذي يرتبط به كل رمز مميز. ويكون كل رمز مميز لبروتوكول OAuth خاصًا بالمستخدم الذي صرّح له بالدخول. يجب أن يكون تطبيقك قادرًا على ربط رمز مميز بالمستخدم الصحيح. وتتمثّل إحدى طرق إدارة ذلك في إصدار ملف تعريف ارتباط إلى المستخدم قبل تقديم طلب الرمز المميز. بعد أن يمنح المستخدم حق الوصول إلى البيانات المطلوبة، ترسل Google رمزًا مميزًا للطلب المُصرَّح به ويعيد توجيه المستخدم إلى تطبيقك. ويمكنك بعد ذلك استخدام ملف تعريف ارتباط التطبيق لربط الرمز المميز بالمستخدم الصحيح.

إعداد آلية لطلب الوصول إلى إحدى خدمات Google

يجب التوقيع على كل طلب يتم إرساله إلى خدمة من خدمات Google، كما يجب تضمين رمز دخول صالح عبر OAuth. بشكل عام، يتم تقديم كل طلب في شكل طلب HTTP GET مع تضمين رمز الدخول والتوقيع في العنوان. يجب أن تستخدم الطلبات التي تكتب بيانات جديدة HTTP POST.

للحصول على مزيد من المعلومات عن تنسيق الطلب المناسب لكل واجهة برمجة تطبيقات لبيانات Google، يُرجى الرجوع إلى وثائق واجهة برمجة التطبيقات هذه.

تنفيذ OpenID (اختياري)

في حال تنفيذ OpenID لمصادقة المستخدم، ننصحك باستخدام البروتوكول المختلط لدمج العمليتين. باستخدام OpenID+OAuth، تتم معالجة مهام الحصول على رمز مميز للطلب والتفويض كجزء من طلب OpenID مع إضافات OAuth. وكما هو الحال مع OAuthGetRequestToken، يتم استخدام هذه الإضافات لتحديد خدمات Google التي يتم الوصول إليها. تحتوي الاستجابة الناجحة لطلب OpenID على رمز مميّز لطلب معتمَد. بعد تلقي هذا الرمز المميز، استخدِم OAuthGetAccessToken لاستبداله برمز دخول.

العمل باستخدام رموز OAuth المميزة

لاستخدام OAuth، يجب أن ينشئ تطبيقك طلبات بشكل صحيح وموقّع لطلب الرمز المميّز، وأن يعالج الاستجابات للتسلسل التالي:

  1. الحصول على رمز مميز لطلب غير مصرّح به (OAuthGetRequestToken)
  2. مصادقة الرمز المميز للطلب (OAuthAuthorizeToken)
  3. تبادل رمز الطلب المميز لرمز الدخول المميز (OAuthGetAccessToken)

يجب توقيع جميع طلبات OAuth، سواء تم تسجيل تطبيقك أم لا. لمزيد من المعلومات، يُرجى الاطِّلاع على توقيع طلبات OAuth.

يمكنك تجربة طلب الرموز المميزة للتفويض وتلقيها في مساحة بروتوكول OAuth.

للاطّلاع على المستندات التفصيلية، راجِع مرجع واجهة برمجة تطبيقات OAuth.

تعيين عنوان URL لرد الاتصال

يمكنك تحديد قيمة للسمة oauth_callback في طلب OAuthGetRequestToken لتحديد المكان الذي تعيد Google فيه توجيه المستخدم بعد تخويله لطلب الوصول. يمكن أن يتضمن عنوان URL لرد الاتصال معلمات طلب البحث. ستتضمّن عملية إعادة التوجيه معلَمات طلب البحث نفسها، بالإضافة إلى رمز الطلب المميز الذي يجب أن يتمكن تطبيقك من تحليله.

على سبيل المثال، عند دعم لغات متعددة، يمكنك تضمين معلمة طلب بحث تحدد إصدار التطبيق الذي يعرضه المستخدم. قد تؤدي القيمة oauth_callback لـ "http://www.yoursite.com/Recovertoken?Lang=de" إلى إعادة التوجيه "http://www.yoursite.com/Recovertoken?Lang=de&oauth_token=DQAADKEDE". من خلال تحليل الرمز المميّز ومَعلمة اللغة، يُعاد توجيه المستخدم إلى النسخة الصحيحة من الموقع الإلكتروني.

إذا لم يتم تضمين المعلمة oauth_callback، ستوجّه Google المستخدم إلى صفحة ويب تعرض رقم التحقق (انظر المثال)، بعد مصادقة طلب الدخول. ويجب أن يعود المستخدم يدويًا إلى طلبك ويُدخِل رقم التحقق قبل أن تتمكّن من الحصول على رمز مميّز لطلب مصرّح به.

تحديد تطبيقك للمستخدمين

تعرض Google عادةً اسم التطبيق عند طلب الحصول على موافقة المستخدم من الوصول (الاطّلاع على المثال).

إذا لم يتم تسجيل تطبيقك، استخدِم المعلمة xoauth_displayname في طلب OAuthGetRequestToken لتحديد اسم تطبيقك. وفي حال عدم تحديد هذه المعلّمة، يعرض محرّك البحث Google اسم نطاق عنوان URL الذي توفّره المعلّمة oauth_callback. وإذا لم يتم تقديم عنوان URL لرد الاتصال، سيعرض محرّك البحث Google السلسلة "مجهول المصدر".

لا تضبط هذه المعلمة إذا كان التطبيق مسجلاً. تعرض Google تلقائيًا الاسم المعروض المُحدَّد أثناء التسجيل. إذا اخترت اسمًا معروضًا في طلب OAuthGetRequestToken، ستستخدمه Google بدلاً من اسم العرض المسجّل الخاص بك، وستتضمن رسالة تفيد بأنّه لا يمكن إثبات هوية التطبيق.

ملاحظة: لضبط المَعلمة xoauth_displayname في مساحة بروتوكول OAuth، ضع علامة في المربّع "إعدادات متقدّمة" قبل جلب الرمز المميز للطلب.

التعامل مع نطاقات Google Apps

إذا تم تصميم تطبيقك للمستخدمين على نطاق حسابات Google مستضافة، ففكّر في استخدام معلمة hd عند تفويض رمز مميز. لمزيد من المعلومات حول المَعلمة hd، راجِع التعامل مع المستخدمين الذين لديهم حسابات متعددة.

مزيد من المعلومات حول OAuth

للحصول على معلومات تفصيلية حول تنفيذ Google لبروتوكول OAuth، بما في ذلك كيفية تسجيل تطبيقك وإنشاء معلمات OAuth اللازمة، راجع هذه الموارد الإضافية:

الرجوع إلى الأعلى

استخدام OAuth مع التطبيقات المثبتة

تدعم جميع واجهات برمجة التطبيقات لبيانات Google بروتوكول OAuth وهو معيار مفتوح لتفويض استخدام البيانات في التطبيقات. لا يلزم تسجيل التطبيقات المثبتة في Google لاستخدام OAuth.

عملية تفويض OAuth

تتضمن عملية تفويض OAuth سلسلة من التفاعلات بين تطبيقك وخوادم تفويض Google والمستخدم.

على المستوى الأساسي، تتم العملية على النحو التالي:

  1. يطلب تطبيقك الوصول ويحصل على رمز طلب غير مصرح به من خادم تفويض Google.
  2. تطلب Google من المستخدم أن يمنحك إمكانية الوصول إلى البيانات المطلوبة.
  3. يحصل تطبيقك على رمز مميّز لطلب مُعتمَد من خادم التفويض.
  4. يمكنك استبدال رمز الطلب المصرح به برمز دخول.
  5. يمكنك استخدام رمز الدخول المميز لطلب البيانات من خوادم الوصول إلى خدمات Google.

عندما يطلب تطبيقك في البداية الوصول إلى بيانات المستخدم، يصدر Google رمز طلب مميز غير مصرح به إلى تطبيقك.

إذا لم يسبق للمستخدم تسجيل الدخول، ستطلب من المستخدم تسجيل الدخول. يعرض Google بعد ذلك صفحة تفويض تتيح للمستخدم معرفة بيانات خدمة Google التي يطلب تطبيقك الوصول إليها.

إذا وافق المستخدم على طلب الوصول إلى تطبيقك، تصدر Google رمزًا مميزًا للطلب مُصرَّح به. ويكون رمز كل طلب مميز صالحًا لمدة ساعة واحدة فقط. لا يمكن استبدال سوى رمز الطلب المميز برمز دخول، ولا يمكن إجراء هذا التبادل سوى مرة واحدة فقط لكل رمز مميز المميز للطلب.

يدعم OAuth التطبيقات المثبتة باستخدام الوضع غير المسجل. نظرًا لوجود طرق متنوعة للحصول على رمز مميز مصرح به للطلب، يمكن لتطبيقك استخدام OAuth لتفويض أحد التطبيقات حتى إذا كان الجهاز الذي تم تثبيته عليه لا يحتوي على متصفح ويب.

حسب الإعدادات التلقائية، تكون رموز الدخول طويلة الأجل. ويكون كل رمز دخول مخصصًا لحساب المستخدم المحدد في طلب التفويض الأصلي، كما يمنح حق الدخول إلى الخدمات المحددة في هذا الطلب فقط. يجب أن يخزن التطبيق رمز الدخول بشكل آمن، نظرًا لأنه مطلوب لجميع عمليات الدخول إلى بيانات المستخدم.

الاستعداد لاستخدام OAuth

قبل أن تتمكن من إعداد تطبيقك لاستخدام خدمة تفويض Google مع OAuth، يجب إكمال المهام التالية.

تحديد نطاق البيانات التي سيصل إليها تطبيقك

تضع كل خدمة من خدمات Google حدودًا على إذن الوصول الذي تسمح به من خلال Google Data APIs. ويتم التعبير عن إمكانية الوصول هذه كقيمة للنطاق. وتوفر بعض الخدمات مجموعة متنوعة من قيم النطاق، للسماح للمستخدم باختيار التطبيقات التي يجب أن يكون لديها حق الوصول إلى البيانات. للحصول على معلومات عن قيم النطاق المتاحة لخدمة Google التي تريد الوصول إليها، يمكنك الاطّلاع على مستندات الخدمة.

وبوجه عام، يجب عليك طلب رمز مميز للنطاق الأضيق الذي يتضمن البيانات التي تحتاج إليها. على سبيل المثال، إذا كان تطبيقك يتطلب الوصول إلى خلاصة "كل التقاويم" للمستخدم، عليك طلب رمز مميز للنطاق http://www.google.com/calendar/feeds/default/allcalendars/full.

إعداد آلية لإدارة الرموز المميزة لـ OAuth

عند الحصول على رمز الدخول المميز عبر OAuth لبيانات المستخدم، يجب استخدام رمز الدخول هذا لجميع التفاعلات المستقبلية مع خدمة Google المحددة نيابةً عن المستخدم.

يجب أن يدير تطبيقك مساحة تخزين الرمز المميّز بشكل آمن، بما في ذلك تتبُّع خدمة Google التي يكون كل رمز مميّز صالحًا لها.

إذا كان تطبيقك يتيح استخدام عدة حسابات مستخدمين، يجب تتبع الحساب الذي يرتبط به كل رمز مميز.

إعداد آلية لطلب الوصول إلى إحدى خدمات Google

يجب التوقيع على كل طلب يتم إرساله إلى خدمة من خدمات Google، كما يجب تضمين رمز دخول صالح عبر OAuth. بشكل عام، يتم تقديم كل طلب في شكل طلب HTTP GET مع تضمين رمز الدخول والتوقيع في العنوان. يجب أن تستخدم الطلبات التي تكتب بيانات جديدة HTTP POST.

للحصول على مزيد من المعلومات عن تنسيق الطلب المناسب لكل واجهة برمجة تطبيقات لبيانات Google، يُرجى الرجوع إلى وثائق واجهة برمجة التطبيقات هذه.

العمل باستخدام رموز OAuth المميزة

لاستخدام OAuth، يجب أن ينشئ تطبيقك طلبات بشكل صحيح وموقّع لطلب الرمز المميّز، وأن يعالج الاستجابات للتسلسل التالي:

  1. الحصول على رمز مميز لطلب غير مصرّح به (OAuthGetRequestToken)
  2. مصادقة الرمز المميز للطلب (OAuthAuthorizeToken)
  3. تبادل رمز الطلب المميز لرمز الدخول المميز (OAuthGetAccessToken)

يجب توقيع جميع طلبات OAuth، سواء تم تسجيل تطبيقك أم لا. لمزيد من المعلومات، يُرجى الاطِّلاع على توقيع طلبات OAuth. يجب أن تتّبع التطبيقات المثبَّتة تعليمات تطبيق غير مسجَّل.

يمكنك تجربة طلب الرموز المميزة للتفويض وتلقيها في مساحة بروتوكول OAuth.

للاطّلاع على المستندات التفصيلية، راجِع مرجع واجهة برمجة تطبيقات OAuth.

تحديد تطبيقك للمستخدمين

تعرض Google عادةً اسم التطبيق عند طلب الحصول على موافقة المستخدم من الوصول (الاطّلاع على المثال).

استخدِم المَعلمة xoauth_displayname في طلب OAuthGetRequestToken لتحديد اسم تطبيقك. وفي حال عدم تحديد هذه المعلّمة، يعرض محرّك البحث Google اسم نطاق عنوان URL الذي توفّره المعلّمة oauth_callback. وإذا لم يتم تقديم عنوان URL لرد الاتصال، سيعرض محرّك البحث Google السلسلة "مجهول المصدر".

ملاحظة: لضبط المَعلمة xoauth_displayname في مساحة بروتوكول OAuth، ضع علامة في المربّع "إعدادات متقدّمة" قبل جلب الرمز المميز للطلب.

إطلاق متصفح ويب

كجزء من عملية تفويض OAuth، على تطبيقك تقديم طلب OAuthAuthorizeToken. يجب على المستخدم بعد ذلك تسجيل الدخول إلى صفحة ويب على Google وتفويض طلب الدخول إلى التطبيق.

  • يجب استخدام وضع الاكتشاف التلقائي لمعظم التطبيقات
  • يجب استخدام وضع الجهاز للتطبيقات التي لا يمكنها تشغيل متصفّح ويب كامل الوظائف.
  • يجب استخدام وضع التطوير أثناء التطوير المبكر فقط.

وضع الاكتشاف التلقائي

إن أمكن، يجب أن يشغّل التطبيق نافذة متصفّح وأن يرسل طلب OAuthAuthorizeToken لفتح صفحة Google. عندما يعرض محرّك البحث Google الرمز المميّز المصرَّح به، يجب أن يكتشف تطبيقك هذا الرمز ويعيد التركيز عليه من متصفّح الويب.

يتطلب هذا الوضع تقديم عنوان URL لرد الاتصال تتم إعادة توجيه المستخدم إليه بعد أن يفوّض طلب وصولك. يجب تقديم عنوان URL هذا كمَعلمة oauth_callback في طلب OAuthGetRequestToken، وكمعلمة verifier لطلب OAuthGetAccessToken.

لتحسين تجربة المستخدم، يجب أن يحاول تطبيقك اكتشاف إعادة توجيه المستخدم إلى عنوان URL هذا تلقائيًا، وتقديم نفسه فورًا إلى المقدّمة وإرسال طلب OAuthGetAccessToken لإكمال عملية OAuth.

لمزيد من المعلومات وأفضل الممارسات، اطلع على الاكتشاف التلقائي للموافقة.

إذا لم يتمكّن تطبيقك من رصد إعادة توجيه المستخدم إلى عنوان URL لمعاودة الاتصال تلقائيًا أو إذا تعذّر عليه إظهار نفسه في المقدّمة، يجب أن يعرض عنوان URL لمعاودة الاتصال صفحة توضّح كيفية عرض تطبيقك في المقدمة وكيفية بدء طلب OAuthGetAccessToken من داخل تطبيقك.

وضع الجهاز

إذا كان تطبيقك لا يستطيع تشغيل متصفّح ويب كامل الوظائف، من الممكن أيضًا للأجهزة التي تتضمن برامج عميلة أن تضمّن التفويض بدون متصفّح ويب.

يتيح هذا الوضع لمطوّر البرامج إعداد موقع إلكتروني يمكن للمستخدم من خلاله تفويض طلب الوصول. بعد التفويض، يتم منح المستخدم رمزًا أنشأته Google ويُعاد توجيهه إلى الموقع الإلكتروني لمطوّر البرامج. ويجب أن يوضّح هذا الموقع الإلكتروني للمستخدم كيفية إدخال الرمز في جهازه لإكمال عملية التفويض.

وضع التطوير

هذا الوضع موصى به للاستخدام خلال مرحلة التطوير الأولي للتطبيق فقط.

كما هو الحال في وضع "الرصد التلقائي"، يجب أن يشغّل التطبيق متصفّحًا، ويجب أن يسمح المستخدم بطلبك. وبدلاً من إنشاء صفحة ويب لعنوان URL لرد الاتصال، يمكنك ضبط قيمة المعلَمة oauth_callback على "oob" (خارج النطاق).

وفي هذه الحالة، وبعد أن يصادق المستخدم على طلبك، توجّه Google المستخدم إلى صفحة "حسابات Google" التي تعرض رقم التحقّق (راجِع المثال).

على المستخدم الرجوع إلى طلبك وإدخال رقم التحقق قبل أن تتمكن من تقديم طلب OAuthGetAccessToken.

مزيد من المعلومات حول OAuth

للحصول على معلومات تفصيلية حول تنفيذ Google لبروتوكول OAuth، بما في ذلك كيفية تسجيل تطبيقك وإنشاء معلمات OAuth اللازمة، راجع هذه الموارد الإضافية:

الرجوع إلى الأعلى

استخدام AuthSub للتفويض

AuthSub هي واجهة برمجة تطبيقات للتفويض مملوكة لشركة Google، ومتاحة كبديل لبروتوكول OAuth لمعظم واجهات برمجة تطبيقات Google. عليك تجنّب استخدام AuthSub إن أمكن. إذا كانت لديك تطبيقات تستخدم AuthSub، عليك الترحيل إلى OAuth أو البروتوكول المختلط.

عملية تفويض AuthSub

يتضمن التفويض من خلال AuthSub سلسلة من التفاعلات بين ثلاثة كيانات: تطبيق الويب، وخدمات Google، والمستخدم. يوضح هذا الرسم البياني التسلسل:

عملية التفويض

  1. عندما يحتاج تطبيق الويب إلى الوصول إلى خدمة Google لمستخدم، يجري استدعاء AuthSub إلى خدمة الخادم الوكيل للمصادقة من Google.
  2. تستجيب خدمة التفويض بعرض صفحة طلب الوصول. تطلب هذه الصفحة التي تديرها Google من المستخدم منح/رفض الدخول إلى خدمة Google. قد يُطلب من المستخدم أولاً تسجيل الدخول إلى حسابه.
  3. يقرر المستخدم ما إذا كان يريد منح أو رفض الدخول إلى تطبيق الويب. إذا رفض المستخدم الدخول، فسيتم توجيهه إلى صفحة Google بدلاً من الرجوع إلى تطبيق الويب.
  4. وإذا منح المستخدم إمكانية الدخول، فإن خدمة التفويض تعيد توجيه المستخدم مرة أخرى إلى تطبيق الويب. تحتوي عملية إعادة التوجيه على رمز تفويض صالح للاستخدام لمرة واحدة، ويمكن استبداله برمز مميز قديم.
  5. يتصل تطبيق الويب بخدمة Google من خلال طلب، وذلك باستخدام الرمز المميز للتفويض ليكون بمثابة وكيل للمستخدم.
  6. إذا تعرفت خدمة Google على الرمز المميز، فإنها توفر البيانات المطلوبة.

استخدام AuthSub

يتطلب دمج AuthSub في تطبيق الويب إجراء المهام التالية:

  1. حدد ما إذا كنت تريد تسجيل تطبيق الويب أم لا.

    وتتمتع تطبيقات الويب المسجلة بميزة التعرف عليها من قِبل Google؛ حيث يتم تعديل أو حذف التنبيه القياسي المعروض للمستخدمين على صفحة تسجيل الدخول إلى Google. بالإضافة إلى ذلك، يتم تعريف تطبيقات الويب المسجلة باسم وصفي بدلاً من مجرد عنوان URL للاستدعاء. ضع في اعتبارك أن بعض خدمات Google لا تسمح إلا بالدخول المحدود إلى تطبيقات الويب غير المسجلة. إذا اخترت التسجيل، فاستخدم عملية التسجيل التلقائية هذه.

    في حال التسجيل، يمكنك أيضًا تقديم شهادة أمان ومفاتيح. يمكن لتطبيقات الويب المسجّلة التي تحتوي على شهادة مسجلة الحصول على رموز مميزة آمنة للاستخدام عند طلب بيانات من خدمة Google. (ويمكنها أيضًا استخدام رموز مميزة غير آمنة إذا لزم الأمر.)

  2. حدِّد نوع الرموز المميزة التي تريد استخدامها وكيفية إدارتها.

    والغرض من الرمز المميز للتفويض الذي تم استلامه من Google هو استخدامه في جميع التفاعلات المستقبلية مع خدمة Google المحددة لهذا المستخدم. ويعتمد نوع الرمز المميز الذي تختار استخدامه--للاستخدام لمرة واحدة أو للجلسة- على نوع التفاعلات التي سيتم إجراؤها مع تطبيق الويب مع إحدى خدمات Google. على سبيل المثال، قد يكون الرمز المميز الذي يُستخدم لمرة واحدة كافيًا إذا كان التفاعل عبارة عن حدث لمرة واحدة أو حدث نادر.

    إذا اخترت الحصول على رموز جلسة واستخدامها بشكل منتظم للدخول إلى خدمة Google، فسيلزم تطبيق الويب إدارة سعة تخزين الرمز المميز، بما في ذلك تتبع المستخدم وخدمة Google التي يصلح فيها الرمز المميز. لم يتم إعداد حسابات Google لإدارة عدد كبير من الرموز المميزة، وفي الحقيقة لا تسمح بأكثر من عشرة رموز مميزة صالحة (لكل مستخدم ولكل تطبيق ويب) لتكون مميزة في أي وقت. ويسمح هذا التقييد لأحد تطبيقات الويب بالحصول على رموز مميزة متعددة لتغطية خدمات مختلفة، إذا لزم الأمر، ولا يتيح الحصول على رمز مميز جديد في كل مرة يحتاج فيها تطبيق الويب إلى الدخول إلى إحدى خدمات Google. إذا قررت تخزين الرموز المميزة للجلسة، يجب التعامل مع الرموز المميزة بشكل آمن كأي معلومات حساسة أخرى مخزنة على الخادم.

    وبدلاً من ذلك، يمكنك اختيار الحصول على رموز مميزة جديدة بشكل منتظم ما دمت تقوم بإعداد آلية لإبطال الرمز المميز. سيحتاج تطبيقك إلى إبطال الرمز المميز الحالي قبل طلب رمز مميز آخر. في هذا السيناريو، سيُطلب من المستخدم تسجيل الدخول ومنح حق الوصول في كل مرة يتم فيها طلب رمز مميز جديد.

  3. حدد النطاق المطلوب للوصول إلى خدمة Google.

    تحدِّد كل خدمة من خدمات Google مقدار الوصول الذي تسمح به ونوعه. ويتم التعبير عن إمكانية الوصول هذه كقيمة للنطاق. قد يكون نطاق الخدمة عنوان URL بسيطًا يحدد الخدمة بالكامل، أو قد يحدد إمكانية وصول أكثر تقييدًا. تقيّد بعض الخدمات الوصول بشدة، مثل السماح بالوصول للقراءة فقط إلى معلومات محدودة. للحصول على النطاقات المسموح بها لخدمة Google التي تريد الوصول إليها، يمكنك الرجوع إلى وثائق هذه الخدمة. يجب عليك طلب الرمز المميز الأكثر نطاقًا قدر الإمكان. على سبيل المثال، إذا كنت تحاول الدخول إلى ميزة خلاصة Atom في Gmail، فاستخدم النطاق "http://www.google.com/calendar/feeds/"، وليس "http://www.google.com/calendar/". تعتبر خدمات Google أكثر تقييدًا مع الطلبات على نطاق واسع.

  4. يمكنك إعداد آلية لطلب الرمز المميز للتفويض وتلقيه.

    يجب أن تنشئ الآلية استدعاء AuthSubRequest بتنسيق سليم، بما في ذلك تحديد قيم مناسبة لعنوان URL التالي والنطاق (المحددة في الخطوة 3). إذا كنت تستخدم رموزًا مميزة آمنة و/أو تدير رموزًا مميّزة للجلسة، يجب أن يتضمّن الطلب قيمًا لهذه المتغيرات أيضًا.

    يمكن أن يتضمن عنوان URL التالي معلمات طلب البحث. على سبيل المثال، عند دعم لغات متعددة، يمكنك تضمين معلمة طلب بحث تحدد إصدار تطبيق الويب الذي يعرضه المستخدم. ستؤدي القيمة التالية لـ http://www.yoursite.com/Retrievetoken?Lang=de إلى إعادة التوجيه http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE. ويضمن تحليل الرمز المميز ومعلمة Lang إعادة توجيه المستخدم إلى الإصدار الصحيح من الموقع.

    في حالات معينة، يمكن أن يساعد استخدام المعلمة hd في تبسيط تجربة المستخدمين عندما يُطلب منهم منح حق الوصول إلى موقع حسابات Google. في معظم الحالات، تكون العملية مسألة بسيطة وهي تسجيل الدخول إلى الحساب واختيار ما إذا كنت تريد منح حق الدخول أم لا. ومع ذلك، قد يحتاج المستخدمون الذين لديهم أكثر من حساب Google واحد (حساب Gmail عادي و/أو حساب واحد أو أكثر من حسابات مستضافة في Google Apps) إلى اتباع عملية "تسجيل الدخول العام" الإضافية لتحديد الحساب الذي يريدون الدخول إليه. إذا كان تطبيقك مصممًا لنطاق مُدار واحد، يمكنك استبعاد هذه الخطوات الإضافية باستخدام هذه المعلمة لتحديد هذا النطاق. كما يمكنك استخدام المعلمة hd إذا كان تطبيقك يدخل إلى خدمات غير متاحة في الحسابات المستضافة--فإن تعيين القيمة على "افتراضي" سيؤدي إلى قصر التفويض على الحسابات العادية فقط. عند ضبط القيمة hd، سيختار Google تلقائيًا الحساب الصحيح للتفويض.

    يجب أن تكون آلية الرمز المميز مجهزة لتحليل إعادة التوجيه التي تم الحصول عليها من Google، والتي تحتوي على الرمز المميز للاستخدام لمرة واحدة، واتخاذ إجراء معه. نظرًا لأن الرموز المميزة للتفويض خاصة بالمستخدم، يجب أن يتمكن التطبيق من ربط رمز مميز بمستخدمه. والخيار المفضل هو إصدار ملف تعريف ارتباط إلى المستخدم قبل إجراء طلب الرمز المميز. وبعد ذلك، عندما تعيد Google توجيه المستخدم إلى موقعك الإلكتروني مرة أخرى باستخدام رمز مميّز ملحق، يمكن لتطبيقك قراءة ملف تعريف الارتباط وربط الرمز المميّز برقم تعريف المستخدم الصحيح.

  5. يمكنك إعداد آليات لطلب رموز الجلسات المميزة وتخزينها أو إبطالها، إذا كان ذلك مناسبًا.

    وفقًا لقرارات إدارة الرموز المميَّزة التي اتّخذتها في الخطوة 2، قد تحتاج إلى إنشاء آليات للحصول على رموز مميَّزة للجلسة وإبطالها (AuthSubSessionToken وAuthSubإبطالToken). لاختبار آليات الجلسات والإبطال، استخدِم AuthSubTokenInfo الذي يشير إلى ما إذا كان الرمز المميز صالحًا أم لا. في حالة تخزين الرموز المميزة، يجب أن يتتبع التطبيق كلاً من الرقم التعريفي للمستخدم والخدمة (النطاق) التي يغطيها الرمز المميز.

  6. يمكنك إعداد آلية لطلب الوصول إلى إحدى خدمات Google.

    يمكنك الرجوع إلى مستندات خدمة Google للحصول على معلومات حول تنسيق الطلب الصحيح. يجب أن تتضمن جميع طلبات خدمة Google رمز تفويض مميزًا صالحًا. بوجه عام، يكون طلب إحدى خدمات Google في شكل HTTP GET (أو POST في حال كتابة بيانات جديدة)، مع الرمز المميز المُشار إليه في عنوان الطلب.

    يجب أن يتخذ عنوان الطلب النموذج التالي:

    Authorization: AuthSub token="token"

    حيث يكون الرمز المميز هو الرمز المميز للتفويض أو الاستخدام لمرة واحدة أو الجلسة التي تم استلامها من Google ردًا على طلب AuthSub. إذا كان الرمز المميّز آمنًا، يجب أن يكون مصحوبًا بتوقيع رقمي. اطلع على "طلبات التوقيع" للحصول على إرشادات وأمثلة.

    يوضح المثال أدناه رأس طلب لاستدعاء خدمة خلاصة تقويم Google. يحتوي هذا الطلب على رمز مميز غير آمن: 

    GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

مزيد من المعلومات حول AuthSub

للحصول على معلومات عن AuthSub، بما في ذلك تسجيل تطبيقك في Google وشرح تفصيلي لتبادل رمز مميز لمرة واحدة مع رمز مميز للجلسة، راجع هذه الموارد الإضافية:

الرجوع إلى الأعلى

استخدام ClientLogin للتفويض

ClientLogin هي واجهة برمجة تطبيقات للتفويض مملوكة لشركة Google، ومتوفرة كبديل لبروتوكول OAuth لمعظم واجهات برمجة تطبيقات Google. يجب تجنب استخدام ClientLogin إن أمكن. إذا كانت لديك بالفعل تطبيقات تستخدم ClientLogin، يجب الترحيل إلى OAuth أو البروتوكول المختلط.

مصادقة التطبيقات المثبتة: ClientLogin

يتيح ClientLogin للمستخدمين تسجيل الدخول إلى حساب Google من داخل تطبيقك. بعد ذلك، يتصل التطبيق بـ Google باستخدام بيانات تسجيل الدخول ويطلب الدخول إلى واجهة برمجة تطبيقات معينة لبيانات Google. بعد مصادقة معلومات تسجيل الدخول بنجاح، تعرض Google رمزًا مميزًا يشير إليه تطبيقك في كل مرة يطلب فيها الدخول إلى حساب المستخدم، مثل الحصول على بيانات أو نشرها. يظل الرمز المميز صالحًا لمدة زمنية محددة، يتم تحديدها من خلال أي خدمة من خدمات Google تعمل معها.

ملاحظة: توفر مكتبات العميل في Google Data APIs طرقًا لمساعدتك في استخدام ClientLogin في التطبيقات المثبتة. وعلى وجه التحديد، هناك طرق للحصول على الرمز المميز للمصادقة، والتعامل مع اختبارات CAPTCHA، واسترجاع الرمز المميز للمصادقة للاستخدام لاحقًا، وإرسال عنوان Authorization الصحيح مع كل طلب. إذا كنت تعمل مع إحدى المكتبات، راجع استخدام ClientLogin مع مكتبات برامج Google Data APIs.

عملية تفويض ClientLogin

يتضمن التفويض باستخدام ClientLogin سلسلة من التفاعلات بين ثلاثة كيانات: التطبيق المثبّت، وخدمات Google، والمستخدم. يوضح هذا الرسم البياني التسلسل:

عملية التفويض

  1. عندما يحتاج تطبيق الجهة الخارجية إلى الوصول إلى خدمة Google للمستخدم، فإنه يسترد اسم تسجيل دخول المستخدم وكلمة مروره.
  2. بعد ذلك، يُجري تطبيق الجهة الخارجية استدعاء ClientLogin إلى خدمة تفويض Google.
  3. إذا رأت خدمة تفويض Google أن التحقق الإضافي ضروري، فإنها تعرض استجابة الإخفاق مع رمز اختبار CAPTCHA مميز وتحد، في شكل عنوان URL لصورة اختبار CAPTCHA.
  4. إذا تم تلقي اختبار CAPTCHA، فسيعرض تطبيق الجهة الخارجية صورة اختبار CAPTCHA للمستخدم ويطلب إجابة من المستخدم.
  5. إذا طلب المستخدم ذلك، يرسل إجابة عن اختبار CAPTCHA.
  6. يجري تطبيق الجهة الخارجية استدعاء ClientLogin جديدًا هذه المرة، بما في ذلك إجابة اختبار CAPTCHA والرمز المميز (الذي تم استلامه مع استجابة الإخفاق).
  7. في محاولة تسجيل دخول ناجحة (مع اختبار CAPTCHA أو بدونه)، تعرض خدمة تفويض Google رمزًا مميزًا للتطبيق.
  8. يتصل التطبيق بخدمة Google وطلب الدخول إلى البيانات، مع الإشارة إلى الرمز المميز الذي تم استلامه من خدمة تفويض Google.
  9. إذا تعرفت خدمة Google على الرمز المميز، فإنها توفر إمكانية الوصول المطلوب إلى البيانات.

استخدام ClientLogin

استخدم هذه الواجهة في التطبيق الذي تم تثبيته للدخول برمجيًا إلى حساب Google للمستخدم. بعد جمع معلومات تسجيل الدخول من المستخدم، اتصل بـ ClientLogin لطلب الوصول إلى حساب المستخدم. بعد مصادقة معلومات تسجيل الدخول بنجاح، تعرض Google رمزًا مميزًا يشير إليه تطبيقك في كل مرة يطلب فيها الدخول إلى حساب المستخدم. ويظل الرمز المميز صالحًا لمدة زمنية محددة، والتي يتم تحديدها من خلال أي خدمة من خدمات Google تعمل معها.

يتطلب إدراج ClientLogin في تطبيقك المهام التالية:

  1. أنشئ عنصر واجهة مستخدم لالتقاط بيانات تسجيل الدخول من المستخدم.

    يجب أن تطلب واجهة المستخدم اسم مستخدم (عنوان بريد إلكتروني، بما في ذلك النطاق) وكلمة مرور. يجب أن تكون واجهة المستخدم أيضًا قادرة على عرض صورة اختبار CAPTCHA باستخدام عنوان URL الذي تم تلقيه من Google، إذا كان مطلوبًا، وطلب إجابة صحيحة من المستخدم. بشكل مثالي، ستتضمن واجهة المستخدم رابطًا لصفحة تسجيل الدخول إلى حسابات Google ("https://www.google.com/accounts/Login") في حالة احتياج المستخدم إلى الاشتراك في حساب جديد أو إجراء صيانة أخرى للحساب.

  2. اكتب الرمز لإنشاء طلب HTTPS POST ClientLogin منسق بشكل صحيح وأرسله.

    يجب أن يحتوي هذا الرمز على منطق للتعامل مع اختبار CAPTCHA وأن يتضمّن المعلّمتَين logintoken وlogincaptcha على حدّ سواء. كما يجب أن يكون التطبيق قادرًا على اكتشاف وقت حذف المستخدم للمعلومات المطلوبة -- أو تكرار البيانات غير الصحيحة بعد إخفاق تسجيل الدخول -- وعرض خطأ دون إرسال طلب غير ضروري.

  3. تعامل مع الردود من Google.

    هناك أربعة ردود محتملة على طلب تسجيل الدخول:

    • نجاح (HTTP 200)
    • إخفاق (HTTP 403) مع رمز خطأ توضيحي
    • طلب غير صالح، ينتج بشكل عام عن طلب تمت صياغته بشكل غير صحيح
    • الإخفاق في اختبار CAPTCHA

    تحتوي استجابة النجاح على رمز مصادقة مميز يُسمى "Auth". يجب تضمين هذا الرمز المميز في جميع الطلبات اللاحقة إلى خدمة Google لهذا الحساب. يجب حماية الرموز المميزة للتفويض بعناية وعدم منحها لأي تطبيق آخر، لأنها تمثل إمكانية الوصول إلى حساب المستخدم. ويختلف الحدّ الزمني المسموح به لاستخدام الرمز المميز حسب الخدمة التي أصدرته.

    تتضمن الاستجابة للإخفاق رمز خطأ واحدًا أو أكثر وعنوان URL مع رسالة الخطأ التي يمكن عرضها للمستخدم. يُرجى ملاحظة أن ClientLogin لا يفرق بين الإخفاق بسبب كلمة مرور غير صحيحة أو بسبب اسم مستخدم غير معروف (على سبيل المثال، إذا لم يشترك المستخدم للحصول على حساب حتى الآن). يحتاج تطبيقك إلى معالجة جميع رسائل الخطأ المحتملة حسب الحاجة.

    تعني الاستجابة للإخفاق مع تحدي اختبار CAPTCHA أن Google قد قررت، لأي سبب من الأسباب، أنه يجب اتخاذ إجراءات أمان إضافية. وتكون هذه الاستجابة مصحوبة بعنوان URL لصورة في اختبار CAPTCHA ورمز مميز يمثل تحدي اختبار CAPTCHA المحدد.

  4. تعامل مع اختبار CAPTCHA من Google.

    لمعالجة التحدي، يجب أن يعرض التطبيق صورة اختبار CAPTCHA وأن يطلب إجابة من المستخدم. لعرض صورة اختبار CAPTCHA، استخدم قيمة CaptchaUrl المعروضة مع استجابة الإخفاق، مع وضع بادئة لعنوان URL لحسابات Google: "http://www.google.com/accounts/ ". بعد تقديم المستخدم للإجابة، يجب أن يعيد التطبيق إرسال طلب تسجيل الدخول، وهذه المرة تشمل رمز CAPTCHA المميز (logintoken) وإجابة المستخدم (logincaptcha). تتحقق Google من إجابة المستخدم قبل تفويض الدخول إلى الحساب.

    هناك بديل لمطوّري البرامج الذين لا يريدون إدارة عملية الحصول على استجابة اختبار CAPTCHA للمستخدم وإرسالها. استجابةً لاختبار CAPTCHA، يمكن للتطبيق توجيه المستخدم إلى الصفحة التي تستضيفها Google: "https://www.google.com/accounts/DisplayUnlockCaptcha". بعد أن يجيب المستخدم بنجاح على التحدي، يثق خادم Google بالكمبيوتر المستخدم. ويمكن للتطبيق بعد ذلك إعادة إرسال طلب تسجيل الدخول الأصلي للحصول على الرمز المميز للتفويض.

    5. ملاحظة: لا تتحقق Google من محاولة تسجيل الدخول قبل إصدار اختبار CAPTCHA. وهذا يعني أن محاولة تسجيل الدخول قد تخفق حتى بعد إجراء اختبار CAPTCHA.

* اختبار CAPTCHA هو علامة تجارية لجامعة كارنيغي ميلون

الرجوع إلى الأعلى

مصادقة الأدوات

خادم وكيل OAuth

إذا كنت تنشئ أداة باستخدام واجهة برمجة التطبيقات للأدوات القياسية، يمكنك الاستفادة من ميزة النظام الأساسي للأداة المسماة الخادم الوكيل OAuth للوصول إلى واجهات برمجة التطبيقات لبيانات Google. OAuth (الموضح أعلاه) هو معيار مصادقة يسمح للمستخدمين بالوصول إلى بياناتهم الخاصة في خدمة استضافة الأدوات، مثل iGoogle أو MySpace أو Orkut، أو مشاركة بياناتهم مع موقع ويب أو أداة أخرى. تم تصميم خادم وكيل OAuth لتسهيل عملية التطوير لمطوري الأدوات من خلال إخفاء العديد من تفاصيل مصادقة OAuth. يستند الخادم الوكيل إلى مشروع مفتوح المصدر يسمى Shindig، وهو عبارة عن تنفيذ لمواصفات الأداة.

ملاحظة: لا يتوفر وكيل OAuth إلا للأدوات التي تستخدم واجهة برمجة التطبيقات gadgets.* ويتم تشغيلها في حاويات OpenSocial. ولا يتوافق هذا الإعداد مع واجهة برمجة التطبيقات للأدوات القديمة.

تدفق المصادقة

يجب أن تحصل الأداة على رمز OAuth مميز قبل أن تتمكن من الدخول إلى بيانات المستخدم. ويدير خادم وكيل OAuth تدفق المصادقة نيابةً عنك. عند تثبيت المستخدم لأول مرة لأداتك، تحدث العملية التالية:

  1. يتم تحميل الأداة للمرة الأولى وتحاول الوصول إلى بيانات المستخدم باستخدام إحدى واجهات برمجة التطبيقات لبيانات Google.
  2. تعذَّرت تلبية الطلب لأن المستخدم لم يمنح حق الوصول. يحتوي كائن الاستجابة على عنوان URL (في response.oauthApprovalUrl) لصفحة موافقة OAuth. يجب أن توفر الأداة طريقة لإطلاق نافذة جديدة بعنوان URL هذا.
  3. في صفحة الموافقة، يختار المستخدم منح حق الدخول إلى أداتك أو رفضه. في حالة نجاح هذا الإجراء، يتم نقل المستخدم إلى صفحة oauth_callback التي تحددها. للحصول على أفضل تجربة للمستخدم، استخدم http://oauth.gmodules.com/gadgets/oauthcallback.
  4. بعد ذلك، يغلق المستخدم النافذة المنبثقة. لإعلام أداتك بأن المستخدم قد وافق عليها، يمكنك استخدام معالج نافذة منبثقة لاكتشاف إغلاق نافذة الموافقة. وبدلاً من ذلك، يمكن أن تعرض الأداة رابطًا (على سبيل المثال، "أوافق على الدخول") كي ينقر المستخدم بعد إغلاق هذه النافذة.
  5. تحاول أداتك الدخول إلى واجهة برمجة تطبيقات بيانات Google مرة ثانية عن طريق إعادة طلب بيانات المستخدم. تمت هذه المحاولة بنجاح.
  6. تمت مصادقة أداتك ويمكن أن تبدأ في العمل بشكل طبيعي.

إعداد الأداة

للدخول إلى واحدة أو أكثر من واجهات برمجة التطبيقات لبيانات Google، يجب أولاً إخبار الأداة باستخدام OAuth كطريقة المصادقة. إضافة عنصر <OAuth> في القسم <ModulePrefs> من ملف XML لأداتك:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

في هذا القسم، يجب تغيير معامِلات طلب البحث التالية فقط:

scope
مَعلمة مطلوبة في عنوان URL للطلب. يمكن للأداة الدخول إلى البيانات من scope مستخدمة في هذه المعلمة. في هذا المثال، يمكن للأداة الوصول إلى بيانات Blogger والتقويم. ويمكن للأداة طلب بيانات لنطاق واحد أو عدة نطاقات، كما هو موضح في هذا المثال.
oauth_callback
مَعلمة اختيارية في عنوان URL للتفويض. تعيد صفحة الموافقة على OAuth التوجيه إلى عنوان URL هذا بعد موافقة المستخدم على الوصول إلى البيانات. يجب ضبط هذه المعلمة على http://oauth.gmodules.com/gadgets/oauthcallback لتقديم أفضل تجربة للمستخدم عند تثبيت الأداة. وتوفر هذه الصفحة مقتطف جافا سكريبت يغلق النافذة المنبثقة تلقائيًا. بدلاً من ذلك، يمكنك تعيين هذه المعلمة بحيث تشير إلى صفحتك "المعتمدة"، أو يمكنك ترك المعلمة فارغة.

الوصول إلى خلاصة Google Data API تمت مصادقتها

بعد مصادقة الأداة للمستخدم، يصبح الدخول إلى واجهة برمجة تطبيقات بيانات Google مباشرةً من خلال مكتبة عميل جافا سكريبت لـ Google Data APIs. للحصول على معلومات حول كيفية استخدام المكتبة في خادم وكيل OAuth، اطّلع على استخدام مكتبة عميل JavaScript.

مزيد من المعلومات حول الأدوات

للحصول على معلومات كاملة حول إنشاء أدوات واجهة برمجة التطبيقات لبيانات Google، بما في ذلك تفاصيل حول خادم وكيل OAuth، ومقالة حول كيفية البدء، ومواصفات gadgets.*، راجع هذه الموارد الإضافية:

الرجوع إلى الأعلى