Nilai Request.Path yang berpotensi berbahaya terdeteksi dari klien (*)

Saya menerima kesalahan yang cukup jelas:

Nilai Request.Path yang berpotensi berbahaya terdeteksi dari klien (*).

Masalahnya adalah karena *dalam URL permintaan:

https://stackoverflow.com/Search/test*/0/1/10/1

Url ini digunakan untuk mengisi halaman pencarian di mana 'test *' adalah istilah pencarian dan sisanya dari url berhubungan dengan berbagai filter lainnya.

Apakah ada cara mudah untuk mengizinkan karakter khusus ini di URL? Saya sudah mencoba memodifikasi web.config, tetapi tidak berhasil.

Haruskah saya menyandikan / mendekode karakter khusus secara manual? Atau apakah ada praktik terbaik untuk melakukan ini, saya ingin menghindari menggunakan string kueri. - tapi itu bisa jadi pilihan.

Aplikasi itu sendiri adalah aplikasi formulir c# asp.netweb yang menggunakan perutean untuk menghasilkan URL yang bagus di atas.

The *karakter tidak diperbolehkan di jalur URL, tapi tidak ada masalah menggunakannya dalam string:

http://localhost:3286/Search/?q=test*

Ini bukan masalah penyandian, *karakter tidak memiliki arti khusus dalam URL, jadi tidak masalah apakah URL Anda menyandikannya atau tidak. Anda harus menyandikannya menggunakan skema yang berbeda, lalu mendekodekannya.

Misalnya menggunakan karakter arbitrer sebagai karakter pelarian:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

Dan decoding:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

Jika Anda menggunakan .NET 4.0, Anda harus dapat mengizinkan url ini melalui web.config

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

Catatan, Saya baru saja menghapus tanda bintang (*), string default aslinya adalah:

<httpRuntime 
          requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?" />

Lihat pertanyaan ini untuk lebih jelasnya.

Bagi saya, saya sedang mengerjakan .net 4.5.2 dengan web api 2.0, saya memiliki kesalahan yang sama, saya atur hanya dengan menambahkan requestPathInvalidCharacters = "" di requestPathInvalidCharacters Anda harus menyetel karakter yang tidak diizinkan, jika tidak, Anda harus menghapus karakter yang harus dihapus menyebabkan masalah ini.

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

** Perhatikan bahwa ini bukan praktik yang baik, mungkin posting dengan parameter ini karena atribut objek lebih baik atau mencoba menyandikan karakter khusus. - Setelah mencari praktik terbaik untuk merancang api sisanya, saya menemukan bahwa dalam pencarian, pengurutan dan paginnasi, kita harus menangani parameter kueri seperti ini

/companies?search=Digital%26Mckinsey

dan ini menyelesaikan masalah ketika kita menyandikan & dan mengganti-ganti itu di url sebesar% 26 dengan cara apa pun, di server kita menerima parameter yang benar Digital & Mckinsey

tautan ini dapat membantu praktik terbaik merancang api web sisanya https://hackernoon.com/restful-api-design-guidelines-the-best-practices-60e1d954e7c9

Anda harus menyandikan nilai rute dan kemudian (jika perlu) mendekode nilai sebelum mencari.

Bagi saya, saat mengetik url, pengguna secara tidak sengaja menggunakan / bukannya a? untuk memulai parameter kueri

misalnya:

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

yang seharusnya:

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value

Pengecualian ini terjadi pada aplikasi saya dan agak menyesatkan.

Itu dilemparkan ketika saya memanggil metode Web halaman .aspx menggunakan panggilan metode ajax, melewati objek array JSON. Tanda tangan metode Halaman Web berisi larik objek .NET yang sangat diketik, OrderDetails. Properti Actual_Qty didefinisikan sebagai int, dan objek JSON properti Actual_Qty berisi "4" (karakter spasi tambahan). Setelah menghapus ruang ekstra, konversi dimungkinkan, metode Halaman Web berhasil dijangkau oleh panggilan ajax.

Cobalah untuk menetapkan server proyek web yang layak sebagai IIS Lokal jika IIS Express. Pastikan jika url proyek benar dan buat direktori virual.

Ketika berhadapan dengan Uniform Resource Locator (URL) ada standar sintaksis tertentu , dalam situasi khusus ini kita berhadapan dengan Karakter Cadangan .

Sampai dengan RFC 3986 , Karakter Cadangan dapat (atau mungkin tidak) didefinisikan sebagai pembatas oleh sintaksis umum, oleh setiap sintaksis khusus skema, atau oleh sintaksis implementasi spesifik dari algoritma dereferencing URI; Dan tanda bintang (*) adalah Karakter Cadangan.

Praktik terbaik adalah menggunakan Karakter yang Tidak Ditangguhkan dalam URL atau Anda dapat mencoba menyandikannya.

Terus gali:

• Referensi Pengkodean URL HTML (w3schools)
• Kapan Melakukan Encode atau Decode (RFC 3986)