توقف Google Plus عن العمل. ماذا بعد؟

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

بالنسبة إلى المستخدم النهائي ، يجب أن يكون الانتقال من Gmail إلى الصور ، ومن هناك إلى المستندات ، سلسًا قدر الإمكان - في لمحة سريعة تكون الخدمات مستقلة وموحدة بواسطة نقطة دخول خدمة مفردة مصقولة للغاية. accounts.google.com . لكننا كمطورين نعلم أن الكلمات "close" ، "الامتصاص" ، "التكامل" تحمل معنى أكبر (والمزيد من العمل) للأشخاص الذين يقومون بتطوير منتج ما مما قد يبدو للوهلة الأولى. دعنا ندرس بشكل سطحي كيف يتم ترتيب عملية استيعاب Google لأحد الخدمات الخارجية وما يحدث مع واجهة برمجة التطبيقات للخدمة و Google API.

حسابات ومعرف المستخدم

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

لنأخذ مثالاً على امتصاص خدمة خارجية من قِبل Google

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

ولكن بعد ذلك لا تسير الأمور بسلاسة - في محاولة لتعميم G + ، استخدمت مستخدمي userID الذين هم جزء من خدمة SSO العالمية.

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

بعد ذلك ، تصبح الخدمة خدمة Google. دعنا نقول أنه في هذه المرحلة تم اختباره بالفعل واعتبره أشخاصًا جديرين بالثقة تمامًا من Google ، مسئول عن التكامل. تبدأ المتعة - يمكن دمج الخدمة في خدمات أخرى و / أو نقلها من خدمة إلى أخرى.
بشكل عام ، لن يكون هذا مخيفًا إذا لم يكن ميل Google إلى تغيير تسجيل الخدمات.
خذ على سبيل المثال الصور.

تطبيق سطح المكتب Picasa (2002) => ألبومات الويب بيكاسا - تحصل Google على Picasa (2004) => يدمج Google Plus Picasa (2011) => يتم فصل صور Google عن G + (2015) => ...

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

ثم حان الوقت لتذكر سبب إغلاق G +. مشاكل الأمان المبلغ عنها ، في الواقع ، قد تكون هناك مشكلات أمنية أكثر ترجيحًا بسبب عدم تناسق واجهات برمجة التطبيقات المختلفة.

دليل على المفهوم

على سبيل المثال ، بمجرد وجود خدمة PicasaWeb ، مثل سلف صور Google الحديثة. تم إيقافه في عام 2016 . ولكن وفقًا لسجل الحاشية في نهاية المنشور ، فإن واجهة برمجة التطبيقات للخدمة قد استمرت في العمل حتى الآن. يوجد بالفعل تاريخ انتهاء لواجهة برمجة التطبيقات هذه للعمل - 15 مارس 2019 . هذه الخدمة جديرة بالملاحظة لأنها تتيح لك الحصول على مراسلات البريد الإلكتروني ومعرف المستخدم الداخلي. كيف يمكن أن يكون هذا مفيدا لنا؟

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

ولكن في PicasaWebAlbums القديمة ، يمكن للأشخاص نشر الصور على ألبومات الويب المرتبطة بالبريد الإلكتروني. في الواقع ، يستنتج من ذلك أن API القديمة تسمح لك بالحصول على ملف تعريف الشخص عن طريق معرف المستخدم أو البريد الإلكتروني للمستخدم.

لنفحص:
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 ملفات شخصية (مما يجعل مثل هذا الفحص مفيدًا جدًا لتوليد العملاء المتوقعين) ، وكذلك الأشخاص الذين قاموا بإنشاء ملف تعريف على Google+ عن طريق ربطه بصندوق بريد شخصي لخدمة ثالثة ، على سبيل المثال ، Yandex.ru؛
- إهمال الامتداد = صواب - إشارة إلى ما نعرفه عن النهاية الوشيكة لواجهة برمجة التطبيقات.

إذا حاولنا نقل رسالة بريد إلكتروني غير موجودة ، فسوف نحصل على رد واضح التفسير غير قادر على العثور على مستخدم لديه بريد إلكتروني noname@nodeart.io ، يمكننا أن نستنتج منه بشكل قاطع أنه لا يوجد مثل هذا البريد الإلكتروني. وأكثر من ذلك - إذا حاولنا إرسال عنوان مجموعة التوزيع إلى API ، فستتغير الاستجابة إلى مستخدم غير معروف. وبهذه الطريقة ، يمكنك التمييز بين صناديق البريد الشخصية في G Suite ووكلاء بريد الشركات.

هذا لا يعني أنه من الممكن سحب المعلومات الشخصية للشخص إذا لم ينشرها بشكل صريح ، ولكن من أجل التحقق الشامل من القوائم البريدية ، كانت مثل واجهة برمجة التطبيقات مناسبة جدًا

كيف يرتبط ثقب الفرصة هذا بإغلاق G +؟ النتائج

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

الآن ، بالإضافة إلى إغلاق G + ، هناك إغلاق جزئي لواجهات برمجة التطبيقات المختلفة. على سبيل المثال ، للوصول إلى gmail.api ، يلزمك الآن مراجعة تدقيق مدفوع قيمته من 15 إلى 75 ألف دولار ، مما يجعل واجهة برمجة التطبيقات هذه غير قابلة للوصول لمعظم المطورين. اقتباس:

يتم دفع رسوم التقييم من قِبل المطور وقد تتراوح بين 15000 دولار إلى 75000 دولار (أو أكثر) حسب حجم التطبيق وتعقيده.

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

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