Permintaan HTTP berisi header seperti User-Agent atau Content-Type. Selain {i>header<i} yang dilampirkan oleh
browser, aplikasi Android dapat menambahkan {i>header<i} ekstra, seperti Cookie atau Perujuk melalui
EXTRA_HEADERS
Intent tambahan. Untuk alasan keamanan, Chrome memfilter beberapa header tambahan
bergantung pada bagaimana dan di mana intent diluncurkan.
Permintaan lintas asal memerlukan lapisan keamanan tambahan karena klien dan server tidak dimiliki oleh pihak yang sama. Panduan ini membahas peluncuran permintaan tersebut melalui Chrome tab kustom, yaitu intent yang diluncurkan dari aplikasi yang membuka URL di tab browser. Hingga Chrome 83, developer dapat menambahkan header apa pun saat meluncurkan Tab Khusus. Mulai versi 83 dan seterusnya, Chrome mulai memfilter semua kecuali header lintas origin yang disetujui, karena header yang tidak disetujui menimbulkan risiko keamanan. Mulai Chrome 86, Anda dapat melampirkan header yang tidak disetujui ke permintaan lintas origin, saat server dan klien terkait menggunakan digital asset link. Perilaku ini diringkas dalam tabel berikut:
Versi Chrome | Header CORS diizinkan |
---|---|
sebelum Chrome 83 | disetujui, tidak disetujui |
Chrome 83 hingga Chrome 85 | disetujui |
mulai Chrome 86 dan seterusnya | disetujui, tidak disetujui saat link aset digital disiapkan |
Tabel 1.: Pemfilteran header CORS yang tidak disetujui.
Artikel ini menunjukkan cara menyiapkan koneksi terverifikasi antara server dan klien serta menggunakannya untuk mengirim header http yang disetujui serta yang tidak disetujui. Anda dapat langsung ke Menambahkan Header Tambahan ke Intent Tab Khusus untuk kode.
Latar belakang
Header Permintaan CORS yang disetujui vs. Tidak disetujui
Cross-Origin Resource Sharing (CORS) memungkinkan aplikasi web dari satu asal untuk melakukan permintaan resource dari origin yang berbeda. Daftar header yang disetujui CORS disimpan di Standar HTML. Contoh header yang disetujui ditampilkan di tabel berikutnya:
Header | Deskripsi |
---|---|
accept-language | mengiklankan bahasa alami yang dipahami klien |
content-language | menjelaskan bahasa yang ditujukan untuk audiens saat ini |
jenis konten | menunjukkan jenis media dari |
Tabel 2.: Contoh header CORS yang disetujui.
Header yang disetujui dianggap aman karena tidak berisi informasi sensitif informasi pengguna dan kemungkinan tidak menyebabkan server melakukan operasi yang berpotensi merusak.
Contoh header yang tidak disetujui ditampilkan dalam tabel berikut:
Header | Deskripsi |
---|---|
bearer-token | mengotentikasi klien di server |
asal | menunjukkan asal permintaan |
kue | berisi cookie yang ditetapkan oleh server |
Tabel 3.: Contoh header CORS yang tidak disetujui.
Standar HTML dan server tidak menyertakan header yang tidak disetujui ke permintaan CORS mengasumsikan bahwa permintaan lintas asal hanya berisi header yang disetujui. Mengirim header yang tidak disetujui dari domain lintas origin akan memungkinkan aplikasi pihak ketiga yang berbahaya membuat header yang menyalahgunakan cookie yang disimpan dan dilampirkan oleh Chrome (atau browser lain) ke permintaan. Cookie tersebut dapat mengotentikasi transaksi server berbahaya yang tidak mungkin dilakukan.
Melampirkan header CORS yang disetujui ke permintaan Tab Khusus
Tab Khusus adalah cara khusus untuk meluncurkan halaman web di tab browser khusus. Tab Khusus
intent dapat dibuat menggunakan CustomTabsIntent.Builder()
. Anda juga dapat melampirkan
{i>header <i}ke
intent menggunakan Bundle
dengan flag Browser.EXTRA_HEADERS
:
CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();
Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));
Kami dapat melampirkan header yang disetujui ke permintaan CORS tab khusus kapan saja. Namun, filter Chrome header yang tidak disetujui secara default. Meskipun {i>browser<i} lain mungkin memiliki perilaku yang berbeda, developer akan memblokir header yang tidak disetujui secara umum.
Cara yang didukung untuk menyertakan header yang tidak disetujui di tab khusus adalah dengan memverifikasi terlebih dahulu koneksi lintas origin menggunakan link akses digital. Bagian berikutnya menunjukkan cara menyetel dan luncurkan intent Tab Khusus dengan header yang diperlukan.
Menambahkan Header Tambahan ke Intent Tab Khusus
Menyiapkan link aset digital
Untuk mengizinkan header yang tidak disetujui diteruskan melalui intent Tab Khusus, Anda perlu menetapkan tautan aset digital antara aplikasi Android dan web yang memverifikasi bahwa pembuat memiliki kedua aplikasi tersebut.
Ikuti panduan resmi untuk menyiapkan link aset digital. Untuk penggunaan relasi tautan "delegate_permission/common.use_as_origin"` yang menunjukkan bahwa kedua aplikasi dimiliki oleh domain yang sama setelah tautan diverifikasi.
Membuat Intent Tab Khusus dengan Header Tambahan
Ada beberapa cara untuk membuat intent Tab Khusus. Anda dapat menggunakan builder yang tersedia di androidX dengan menambahkan library ke dependensi build:
MULTI_LINE_CODE_PLACEHOLDER_1
Buat intent dan tambahkan header ekstra:
MULTI_LINE_CODE_PLACEHOLDER_2
Menyiapkan Koneksi Tab Khusus untuk Memvalidasi Link Aset
Koneksi Tab Khusus digunakan untuk menyiapkan CustomTabsSession
antara aplikasi dan
Tab Chrome. Kita memerlukan sesi tersebut untuk memverifikasi bahwa aplikasi dan aplikasi web berasal dari origin yang sama.
Verifikasi hanya berhasil jika link aset digital disiapkan dengan benar.
Sebaiknya panggil CustomTabsClient.warmup()
. Hal ini memungkinkan
aplikasi {i>browser<i} untuk
pra-inisialisasi di latar belakang dan
mempercepat proses pembukaan URL.
MULTI_LINE_CODE_PLACEHOLDER_3
Menyiapkan Callback yang Meluncurkan Intent setelah Validasi
CustomTabsCallback
diteruskan ke sesi. Kami menyiapkan
onRelationshipValidationResult()
untuk meluncurkan CustomTabsIntent
yang dibuat sebelumnya
setelah verifikasi origin berhasil.
MULTI_LINE_CODE_PLACEHOLDER_4
Mengikat koneksi layanan tab khusus
Mengikat layanan akan meluncurkan layanan dan onCustomTabsServiceConnected()
koneksi
pada akhirnya akan dipanggil. Jangan lupa untuk memisahkan layanan dengan benar. Mengikat dan melepas ikatan
biasanya dilakukan dalam metode siklus proses aktivitas onStart()
dan onStop()
.
// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
CustomTabsClient.getPackageName(MainActivity.this, null), connection);
// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);
Kode aplikasi demo
Anda dapat menemukan detail selengkapnya tentang Layanan Tab Khusus di sini. Lihat Repositori GitHub android-browser-helper untuk aplikasi contoh yang berfungsi.
Ringkasan
Panduan ini mendemonstrasikan cara menambahkan header arbitrer ke permintaan CORS tab khusus. header yang disetujui dapat dilampirkan ke setiap permintaan CORS tab kustom. Header yang tidak disetujui akan umumnya dianggap tidak aman dalam permintaan CORS dan chrome memfilternya secara default. Melampirkannya adalah hanya diizinkan untuk klien dan server yang asalnya sama, diverifikasi dengan link aset digital.