Atur ACL Antrean

Artikel
12/14/2024

Operasi Set Queue ACL menetapkan kebijakan akses tersimpan untuk antrean yang dapat digunakan dengan SAS (tanda tangan akses bersama). Untuk informasi selengkapnya, lihat Menentukan kebijakan akses tersimpan.

Nota

Operasi Set Queue ACL tersedia di versi 2012-02-12 dan yang lebih baru.

Minta

Anda dapat membuat permintaan Set Queue ACL sebagai berikut. Kami menyarankan agar Anda menggunakan HTTPS. Ganti myaccount dengan nama akun penyimpanan Anda:

Metode	Meminta URI	Versi HTTP
`PUT`	`https://myaccount.queue.core.windows.net/myqueue?comp=acl`	HTTP/1.1

Permintaan layanan penyimpanan yang ditimulasi

Saat Anda membuat permintaan terhadap layanan penyimpanan yang ditimulasi, tentukan nama host emulator dan port layanan Antrean sebagai 127.0.0.1:10001, diikuti dengan nama akun penyimpanan yang ditimulasi:

Metode	Meminta URI	Versi HTTP
`PUT`	`http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl`	HTTP/1.1

Untuk informasi selengkapnya, lihat Menggunakan emulator Azurite untuk pengembangan Azure Storage lokal.

Parameter URI

Anda dapat menentukan parameter tambahan berikut pada URI permintaan:

Parameter	Deskripsi
`timeout`	Fakultatif. Parameter `timeout` dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi layanan Antrean.

Header permintaan

Header permintaan yang diperlukan dan opsional dijelaskan dalam tabel berikut:

Header permintaan	Deskripsi
`Authorization`	Diperlukan. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
`Date` atau `x-ms-date`	Diperlukan. Menentukan Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
`x-ms-version`	Fakultatif. Menentukan versi operasi yang akan digunakan untuk permintaan ini. Untuk informasi selengkapnya, lihat Penerapan Versi untuk layanan Azure Storage.
`x-ms-client-request-id`	Fakultatif. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 kibibyte (KiB) yang dicatat dalam log saat pengelogan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server. Untuk informasi selengkapnya, lihat Memantau Azure Queue Storage.

Isi permintaan

Untuk menentukan kebijakan akses tersimpan, berikan pengidentifikasi unik dan kebijakan akses dalam isi permintaan untuk operasi Set Queue ACL.

Elemen SignedIdentifier mencakup pengidentifikasi unik, seperti yang ditentukan dalam elemen Id, dan detail kebijakan akses, seperti yang ditentukan dalam elemen AccessPolicy. Panjang maksimum pengidentifikasi unik adalah 64 karakter.

Bidang Start dan Expiry harus dinyatakan sebagai waktu UTC dan harus mematuhi format ISO 8061 yang valid. Format ISO 8061 yang didukung meliputi yang berikut ini:

YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.ffffffTZD

Untuk bagian tanggal format ini, YYYY adalah representasi tahun empat digit, MM adalah representasi bulan dua digit, dan DD adalah representasi hari dua digit. Untuk bagian waktu, hh adalah representasi jam dalam notasi 24 jam, mm adalah representasi menit dua digit, ss adalah representasi kedua dua digit, dan ffffff adalah representasi milidetik enam digit. Penunjuk waktu T memisahkan bagian tanggal dan waktu string, dan penunjuk zona waktu TZD menentukan zona waktu.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Permintaan sampel

Request Syntax:  
PUT https://myaccount.queue.core.windows.net/myqueue?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>raup</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Jawaban

Respons mencakup kode status HTTP dan sekumpulan header respons.

Kode status

Operasi yang berhasil mengembalikan kode status 204 (Tanpa Konten).

Untuk informasi selengkapnya tentang kode status, lihat Status dan kode kesalahan.

Header respons

Respons untuk operasi ini mencakup header berikut. Respons juga dapat mencakup header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1 .

