Halaman ini menjelaskan cara Identity-Aware Proxy (IAP) menangani permintaan dengan sesi yang berakhir dan cara memastikan permintaan aplikasi AJAX dan permintaan WebSocket berhasil.
Alur sesi IAP
Saat menggunakan alur login IAP standar, pengguna akan menerima cookie sesi yang mereferensikan sesi login Google-nya. IAP menggunakan cookie ini untuk mengonfirmasi bahwa pengguna masih login. IAP mengharuskan pengguna untuk login sebelum mengakses aplikasi yang diamankan oleh IAP.
Sesi IAP diperbarui secara berkala. Namun, jika pengguna menggunakan Akun Google untuk login, sesi IAP juga terikat dengan sesi login Google pengguna. Dalam hal ini, IAP hanya akan meminta pengguna untuk login lagi dalam salah satu situasi berikut:
- Pengguna logout dari akunnya
- Akunnya ditangguhkan
- Akun tersebut memerlukan reset sandi
Jika pengguna logout, IAP akan mendeteksi perubahan status Akun Google dalam beberapa menit. Setelah terdeteksi, IAP akan membatalkan sesi.
IAP memeriksa ulang otorisasi Identity and Access Management (IAM) untuk semua permintaan selama sesi yang valid. Perubahan pada kebijakan akses IAM aplikasi yang diamankan oleh IAP mungkin memerlukan waktu beberapa menit untuk diterapkan.
Masa berlaku sesi IAP
Untuk alur login menggunakan Akun Google, sesi IAP terikat dengan sesi login Google yang mendasarinya, dan hanya berakhir saat sesi tersebut berakhir, terlepas dari klaim exp dalam JWT yang dikirim di header otorisasi.
Untuk autentikasi terprogram,
IAP memang menghormati klaim exp dalam JWT yang dikirim di
header Otorisasi.
Untuk alur login Identity Platform, sesi IAP tetap valid hingga satu jam setelah pengguna logout.
Tombol login untuk Akun Google
Nilai loginHint yang ditetapkan melalui
IapSettings
harus cocok dengan domain pengguna login. Jika nilai ini tidak cocok, tombol login akan ditampilkan jika cookie IAP dihapus atau masa berlakunya berakhir.
Permintaan WebSocket
IAP hanya mendukung WebSocket untuk permintaan awal dan tidak terus-menerus memeriksa otorisasi. Saat diterima, permintaan WebSocket dimulai dengan permintaan Upgrade HTTP.
IAP mengevaluasi permintaan ini sebagai permintaan GET HTTP standar. Setelah permintaan diotorisasi, IAP akan meneruskan permintaan ke server, sehingga membuka koneksi persisten. Setelah itu, IAP tidak memantau permintaan atau memperbarui sesi.
Respons sesi yang berakhir
IAP menampilkan respons yang berbeda untuk sesi yang berakhir berdasarkan jenis permintaan.
Permintaan non-AJAX
Untuk permintaan non-AJAX, pengguna akan dialihkan ke alur login untuk memperbarui sesi. Jika pengguna masih login, pengalihan ini akan transparan.
Permintaan AJAX
Chrome dan browser lainnya menghentikan penggunaan cookie pihak ketiga secara bertahap. Rekomendasi untuk membuat permintaan AJAX di halaman ini tidak akan berfungsi jika cookie pihak ketiga dinonaktifkan. Namun, rekomendasi yang diberikan akan tetap berfungsi jika sumber dan target permintaan AJAX berasal dari situs yang sama.
Untuk mengetahui petunjuk tentang cara mengelola cookie pihak ketiga di Chrome, lihat Menghapus, mengizinkan dan mengelola cookie di Chrome.
IAP mengandalkan cookie untuk mengelola sesi pengguna. IAP juga mengandalkan urutan pengalihan untuk membuat sesi sebagai bagian dari alur login. Membuat sesi tidak selalu memungkinkan jika aplikasi menggunakan Cross-Origin Resource Sharing (CORS) untuk membuat permintaan AJAX ke aplikasi yang dilindungi oleh IAP.
Agar berhasil membuat permintaan CORS ke aplikasi yang dilindungi oleh IAP, sesi IAP harus dibuat di luar band. Perhatikan bahwa untuk permintaan AJAX yang mengirim permintaan CORS dari
source_domain->target_domain tempat target_domain menghosting aplikasi yang dilindungi oleh
IAP, harus ada sesi yang
dibuat di target_domain. Tidak ada cara untuk berbagi cookie antara source_domain dan target_domain.
Setelah sesi di target_domain dibuat, developer harus mengaktifkan kredensial untuk dikirim dalam permintaan. Secara default, metode JavaScript tidak melampirkan cookie ke permintaan. Untuk mengaktifkan kredensial dalam permintaan,
permintaan yang dikirim dengan
XMLHttpRequest
objek memerlukan properti withCredentials yang ditetapkan ke benar, sedangkan permintaan yang dikirim
dengan
Fetch API
memerlukan opsi credentials yang ditetapkan ke include atau same-origin.
Panduan berikut merekomendasikan pola bagi developer web agar dapat membuat dan memperbarui sesi IAP dengan berhasil.
Memahami respons IAP
Untuk permintaan AJAX, IAP menampilkan kode status HTTP 401: Unauthorized. Perhatikan bahwa deteksi permintaan AJAX tidak dapat dilakukan dengan sempurna. Jika
Anda mendapatkan respons kode status 302 dan bukan kode status 401 untuk
permintaan AJAX, header X-Requested-With dengan nilai "XMLHttpRequest"
dapat ditambahkan ke permintaan AJAX. Hal ini memberi tahu IAP bahwa permintaan berasal dari JavaScript.
Menangani respons AJAX HTTP 401
Untuk membuat sesi IAP setelah aplikasi menerima
HTTP 401, aplikasi dapat membuka jendela baru untuk URL
target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Ini adalah pengendali khusus yang hanya membuat sesi IAP di target_domain. Jika jendela tetap terbuka, sesi akan terus diperbarui secara berkala, dan meminta input pengguna jika diperlukan.
Secara opsional, pengguna dapat memilih untuk menutup jendela, dan pengendali untuk status HTTP 401 dalam kode developer akan menampilkan jendela lagi untuk memperbarui sesi jika diperlukan.
Langkah 1: Ubah kode aplikasi Anda
Contoh berikut menunjukkan cara mengubah kode aplikasi untuk menangani kode status HTTP 401 dan memberikan link pembaruan sesi kepada pengguna:
Langkah 2: Instal pengendali onclick
Contoh kode di bawah menginstal pengendali onclick yang menutup jendela setelah sesi diperbarui: