1. Ikhtisar
Plug-in kontrol akses berbasis parameter memungkinkan Anda mendefinisikan kondisi untuk menyaring permintaan yang dikirim ke layanan backend berdasarkan parameter permintaan atau konteks dari sebuah API. Untuk informasi lebih lanjut tentang cara mendefinisikan parameter dan menggunakan ekspresi kondisional, lihat Gunakan Parameter dan Ekspresi Kondisional.
2. Konfigurasi
Asumsikan bahwa jalur permintaan API adalah /{userId}/... dan otentikasi JSON Web Token (JWT) diaktifkan untuk API tersebut. Dua klaim, userId dan userType, tersedia dalam JWT. Kondisi filter berikut berlaku:
Jika userType disetel ke admin, permintaan di semua jalur diperbolehkan.
Jika userType disetel ke user, hanya permintaan di jalur /{userId} yang sama yang diperbolehkan.
---
#
# Dalam contoh ini, jalur permintaan API adalah `/{userId}/...
# Otentikasi JWT diaktifkan untuk API. Dua klaim, userId dan userType, tersedia dalam JWT.
# Kondisi filter berikut berlaku:
# - Jika userType disetel ke admin, permintaan di semua jalur diperbolehkan.
# - Jika userType disetel ke user, hanya permintaan dengan jalur `/{userId}/...` yang diperbolehkan.
parameters:
userId: "Token:userId"
userType: "Token:userType"
pathUserId: "path:userId"
#
# Aturan didefinisikan berdasarkan parameter sebelumnya. Untuk setiap permintaan API, plug-in memeriksa aturan secara berurutan. Jika suatu kondisi dalam aturan terpenuhi, hasilnya adalah true dan tindakan yang ditentukan oleh ifTrue dilakukan. Jika suatu kondisi dalam aturan tidak terpenuhi, hasilnya adalah false dan tindakan yang ditentukan oleh ifFalse dilakukan.
# Tindakan ALLOW menunjukkan bahwa permintaan diperbolehkan. Tindakan DENY menunjukkan bahwa permintaan ditolak dan kode kesalahan dikembalikan ke klien. Setelah tindakan ALLOW atau DENY dilakukan, plug-in tidak memeriksa kondisi yang tersisa.
# Jika baik tindakan ALLOW maupun DENY tidak dilakukan, plug-in melanjutkan untuk memeriksa kondisi berikutnya.
rules:
- name: admin
condition: "$userType = 'admin'"
ifTrue: "ALLOW"
- name: user
condition: "$userId = $pathUserId"
ifFalse: "DENY"
statusCode: 403
errorMessage: "Path tidak cocok ${userId} vs /${pathUserId}"
responseHeaders:
Content-Type: application/xml
responseBody:
<Reason>Path tidak cocok ${userId} vs /${pathUserId}</Reason>3. Gunakan dataset plug-in dalam sebuah plug-in
Untuk informasi lebih lanjut tentang cara mengonfigurasi plug-in kontrol akses berbasis parameter, lihat Plug-in Kontrol Akses Berbasis Parameter.
3.1. Buat dataset plug-in
Masuk ke konsol API Gateway. Di panel navigasi di sebelah kiri, pilih . Pada halaman Daftar Plug-in, klik tab Plug-in Datasets dan klik Create Dataset. Dalam kotak dialog Buat Dataset, pilih PARAMETER_ACCESS dari daftar drop-down Type.

Setelah membuat dataset, Anda dapat mengklik ID dataset untuk melihat dan menambahkan entri data. Plug-in kontrol akses berbasis parameter yang mereferensikan dataset ini menggunakan entri data untuk menyaring permintaan. Anda juga dapat mengatur periode validitas untuk entri data. Entri data menjadi tidak efektif ketika periode validitas berakhir.

