Halaman ini menjelaskan cara Identity-Aware Proxy (IAP) menangani permintaan dengan sesi yang telah berakhir dan cara memastikan bahwa 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 mereka. IAP menggunakan cookie ini untuk mengonfirmasi bahwa pengguna masih login. IAP mengharuskan pengguna untuk login sebelum mengakses aplikasi yang diamankan IAP.
Sesi IAP diperbarui secara berkala. Namun, jika pengguna menggunakan Akun Google untuk login, sesi IAP juga akan terikat dengan sesi login Google pengguna. Dalam hal ini, IAP hanya akan mewajibkan pengguna untuk login lagi dalam salah satu situasi berikut:
- Pengguna logout dari akunnya
- Akunnya ditangguhkan
- Akun 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. Pembaruan pada kebijakan akses IAM aplikasi yang diamankan IAP mungkin memerlukan waktu beberapa menit untuk diterapkan.
Masa berlaku sesi IAP
Untuk alur login yang menggunakan Akun Google, sesi IAP
terikat dengan sesi login Google yang mendasarinya, dan hanya berakhir masa berlakunya saat
sesi tersebut berakhir, terlepas dari klaim exp
dalam JWT yang dikirim dalam
header otorisasi.
Untuk autentikasi terprogram,
IAP mematuhi klaim exp
dalam JWT yang dikirim dalam
header Otorisasi.
Untuk alur login Identity Platform, sesi IAP tetap valid hingga satu jam setelah pengguna logout.
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 mengevaluasinya sebagai
permintaan GET
HTTP standar. Setelah permintaan diotorisasi, IAP
akan meneruskan permintaan ke server, yang akan membuka koneksi persisten. Setelah ini,
IAP tidak memantau permintaan atau memuat ulang sesi.
Respons sesi yang telah berakhir
IAP menampilkan respons yang berbeda untuk sesi yang telah berakhir berdasarkan jenis permintaan.
Permintaan non-AJAX
Untuk permintaan non-AJAX, pengguna akan dialihkan ke alur login untuk memuat ulang sesi. Jika pengguna masih login, pengalihan ini akan transparan.
Permintaan AJAX
Chrome dan browser lain menghentikan penggunaan cookie pihak ketiga. 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 petunjuk tentang cara mengelola cookie pihak ketiga di Chrome, lihat Menghapus, mengizinkan, dan mengelola cookie di Chrome.
IAP mengandalkan cookie untuk mengelola sesi pengguna. Fitur ini juga bergantung pada urutan pengalihan untuk membuat sesi sebagai bagian dari alur login. Menetapkan sesi tidak selalu dapat dilakukan jika aplikasi menggunakan Cross-Origin Resource Sharing (CORS) untuk membuat permintaan AJAX ke aplikasi yang dilindungi IAP.
Agar berhasil membuat permintaan CORS ke aplikasi yang dilindungi 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 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 perlu
mengaktifkan kredensial untuk dikirim dalam permintaan. Secara default, metode JavaScript
tidak melampirkan cookie ke permintaan. Untuk mengaktifkan kredensial dalam permintaan,
permintaan yang dikirim dengan objek
XMLHttpRequest
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 memuat ulang sesi IAP dengan sukses.
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
, 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 401
HTTP
Untuk membuat sesi IAP setelah aplikasi menerima
401
HTTP, 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
dipertahankan sebagai terbuka, jendela akan terus memuat ulang sesi secara berkala, meminta
input pengguna sesuai kebutuhan.
Secara opsional, pengguna dapat memilih untuk menutup jendela, dan pengendali untuk status 401
HTTP dalam kode developer akan memunculkan jendela lagi untuk memuat ulang sesi sesuai kebutuhan.
Langkah 1: Ubah kode aplikasi
Contoh berikut menunjukkan cara mengubah kode aplikasi untuk menangani kode status 401
HTTP dan memberikan link refresh sesi kepada pengguna:
Langkah 2: Instal pengendali onclick
Kode contoh di bawah ini menginstal pengendali onclick yang menutup jendela setelah sesi dimuat ulang: