Zammad: Respons HTTP 401 menyebabkan masalah dengan Autentikasi Dasar

Dibuat pada 24 Mar 2020  ·  12Komentar  ·  Sumber: zammad/zammad

Informasi:

  • Versi Zammad yang digunakan: 3.2.0
  • Metode instalasi (sumber, paket, ..): Dari sumber menggunakan Ruby 2.5.5, di belakang nginx rproxy.
  • Sistem operasi: Ubuntu 18.04.4 LTS (bionic)
  • Database + versi: postgres 9.5.21
  • Versi Elasticsearch: 5.6.16
  • Browser + versi: Google Chrome 80.0.3987.132

Perilaku yang diharapkan:

Zammad terintegrasi dengan mulus dengan lapisan otentikasi dasar . Oleh karena itu, kode status "HTTP 401 Unauthorized" tidak pernah digunakan. Sebagai alternatif, kode status 403 akan menjadi pengganti yang tepat.

Perilaku sebenarnya:

Secara keseluruhan, Zammad tidak memiliki banyak masalah jika digabungkan dengan basic auth. Namun ada beberapa kasus, di mana permintaan dijawab dengan kode status 401 dan pengguna saat ini dipaksa untuk memasukkan kembali kredensial autentikasi dasarnya.

Basis kode dapat dicari dengan mudah untuk status 401 (atau unauthorized ):
https://github.com/zammad/zammad/search?l=Ruby&q=%3Aunauthorized

Langkah-langkah untuk mereproduksi perilaku:

  • Siapkan instance Zammad dan letakkan di belakang autentikasi dasar

KEMUDIAN

  • Coba masuk dengan kredensial yang salah
  • Aplikasi merender halaman dengan kode status 401 dan memaksa Anda untuk memasukkan kembali kredensial otentikasi dasar

ATAU

  • Buat tiket yang ditetapkan ke grup di mana orang 1 memiliki akses
  • Orang 1 berinteraksi dengan tiket itu
  • Pindahkan tiket itu ke grup lain yang tidak dapat diakses oleh orang 1
  • Orang ke-1 masih akan melihat permintaan 401 ke tiket di atas pada ikhtisar Zammad-nya, yang akan mengeluarkannya dari autentikasi dasar

Ya, saya yakin ini bug dan tidak ada permintaan fitur atau pertanyaan umum.

API bug verified

Komentar yang paling membantu

Hai teman-teman! Terima kasih atas informasi dan deskripsi yang berharga. Saya membaca RFC dan masih sedikit bingung tentang perbedaan antara 401 dan 403. Namun, saya menemukan penjelasan yang bagus ini di StackOverflow. Kutipan:

Ada masalah dengan 401 Unauthorized, kode status HTTP untuk kesalahan otentikasi. Dan hanya itu: ini untuk otentikasi, bukan otorisasi.

Itu membawanya ke intinya. Zammad menggunakan 401 untuk kesalahan authorization . Ini secara teknis salah dan karena itu bug. Saya akan membuka kembali masalahnya.

Namun, kita perlu memeriksa dampaknya. Saya berasumsi bahwa ini adalah perubahan besar karena semua penerapan dan konsumen API di luar sana.
Paket saya saat ini adalah menghentikan penggunaan lunak 401 authorization dengan Zammad 3.4, tidak menggunakan lagi dengan 3.5 (atau 3.6) dan beralih ke 403.
Kami perlu membahas ini lebih lanjut secara internal.

Pikiran lebih lanjut tentang siapa ini?

Semua 12 komentar

Harap perbarui artikel pertama Anda untuk menyimpan informasi penginstalan yang tepat - "apa saja" tidak benar-benar sesuai pada saat ini - maaf. :)

Selain itu, berikan konfigurasi server web lengkap Anda (dan beri tahu kami yang mana yang Anda gunakan). Sekarang ini agak berbau pertanyaan teknis, tapi saya ingin memastikan sepenuhnya. Namun, untuk itu saya butuh segalanya. ;)

Terima kasih.

Halo lagi,
Saya memperbarui deskripsi masalah - maaf atas kekurangannya di awal!
Terbaik

Terima kasih atas pembaruannya. Konfigurasi server web Anda adalah konfigurasi default kami yang diperluas oleh autentikasi dasar? Maukah Anda memberikan konfigurasi vhost itu juga? Hanya untuk memastikan aku tidak melewatkan sesuatu.

Terima kasih!

Ya, pada dasarnya hanya konfigurasi Zammad Default + Basic Auth. Berikut adalah konfigurasi vhost:

auth_basic 'Restricted: general basic auth';
auth_basic_user_file /etc/.htpasswd.d/zammad;
location /ws {
    proxy_pass  http://zammad_ws;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  443;
    proxy_set_header CLIENT_IP $remote_addr;
    proxy_read_timeout 86400;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    error_page 502 503 504 =503 @fallback;
}
location / { 
    try_files $uri @proxy;
}
location <strong i="6">@proxy</strong> { 
    proxy_pass  http://zammad;
    proxy_redirect  off;
    proxy_hide_header X-Powered-By;
    proxy_set_header  Host              $host;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto https;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-Host  $host;
    proxy_set_header  X-Forwarded-Port  $server_port;
    proxy_http_version 1.1;
    proxy_set_header  Upgrade           $http_upgrade;
    proxy_set_header  Connection        "upgrade";
    proxy_max_temp_file_size  0;
    proxy_set_header CLIENT_IP $remote_addr;
    error_page 502 503 504 =503 @fallback;
}

Kami memeriksanya lagi.
Tebakan kami (seperti yang ditulis Michael) adalah tidak mengembalikan HTTP 401 (yang membuat browser percaya bahwa kredensial autentikasi dasar salah) tetapi mengembalikan HTTP 403 dilarang.