Dataset plug-in hanya berlaku untuk instans khusus. Jika API tempat plug-in terikat tidak diterapkan pada instans khusus, dataset yang dikonfigurasikan untuk plug-in tidak akan berlaku.
3.2. Konfigurasikan dataset untuk plug-in kontrol akses berbasis parameter
Untuk mengonfigurasikan dataset untuk plug-in kontrol akses berbasis parameter, Anda harus menambahkan bidang assertParameterName dan assertInDataset ke bagian rules dari konfigurasi Plug-in Kontrol Akses Berbasis Parameter.
assertParameterName: Nama parameter yang akan digunakan oleh plug-in untuk menyaring permintaan. Nama tersebut harus didefinisikan di bagian parameters.
assertInDataset: ID dataset. Plug-in memeriksa apakah nilai parameter yang ditentukan dalam assertParameterName termasuk dalam dataset.
Bidang assertParameterName dan assertInDataset harus digunakan bersama-sama. Jika tidak, plug-in gagal dibuat.
Kedua bidang tersebut kompatibel dengan parameter condition. Untuk setiap aturan yang ditentukan dalam bagian rules, Anda dapat menentukan pasangan assertParameterName + assertInDataset atau condition, atau keduanya. Jika keduanya dikonfigurasikan, permintaan ditolak jika memenuhi salah satu kondisi.
---
#
# Dalam contoh ini, jalur permintaan API adalah `/{userId}/...
# Otentikasi JWT diaktifkan untuk API. Dua klaim, userId dan userType, tersedia dalam JWT.
# Kondisi filter berikut berlaku:
# - Jika userType disetel ke admin, permintaan di semua jalur diperbolehkan.
# - Jika userType disetel ke user, hanya permintaan dengan jalur `/{userId}/...` yang diperbolehkan.
parameters:
userId: "Token:userId"
userType: "Token:userType"
pathUserId: "path:userId"
#
# Aturan didefinisikan berdasarkan parameter sebelumnya. Untuk setiap permintaan API, plug-in memeriksa aturan secara berurutan. Jika suatu kondisi dalam aturan terpenuhi, hasilnya adalah true dan tindakan yang ditentukan oleh ifTrue dilakukan. Jika suatu kondisi dalam aturan tidak terpenuhi, hasilnya adalah false dan tindakan yang ditentukan oleh ifFalse dilakukan.
# Tindakan ALLOW menunjukkan bahwa permintaan diperbolehkan. Tindakan DENY menunjukkan bahwa permintaan ditolak dan kode kesalahan dikembalikan ke klien. Setelah tindakan ALLOW atau DENY dilakukan, plug-in tidak memeriksa kondisi yang tersisa.
# Jika baik tindakan ALLOW maupun DENY tidak dilakukan, plug-in melanjutkan untuk memeriksa kondisi berikutnya.
rules:
- name: byDataset
assertParameterName: userId
assertInDataset: 87b65008e92541938537b1a4a236eda5
ifTrue: "ALLOW"
- name: admin
condition: "$userType = 'admin'"
ifTrue: "ALLOW"
- name: user
condition: "$userId = $pathUserId"
ifFalse: "DENY"
statusCode: 403
errorMessage: "Path tidak cocok ${userId} vs /${pathUserId}"
responseHeaders:
Content-Type: application/xml
responseBody:
<Reason>Path tidak cocok ${userId} vs /${pathUserId}</Reason>4. Kode kesalahan
Kode kesalahan | Kode status HTTP | Pesan | Deskripsi |
A403AC | 403 | Akses Kontrol Dilarang oleh ${RuleName} | Pesan kesalahan yang dikembalikan karena permintaan ditolak oleh plug-in kontrol akses berbasis parameter yang terikat pada API. |
5. Batasan
Maksimum 160 parameter dapat didefinisikan.
Setiap ekspresi kondisional dapat berisi maksimum 1.024 karakter.
Setiap plug-in dapat berisi maksimum 50 KB metadata.
Maksimum 160
aturandapat dikonfigurasikan di setiap plug-in kontrol akses berbasis parameter.