IIS 7.5: Cara mengkonfigurasi halaman Error Otentikasi kustom dengan Windows Authentication. 401 masalah header


14

Saya memiliki situs web php yang berjalan di bawah IIS 7.5. Situs ini dijamin oleh otentikasi Windows dan berfungsi dengan baik:

Otentikasi Windows aktif

Ketika pengguna pergi ke situs, mereka ditanyai nama pengguna / kata sandi dan lolos jika dikonfirmasi. Jika pengguna mengklik Batalkan atau salah ketik kata sandi 3 kali, mereka ditampilkan halaman 401 kesalahan:

Halaman jelek 401

Sekarang saya ingin menampilkan halaman khusus yang menjelaskan cara masuk. Jadi saya pergi ke halaman Kesalahan, pilih kode status 401.2 dan arahkan ke halaman yang ingin saya tampilkan:

Pengaturan halaman kesalahan

Kemudian pastikan kesalahan khusus dihidupkan untuk semua orang. Dan kaa-boom! Otentikasi tidak berfungsi lagi, pengguna tidak diberikan kata sandi. Seperti yang dikatakan oleh dokumentasi, Otentikasi Windows berfungsi dengan mengirim 401 balasan pertama, lalu browser meminta pengguna ke kredensial penyedia dan kemudian mereka menentukan apa yang harus dilakukan selanjutnya.

Apa yang terjadi di sini: pada permintaan pertama untuk halaman IIS mencoba mengirim 401-header, tetapi pemberitahuan bahwa web.config mengatakan "pada 401 redirect ke halaman ini". Dan bukannya otentikasi, itu hanya memberikan halaman pengalihan.

Saya sudah mencoba mengganti 401, 401.1, 401.2 - tidak ada bedanya.

Apa yang saya lakukan salah dan bagaimana cara memberikan halaman kustom pada kesalahan otentikasi pengguna?

ps Inilah web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Custom">
            <remove statusCode="500" subStatusCode="-1" />
            <remove statusCode="404" subStatusCode="-1" />
            <remove statusCode="401" subStatusCode="-1" />
            <error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />
            <error statusCode="404" prefixLanguageFilePath="" path="/not_restricted/404.htm" responseMode="ExecuteURL" />
        </httpErrors>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
    <system.web>
        <identity impersonate="false" />
        <customErrors defaultRedirect="http://www.myserver.com/not_restricted/500.htm" mode="Off">
        </customErrors>
    </system.web>
</configuration>

Jawaban:


15

Coba ini:

perubahan:

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />

untuk

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />

Dengan mode respons 'File' IIS hanya memuat konten file itu dan menampilkannya, ia masih mengirim status 401 kembali ke klien.

Saya dulu menggunakan 'ExecuteURL' tetapi telah belajar bahwa mode File berfungsi lebih baik. Anda hanya perlu memastikan bahwa sumber daya yang tertaut di halaman kesalahan Anda masih berfungsi.


1
Pak, Anda seorang bintang! Itu memperbaiki masalah dari upaya pertama!
trailmax

2

Saya mengalami masalah yang sama dengan pengguna yang tidak diminta kredensial setelah menambahkan httperrors khusus dan dapat memperbaikinya dengan subStatusCode 0. Semoga ini bisa membantu seseorang.

<error statusCode="401" subStatusCode="0" path="..." responseMode="ExecuteURL">

1

Jadi saya mengalami kesulitan dengan masalah yang sama persis dari Auth Dasar tidak mendorong browser. Baik memaksa kesalahan khusus 401.0 (yaitu secara eksplisit mengatur subcode ke 0) atau mengatur penciptaan kunci registri untuk saya.

Ternyata itu adalah penggunaan kami dari halaman kesalahan khusus untuk memulai. Mematikannya, semuanya bekerja dengan baik, hidup kembali ... khususnya kesalahan 401 (0) dan 401.2 mencegah prompt.

Mengatur jenis kesalahan khusus ke 'File' dari 'ExecuteURL' memang menyelesaikannya, tetapi jika pengguna membatalkan prompt atau memasukkan kata sandi yang buruk, mereka mendapat generik "Anda tidak memiliki izin untuk melihat direktori atau halaman ini".

Setelah banyak mendapatkan petunjuk dari berbagai posting, tetapi tidak pernah persis 'bagaimana-untuk' atau 'mengapa' ... Saya menggunakan jalur relatif untuk file kesalahan khusus yang berada di subdirektori situs. Mengubah jalur menjadi absolut menyebabkan kesalahan umum di atas diganti dengan "tidak dapat menampilkan halaman ini" jika kata sandi dibatalkan atau salah. Sedikit lebih menggali dan saya menemukan posberbicara tentang atribut config "allowAbsolutePathsWhenDelegated" yang disetel ke false secara default. Ini juga menyatakan bahwa jika Anda hanya meletakkan file kesalahan pelanggan di root situs Anda dan kemudian di lokasi kesalahan kustom hanya nama file (yaitu jalur relatif ke root situs) itu akan berfungsi ... cukup yakin itu terjadi, namun , Saya tidak ingin menempatkan kesalahan khusus di root situs saya. Jadi saya menggunakan ConfigurationEditor untuk mengatur atribut di atas menjadi true, mengatur path absolut ke file kesalahan kustom dan semuanya mulai berfungsi dengan baik. Prompt tetap, kesalahan khusus ditampilkan ketika dipicu.

Yang saya inginkan adalah, untuk dapat menggunakan atribut File dengan path relatif bersarang, tetapi sejauh ini saya belum menemukan mengapa saya tidak bisa atau bagaimana melakukan ini. Pertanyaan lainnya adalah, jika dengan menggunakan jalur absolut, jika saya berpotensi membuat lubang keamanan (yaitu mengapa ini dinonaktifkan secara default?)

Bagaimanapun, semoga ini membantu seseorang.


0

Untuk beberapa alasan aneh dalam kombinasi kasus saya hingga 2 solusi bekerja untuk saya untuk asp.net MVC 5.

  <error statusCode="401" subStatusCode="0" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />

Ini adalah jawaban yang tepat sebagai jawaban yang diterima.
Luminous

kode status berbeda.
Teoman shipahi
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.