Google menutup platform media sosial mereka Google+ pada 2 April 2019. Sulit untuk menemukan beberapa artikel teknis yang belum menyebutkan akhir era jejaring sosial Google. Tetapi, tingkat konsistensi yang tinggi dalam konektivitas dalam layanan perusahaan telah menerima sedikit perhatian. Dalam artikel ini saya ingin berbagi pemikiran saya tentang cara internal konsistensi layanan Google dan apa artinya bagi pengguna Google API ketika datang ke Google+ shutdown.
Dari sudut pandang klien, penggunaan Foto Gmail dan perubahan lebih lanjut ke Documents harus sejelas mungkin - pada pandangan pertama, layanan ini independen dan bersatu dalam satu platform yang merupakan titik akses yang disebut accounts.google.com . Tetapi sebagai pengembang, kita tahu, bahwa istilah "shutdown", "takeover", "integrate" melibatkan makna yang hebat (dan juga bekerja) bagi orang-orang yang mengambil bagian dalam proses ini. Jadi, mari kita lihat lebih dekat pada proses pengambilalihan salah satu layanan eksternal Google, dan apa yang terjadi dengan API layanan pengambilalihan dan Google API.
Akun dan ID pengguna
Selain pengguna yang menggunakan Gmail dan mungkin mendengar tentang Google Plus, ada juga sejumlah besar API untuk pengembang yang mencakup hal-hal seperti pengidentifikasi akun, ID pengguna terkenal. UserID adalah ID internal Google, ini adalah hal yang membantu layanan Google memahami siapa. Itu muncul di banyak API, dan kami melihat bahwa itu tidak berubah dari satu layanan ke layanan lainnya.
Kekacauan
Jelas, untuk implementasi SSO dalam layanan yang baru diserap, Anda tidak bisa begitu saja mengambil dan mentransfer akun dari basis lama ke "basis akun Google" yang baru. Saya pikir tidak ada hal seperti itu - ada banyak layanan yang saling terkait, tingkat interaksi, rantai tanggung jawab, layanan manajemen layanan. Serius, jika Anda memikirkannya, maka harus ada banyak, banyak, banyak tingkat koneksi antara layanan Google agar semuanya berfungsi. Tapi kemudian semuanya berjalan tidak begitu lancar - dalam upaya untuk mempopulerkan G + itu menggunakan userID pengguna yang merupakan bagian dari layanan SSO global.
Mari kita kembali ke tesis. Ada kebutuhan untuk membuat perubahan pada API yang ada dari sisi yang diserap API dan dari layanan lain yang sekarang dapat mulai bekerja dengan layanan baru. Tampaknya tidak ada yang super rumit - untuk mengadaptasi basis pengguna layanan yang ada dengan layanan "google umum", untuk membuat titik interaksi dengan layanan lain sehingga mereka dapat menggunakan layanan baru untuk tujuan mereka sendiri. Tetapi ini bukan tentang proyek-proyek kecil - sebuah perusahaan barang tidak membuang waktu untuk hal-hal sepele dan menyerap perusahaan jutaan dolar, yang, kemungkinan besar, telah membangun infrastruktur - jika tidak, mereka tidak dapat tumbuh dengan skala mereka. Jadi, masuk akal untuk meninggalkan basis kode, atau lebih tepatnya, inti dari layanan, dan mengulang saluran input-output dari tautan layanan sehingga mereka menjadi kompatibel dengan Google. Kemudian layanan menjadi layanan Google. Misalkan pada saat ini sudah diuji dan dianggap cukup dapat dipercaya oleh orang-orang dari Google yang bertanggung jawab untuk integrasi. Inilah bagian yang paling menarik - layanan dapat diintegrasikan ke dalam layanan lain dan / atau ditransfer dari layanan ke layanan. Secara umum, itu tidak akan menakutkan jika bukan karena kecenderungan Google untuk mengubah pendaftaran layanan. Ambil contoh foto.
Aplikasi desktop Picasa (2002) => Album Web Picasa - Google mengakuisisi Picasa (2004) => Google Plus memasukkan Picasa (2011) => Foto Google dipisahkan dari Google+ (2015) => ...
Mempertimbangkan inersia proses integrasi, di sebagian besar produk, Google masih mendukung API yang sangat lama. Pada saat publikasi artikel, Picasa API masih berfungsi seperti dulu ketika Picasa merupakan produk terpisah. Itu membawa kita pada kesimpulan bahwa ketika Google mengintegrasikan Picasa sebagai layanan mereka berikutnya, mereka menciptakan "cabang" dari produk asli dan meninggalkan "cabang" lama itu ke tangan nasib, tetapi tidak mematikan API-nya.
Dan sekarang saatnya untuk mengingat alasan penutupan G +. Itu terjadi karena masalah keamanan yang dilaporkan, tetapi dalam kenyataannya, bahkan ada lebih banyak masalah keamanan karena ketidakkonsistenan dalam API yang berbeda.
Bukti konsep
Misalnya, ada layanan bernama PicasaWeb - pendahulu Foto Google . Ini tidak tersedia sejak 2016 tetapi menurut catatan di akhir posting - API-nya masih beroperasi. Tanggal akhir API ini adalah 15 Maret 2019 . Layanan ini patut diperhatikan karena memungkinkan mendapatkan kecocokan email dan userID internal. Apa manfaatnya?
Jika kami mengembangkan validator email . Dalam hal ini, API ini akan menjadi manna dari surga. Mengetahui ID Akun dari G + kita bisa mendapatkan nama pengguna, foto, dan bahkan informasi tambahan. Caranya adalah Anda tidak bisa mendapatkan ID pengguna jika pengguna ini tidak pernah masuk ke situs web kami. Namun, meskipun demikian, pengguna dapat memposting gambar di album web yang ditautkan dengan email menggunakan PicasaWebAlbums lama. Itu menyarankan bahwa API lama memungkinkan untuk masuk ke akun pengguna menggunakan userID atau email pengguna.
Mari kita periksa: https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
https://picasaweb.google.com/data/feed/api/user/ - titik akhir API;
nosov@nodeart.io - email pengguna untuk verifikasi (seperti yang dapat kita lihat, tidak perlu menggunakan email Gmail saja). Pengguna memiliki akun Google Apps (fakta ini membantu verifikasi berguna mengenai pembuatan prospek), pengguna dengan akun Google+ juga memiliki ini (dengan menautkan email pihak ketiga sebelumnya), misalnya, Yandex.ru
deprecation-extension = true - indikasi tentang titik akhir API yang akan segera terjadi.
Jika kami akan mencoba mengirimkan email yang tidak ada , kami akan mendapatkan respons yang jelas: “Tidak dapat menemukan pengguna dengan email noname@nodeart.io, yang mengarah pada kesimpulan bahwa email ini tidak valid. Dan bahkan lebih - jika kami akan mencoba mengirim alamat surat grup ke API jawabannya adalah "Pengguna tidak dikenal". Maka akan mungkin untuk membedakan perbedaan antara email pribadi G-Suite dan email perusahaan. Sulit untuk mengatakan bahwa kita dapat "menangkap" data pribadi dengan cara ini jika data ini tidak dibagikan oleh pengguna, tetapi itu bagus untuk validasi global daftar pengguna melalui API.
Jadi, bagaimana ketidaktepatan ini terkait dengan penutupan Google?
Kesimpulan
Alasan utama untuk mematikan Google+ adalah kesalahan keamanan, lebih tepatnya, kemampuan untuk mendapatkan data dari Google+ oleh layanan yang tidak direncanakan dan dimaksudkan sebelumnya.
Selain Google+, pematian sebagian dari berbagai API dilakukan. Misalnya, Anda harus lulus audit berbayar untuk mendapatkan akses ke gmail.api yang membuat API ini tidak tersedia untuk sebagian besar pengembang.
Kutipan
Biaya penilaian dibayar oleh pengembang dan dapat berkisar dari $ 15.000 hingga $ 75.000 (atau lebih) tergantung pada ukuran dan kompleksitas aplikasi.
Bahkan, ini memberi kita alasan untuk berpikir bahwa Google telah menjadi terjerat dalam sistem interaksi antara layanan karena tindakan yang sebelumnya dapat dilakukan hanya dengan memperoleh ruang lingkup yang diperlukan, sekarang memerlukan validasi manual untuk 15-75 ribu USD dan penyertaan manual dalam daftar putih. Tetap hanya untuk menebak apa lagi yang dapat Anda lakukan dengan menggunakan fitur tak terdokumentasi ekosistem kaya Google layanan dan layanan SSO pada khususnya.
Untuk memvalidasi milis secara kualitatif , kami akan perlu mencari cara baru non-standar penggunaan API publik, jadi kami akan terus mengeksplorasi Google \ Facebook API dan layanan lainnya. (Omong-omong, Facebook hingga saat ini memiliki cara yang sama untuk validasi email.)