Jika saya melihatnya dengan benar, ini berarti

app / controllers / application_controller / handle_errors.rb # L39
respond_to_exception(e, :unauthorized)

harus diganti dengan
respond_to_exception(e, :forbidden)

RFC mengatakan browser harus berperilaku berbeda (https://tools.ietf.org/html/rfc7231#section-6.5.3): "Jika kredensial otentikasi diberikan dalam permintaan, server menganggapnya tidak cukup untuk memberikan akses. Klien HARUS TIDAK otomatis mengulangi permintaan dengan kredensial yang sama. "

Padahal, kami memiliki masalah yang sama di proyek lain minggu lalu dan 403 pekerjaan.
Jika Anda tidak melihat masalah lain dalam mengembalikan 403, kami dapat mengeluarkan PR.

Terbaik

Maaf sudah lama sekali.
Harap dicatat bahwa ini bukan masalah terkait Zammad (berbasis aplikasi), tetapi "masalah backend" di nginx Anda.

Permintaan otentikasi untuk otentikasi dasar tidak pernah mencapai Zammad sebagai aplikasi tetapi sudah berakhir (dan diperiksa oleh) nginx Anda atau server web lain yang Anda gunakan.

Jadi, mengubah kode sumber menurut saya tidak menyelesaikan masalah Anda sama sekali.
Secara teknis, 401 tidak sah benar dari apa yang saya tahu (meskipun saya mengerti Anda menginginkan 403).

Lihat juga:
https://serverfault.com/questions/616770/nginx-auth-basic-401-htpasswd

Ngomong-ngomong:
Hanya untuk memeriksa ulang saya benar-benar mengomentari bagian proxy Zammad untuk memastikan backend Zammad tidak dapat membalas. Hasil dengan 401 adalah sama dan dengan demikian kesalahan nginx. :)

Menutup karena ini bukanlah bug tapi pertanyaan teknis.

Halo @rGeneration ,
terima kasih telah melihat ini.

Meskipun saya memahami bahwa masalah ini tampaknya berada di luar cakupan aplikasi Zammad, saya masih berpikir bahwa ini disebabkan olehnya (dan bukan Ngnix). Saya akan mencoba menjelaskan alasannya:

Mari asumsikan ngnix kita _not_ dikonfigurasi untuk menggunakan otentikasi dasar. Dalam hal ini, kami berdua setuju bahwa aplikasi Zammad ("di belakang" ngnix) berfungsi dengan baik.

Sekarang, kami mengaktifkan autentikasi dasar dengan menambahkan konfigurasi yang disebutkan di atas ke ngnix kami. Harap dicatat bahwa bahkan sekarang, hampir semuanya masih berfungsi seperti yang diharapkan - termasuk otentikasi (login dasar dan Zammad) dan aplikasi Zammad itu sendiri.

Masalah yang saya coba jelaskan sebelumnya kadang-kadang disebabkan kemudian (oleh Zammad!) Ketika aplikasi merender halaman dengan kode status 401. Dalam kasus ini, _server_ mana pun_ dengan otentikasi dasar yang diaktifkan dipaksa untuk mengeluarkan Anda.

Saya setuju bahwa berbicara secara semantik 401 terdengar "tepat" dalam kasus ini. Secara teknis, ini menyebabkan masalah yang tak terhindarkan dengan otentikasi dasar dan harus diganti dengan 403.
Harap buka kembali masalah ini karena mungkin juga memengaruhi UX aplikasi Zammad bagi banyak pengguna.

@thorsteneckel apa pendapat Anda tentang ini?

Hai teman-teman! Terima kasih atas informasi dan deskripsi yang berharga. Saya membaca RFC dan masih sedikit bingung tentang perbedaan antara 401 dan 403. Namun, saya menemukan penjelasan yang bagus ini di StackOverflow. Kutipan:

Ada masalah dengan 401 Unauthorized, kode status HTTP untuk kesalahan otentikasi. Dan hanya itu: ini untuk otentikasi, bukan otorisasi.

Itu membawanya ke intinya. Zammad menggunakan 401 untuk kesalahan authorization . Ini secara teknis salah dan karena itu bug. Saya akan membuka kembali masalahnya.

Namun, kita perlu memeriksa dampaknya. Saya berasumsi bahwa ini adalah perubahan besar karena semua penerapan dan konsumen API di luar sana.
Paket saya saat ini adalah menghentikan penggunaan lunak 401 authorization dengan Zammad 3.4, tidak menggunakan lagi dengan 3.5 (atau 3.6) dan beralih ke 403.
Kami perlu membahas ini lebih lanjut secara internal.

Pikiran lebih lanjut tentang siapa ini?

Itu berita bagus! Terdengar bagus untukku.

Agar Anda tetap mengetahui: Kami akan menerapkan ini dengan rilis 4.0 mendatang.

Untuk tujuan implementasi internal: https://thoughtbot.com/blog/forbidden-kisses-http-fluency-in-clearance

Diperbaiki dengan komit di atas. Kami mengambil kesempatan dan meningkatkan beberapa pesan kesalahan 401 tetapi pada dasarnya satu-satunya hal yang kami ubah adalah kesalahan non-otentikasi menjadi 403 Forbidden .

Anda dapat menguji ini dengan paket develop dalam waktu sekitar 30 menit dari sekarang. Perlu diketahui bahwa ini adalah cabang yang berfungsi dan tidak stabil. Oleh karena itu pastikan untuk memiliki cadangan dan mengharapkan yang terburuk :) Menantikan tanggapan Anda!

Apakah halaman ini membantu?
0 / 5 - 0 peringkat