HTTPDNS:Implementasikan akses terotentikasi

1. Latar Belakang

Untuk mencegah penggunaan tidak sah yang dapat memengaruhi penagihan Anda, kami telah merancang mekanisme otentikasi. Dokumen ini menjelaskan cara mengintegrasikannya.

2. Solusi Otentikasi

Pengguna yang sudah ada memiliki produk yang menggunakan API non-terotentikasi. Untuk memastikan kelangsungan layanan, pengguna tersebut harus tetap menggunakan API non-terotentikasi.

Oleh karena itu, kami menyediakan authenticated API yang baru. Anda dapat secara bertahap memigrasikan versi produk baru ke API ini. Ketika jumlah pengguna pada versi aplikasi lama turun ke tingkat yang dapat dikelola, Anda dapat mengaktifkan akses bertanda tangan untuk mencegah penggunaan tidak sah yang berdampak pada penagihan Anda, seperti yang ditunjukkan pada diagram berikut.

2.1 Rencana migrasi untuk pengguna yang sudah ada

• Jika Anda mengaktifkan akses bertanda tangan, pengguna versi aplikasi lama tidak akan dapat mengakses layanan HTTPDNS.

• Arahkan pengguna yang sudah ada untuk memperbarui aplikasi mereka dan bermigrasi ke API authenticated.

• Ketika jumlah pengguna pada API non-authenticated turun ke tingkat yang dapat diterima, Anda dapat secara manual mengaktifkan akses bertanda tangan.

2.2 Rencana penggunaan untuk pengguna baru

• Untuk mengurangi beban integrasi, akses bertanda tangan dinonaktifkan secara default.

• Jika Anda memerlukan akses bertanda tangan, Anda dapat mengaktifkannya secara manual.

2.3 Mengelola toggle API bertanda tangan

• Menonaktifkannya dapat menimbulkan risiko keamanan.

• Mengaktifkan akses bertanda tangan adalah satu-satunya cara untuk mencegah biaya tak terduga akibat serangan.

3. Algoritma pembuatan signature dan mekanisme otentikasi

3.1 Algoritma pembuatan signature dan contoh

Authenticated API

• http://47.74.XXX.XXX/{account_id}/sign_d

• http://47.74.XXX.XXX/{account_id}/sign_resolve

Algoritma Tanda Tangan

sign = md5sum( host-secret-timestamp )

Deskripsi bidang otentikasi

Contoh signature

• Contoh 1 (Standard resolution API):

  • Permintaan awal:http://47.74.XXX.XXX/{account_id}/d?host=www.aliyun.com

  • Asumsikan secret-nya adalah IAmASecret dan signature kedaluwarsa pada pukul 15.00.00 UTC+8 tanggal 15 Agustus 2018 (timestamp: 1534316400).

  • sign = md5sum("www.aliyun.com-IAmASecret-1534316400") = 60c71e98b6d7fcbb366243e224eab457

  • Permintaan terotentikasi:http://47.74.XXX.XXX/{account_id}/sign_d?host=www.aliyun.com&t=1534316400&s=60c71e98b6d7fcbb366243e224eab457

• Contoh 2 (Batch resolution API):

  • Permintaan awal:

    http://47.74.XXX.XXX/{account_id}/resolve?host=www.aliyun.com,www.taobao.com

  • Asumsikan secret-nya adalah IAmASecret dan signature kedaluwarsa pada pukul 15.00.00 UTC+8 tanggal 15 Agustus 2018 (timestamp: 1534316400).

  • sign = md5sum("www.aliyun.com,www.taobao.com-IAmASecret-1534316400") = 12a3f6b1b14a46ca813ca6439beb59a4

  • Permintaan terotentikasi:http://47.74.XXX.XXX/{account_id}/sign_resolve?host=www.aliyun.com,www.taobao.com&t=1534316400&s=12a3f6b1b14a46ca813ca6439beb59a4

Kelebihan dan kekurangan solusi ini

• Kekurangan

  • Waktu sistem klien mungkin tidak tersinkronisasi.

  • Menyimpan secret di klien menimbulkan risiko keamanan karena secret dapat terekspos.

• Kelebihan

  • Tidak memerlukan pengambilan data dari sisi server.

3.2 Respons otentikasi

• Jika otentikasi berhasil, kode status HTTP adalah 200 dan respons sesuai dengan API response description dalam dokumentasi single-domain resolution .

• Jika otentikasi gagal, kode status HTTP adalah 403 atau 400. Badan respons berformat JSON dan mencakup kode kesalahan spesifik.

   { "code": "InvalidSignature" }

3.3 Referensi kode status