Header respons	Deskripsi
`x-ms-request-id`	Secara unik mengidentifikasi permintaan yang dibuat dan dapat digunakan untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API.
`x-ms-version`	Menunjukkan versi layanan Antrean yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru.
`Date`	Nilai tanggal/waktu UTC yang dihasilkan oleh layanan, yang menunjukkan waktu ketika respons dimulai.
`x-ms-client-request-id`	Header ini dapat digunakan untuk memecahkan masalah permintaan dan respons yang sesuai. Nilai header ini sama dengan nilai header `x-ms-client-request-id` jika ada dalam permintaan dan nilai berisi tidak lebih dari 1.024 karakter ASCII yang terlihat. Jika header `x-ms-client-request-id` tidak ada dalam permintaan, header tersebut tidak akan ada dalam respons.

Sampel respons

Response Status:  
HTTP/1.1 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2012-02-12  
Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0

Otorisasi

Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi Set Queue ACL menggunakan ID Microsoft Entra atau Kunci Bersama.

Untuk mengotorisasi operasi Set Queue ACL menggunakan ID Microsoft Entra, prinsip keamanan memerlukan peran Azure RBAC kustom yang menyertakan tindakan RBAC berikut: Microsoft.Storage/storageAccounts/queueServices/queues/setAcl/action.

Penting

Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. MICROSOFT Entra ID menyediakan keamanan yang unggul dan kemudahan penggunaan dibandingkan dengan otorisasi Kunci Bersama.

Komentar

Saat Anda mengatur izin untuk antrean, izin yang ada akan diganti. Untuk memperbarui izin antrean, panggil Dapatkan Antrean ACL untuk mengambil semua kebijakan akses yang terkait dengan antrean. Ubah kebijakan akses yang ingin Anda ubah, lalu panggil Set Queue ACL dengan kumpulan data lengkap untuk melakukan pembaruan.

Membuat kebijakan akses tersimpan

Kebijakan akses tersimpan dapat menentukan waktu mulai, waktu kedaluwarsa, dan izin untuk tanda tangan akses bersama yang terkait dengannya. Bergantung pada bagaimana Anda ingin mengontrol akses ke sumber daya antrean, Anda dapat menentukan semua parameter ini dalam kebijakan akses tersimpan, dan menghilangkannya dari URL untuk tanda tangan akses bersama. Dengan demikian, Anda dapat memodifikasi perilaku tanda tangan terkait kapan saja atau mencabutnya. Atau Anda dapat menentukan satu atau beberapa parameter kebijakan akses dalam kebijakan akses tersimpan, dan yang lain di URL. Terakhir, Anda dapat menentukan semua parameter pada URL. Dalam hal ini, Anda dapat menggunakan kebijakan akses tersimpan untuk mencabut tanda tangan, tetapi tidak mengubah perilakunya. Untuk informasi selengkapnya tentang membuat kebijakan akses, lihat Menentukan kebijakan akses tersimpan.

Bersama-sama, tanda tangan akses bersama dan kebijakan akses tersimpan harus menyertakan semua bidang yang diperlukan untuk mengotorisasi tanda tangan. Jika ada bidang yang diperlukan yang hilang, permintaan gagal. Demikian juga, jika bidang ditentukan baik di URL tanda tangan akses bersama maupun dalam kebijakan akses tersimpan, permintaan gagal dengan kode status 400 (Permintaan Buruk).

Paling banyak, lima kebijakan akses terpisah dapat diatur untuk satu antrean kapan saja. Jika lebih dari lima kebijakan akses diteruskan dalam isi permintaan, layanan mengembalikan kode status 400 (Permintaan Buruk).

Saat Anda membuat kebijakan akses tersimpan pada antrean, mungkin perlu waktu hingga 30 detik untuk diterapkan. Selama interval ini, tanda tangan akses bersama yang terkait dengan kebijakan akses tersimpan gagal dengan kode status 403 (Terlarang), hingga kebijakan akses menjadi aktif.

Lihat juga

Menentukan kebijakan akses tersimpan
Dapatkan ACL Antrean
Mengotorisasi permintaan ke Azure Storage
status dan kode kesalahan

Bagikan melalui