أغلقت Google منصة التواصل الاجتماعي + Google في 2 أبريل 2019. من الصعب العثور على بعض المقالات الفنية التي لم تذكر نهاية عصر شبكة التواصل الاجتماعي من Google. لكن مستوى عال من الاتساق في الاتصال داخل خدمات الشركة قد حظي باهتمام ضئيل. في هذه المقالة ، أود أن أشارك أفكاري حول الطريقة الداخلية لتناسق خدمات Google وماذا يعني بالنسبة لمستخدمي Google API عندما يتعلق الأمر بإغلاق + Google.
من وجهة نظر العميل ، يجب أن يكون استخدام صور Gmail والتحول إلى مستندات أكثر وضوحًا قدر الإمكان - للوهلة الأولى ، تكون هذه الخدمات مستقلة وموحدة ضمن نظام أساسي واحد يمثل نقطة وصول تدعى accounts.google.com . ولكن كمطورين ، نعلم أن مصطلحات "إيقاف التشغيل" و "الاستحواذ" و "الاندماج" تنطوي على معنى كبير (وأيضًا العمل) لهؤلاء الأشخاص الذين يشاركون في هذه العملية. لذلك ، دعونا نلقي نظرة فاحصة على عملية واحدة من عمليات الاستحواذ على الخدمات الخارجية من Google ، وما يحدث مع واجهة برمجة تطبيقات خدمة الاستلام وواجهة برمجة تطبيقات Google.
حساب ومعرف المستخدم
بجانب المستخدمين الذين يستخدمون Gmail وقد يسمعوا عن Google Plus ، هناك أيضًا عدد كبير من واجهات برمجة التطبيقات للمطورين الذين يتضمنون أشياء مثل معرّفات الحساب ، معرف المستخدم السيئ السمعة. معرف المستخدم هو معرف Google الداخلي ، وهذا هو الشيء الذي يساعد خدمات Google على فهم من هو. لقد ظهر في العديد من واجهات برمجة التطبيقات ، ونرى أنه لم يتغير من خدمة إلى أخرى.
فوضى
من الواضح ، بالنسبة لتطبيق SSO في الخدمة التي تم استيعابها حديثًا ، لا يمكنك ببساطة نقل حسابات من القاعدة القديمة ونقلها إلى "قاعدة حسابات Google" الجديدة. أعتقد أنه لا يوجد شيء من هذا القبيل - فهناك العديد من الخدمات المتشابكة ومستويات التفاعل وسلاسل المسؤولية وخدمات إدارة الخدمات. على محمل الجد ، إذا فكرت في الأمر ، فيجب أن يكون هناك العديد من مستويات الاتصالات بين خدمات Google حتى يعمل كل شيء. ولكن بعد ذلك ، لا تسير الأمور على ما يرام - في محاولة لتعميم G + ، استخدم معرف المستخدم للمستخدمين الذين يشكلون جزءًا من خدمة SSO العالمية.
دعنا نعود إلى الأطروحة. هناك حاجة إلى إجراء تغييرات على واجهة برمجة التطبيقات الحالية من كل من الجانب الذي تم امتصاصه من واجهة برمجة التطبيقات ومن الخدمات الأخرى التي يمكن أن تبدأ الآن العمل مع الخدمة الجديدة. يبدو أنه لا يوجد شيء معقد للغاية - تكييف قاعدة المستخدمين الحالية للخدمة مع خدمات "google الشائعة" ، لإنشاء نقاط تفاعل مع خدمات أخرى حتى يتمكنوا من استخدام الخدمة الجديدة لأغراضهم الخاصة. ولكن هذا لا يتعلق بالمشروعات الصغيرة - شركة الخير لا تضيع الوقت على تفاهات وتمتص الشركات التي تقدر بملايين الدولارات ، والتي على الأرجح أنشأت بالفعل بنية تحتية - وإلا فإنها لا تستطيع أن تنمو إلى حد كبير. لذلك ، فمن المنطقي ترك قاعدة الكود الخاصة بها ، أو بالأحرى ، جوهر الخدمة ، وإعادة قنوات الإدخال والإخراج في روابط الخدمة بحيث تصبح متوافقة مع Google. ثم تصبح الخدمة خدمة Google. دعنا نفترض أنه في هذه اللحظة تم اختباره بالفعل ويعتبره جديرًا بالثقة من قِبل الأشخاص من Google المسؤولين عن التكامل. إليك الجزء الأكثر إثارة للاهتمام - يمكن دمج الخدمة في خدمات أخرى و / أو نقلها من خدمة إلى أخرى. بشكل عام ، لن يكون الأمر مخيفًا إذا لم يكن اتجاه Google لتغيير تسجيل الخدمات. خذ على سبيل المثال الصور.
تطبيق سطح المكتب Picasa (2002) => ألبومات الويب بيكاسا - تحصل Google على Picasa (2004) => Google Plus المدمجة Picasa (2011) => يتم فصل صور Google عن Google+ (2015) => ...
بالنظر إلى القصور الذاتي في عملية التكامل ، في معظم المنتجات ، لا تزال Google تدعم واجهات برمجة التطبيقات القديمة جدًا. في وقت نشر المقال ، كانت واجهة برمجة تطبيقات Picasa لا تزال تعمل بالطريقة التي عادت بها إلى الوقت الذي كانت فيه بيكاسا منتجًا منفصلاً. يقودنا ذلك إلى استنتاج مفاده أنه عندما قامت Google بدمج بيكاسا كخدمة لهم ، قاموا بإنشاء "فرع" من المنتج الأصلي وتركوا "الفرع" القديم تحت رحمة القدر ، لكنهم لم يغلقوا واجهة برمجة التطبيقات.
ثم حان الوقت لتذكر سبب إغلاق G +. حدث ذلك بسبب مشكلة أمنية تم الإبلاغ عنها ، ولكن في الواقع ، يمكن أن يكون هناك المزيد من مشكلات الأمان بسبب التناقض في واجهات برمجة التطبيقات المختلفة.
دليل على المفهوم
على سبيل المثال ، كانت هناك خدمة تسمى PicasaWeb - سلف صور Google . إنه غير متاح منذ عام 2016 ، لكن وفقًا للملاحظة في نهاية المنشور - لا تزال واجهة برمجة التطبيقات تعمل. تاريخ الانتهاء من هذا API هو 15 مارس 2019 . كانت هذه الخدمة جديرة بالملاحظة لأنها سمحت بالحصول على البريد الإلكتروني ومطابقة معرف المستخدم الداخلية. كيف ستكون مفيدة؟
في حال قمنا بتطوير مدقق البريد الإلكتروني . في هذه الحالة ، ستكون واجهة برمجة التطبيقات هذه من السماء. عند معرفة معرف الحساب من G + ، يمكننا الحصول على اسم المستخدم ، والصور ، وحتى المعلومات الإضافية. الحيلة هي أنه لا يمكنك الحصول على معرف المستخدم إذا لم يقم هذا المستخدم بتسجيل الدخول إلى موقعنا على الويب. ولكن على الرغم من ذلك ، تمكن المستخدمون من نشر الصور على ألبومات الويب التي تم ربطها بالبريد الإلكتروني باستخدام PicasaWebAlbums القديم. يشير ذلك إلى أن واجهة برمجة التطبيقات القديمة تسمح بالوصول إلى حساب المستخدم باستخدام معرف المستخدم أو البريد الإلكتروني للمستخدم.
دعونا نتحقق من: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io؟deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ - نقطة نهاية واجهة برمجة التطبيقات ؛
nosov@nodeart.io - البريد الإلكتروني للمستخدم للتحقق (كما نرى ، ليس مطلوبًا استخدام رسائل البريد الإلكتروني في Gmail فقط). لدى المستخدمين حسابات في Google Apps (تساعد هذه الحقيقة في أن يكون التحقق مفيدًا فيما يتعلق بتوليد العملاء المتوقعين) ، كما يمتلك المستخدمون الذين لديهم حسابات في Google+ هذا أيضًا (عن طريق ربط بريد إلكتروني تابع لجهة خارجية مسبقًا) ، على سبيل المثال ، Yandex.ru
deprecation-extension = true - إشارة حول نقطة نهاية API وشيكة.
إذا حاولنا تمرير بريد إلكتروني غير موجود ، فسوف نحصل على رد واضح ومفسر: "يتعذر العثور على مستخدم لديه بريد إلكتروني noname@nodeart.io ، مما يؤدي إلى استنتاج مفاده أن هذه الرسالة الإلكترونية غير صالحة. وأكثر من ذلك - إذا حاولنا إرسال عنوان بريدي جماعي إلى واجهة برمجة التطبيقات ، فستكون الإجابة "مستخدم غير معروف". سيكون من الممكن بعد ذلك التمييز بين رسائل البريد الإلكتروني الشخصية في G-Suite ورسائل البريد الإلكتروني للشركات. من الصعب القول أنه يمكننا "التقاط" البيانات الشخصية بهذه الطريقة إذا لم تتم مشاركة هذه البيانات من قبل المستخدم ، لكنها كانت جيدة للمصادقة العالمية على قائمة المستخدمين عبر واجهة برمجة التطبيقات.
إذاً ، كيف يتم ربط هذا الإيقاع بإغلاق + Google؟
الاستنتاجات
كان السبب الرئيسي لإغلاق + Google هو مرور الأمان ، وبشكل أكثر دقة ، القدرة على الحصول على البيانات من Google+ من خلال الخدمات التي لم يتم التخطيط لها والمقصودة مسبقًا.
إلى جانب Google+ ، يتم تنفيذ الإغلاق الجزئي لمختلف واجهات برمجة التطبيقات. على سبيل المثال ، يجب اجتياز التدقيق المدفوع للوصول إلى gmail.api مما يجعل واجهة برمجة التطبيقات هذه غير متاحة للغالبية العظمى من المطورين.
تنويه
يتم دفع رسوم التقييم من قِبل المطور وقد تتراوح بين 15000 دولار إلى 75000 دولار (أو أكثر) حسب حجم التطبيق وتعقيده.
في الواقع ، هذا يعطينا سببًا للاعتقاد بأن Google أصبحت متشابكة في نظام التفاعل بين الخدمات لأن الإجراءات التي كان يمكن تنفيذها سابقًا بمجرد الحصول على النطاق المطلوب ، تتطلب الآن التحقق اليدوي من 15 إلى 75 ألف دولار أمريكي والتضمين اليدوي في القائمة البيضاء. يبقى فقط تخمين ما يمكنك القيام به باستخدام ميزات غير موثقة للنظام البيئي الغني لخدمات Google وخدمة SSO بشكل خاص.
للتحقق من صحة القوائم البريدية من حيث النوعية ، سنحتاج إلى البحث عن طرق جديدة غير قياسية لاستخدام واجهات برمجة التطبيقات العامة ، لذلك سنستمر في استكشاف واجهة برمجة تطبيقات Google \ Facebook والخدمات الأخرى. (بالمناسبة ، كان لدى Facebook حتى وقت قريب طريقة مماثلة للتحقق من صحة البريد الإلكتروني.)