ValidateRequest = "false" не працює в Asp.Net 4


156

У мене є форма, в якій я використовую ckeditor. Ця форма добре працювала на Asp.Net 2.0 та 3.5, але зараз вона не працює в Asp.Net 4+. У мене ValidateRequest = "false" директива. Будь-які пропозиції?


Існує коротка стаття про правильне відображення засобів перевірки перевірки, якщо хтось хвилює: Перевірка помилок у .NET 4
— Ян

може хто-небудь, будь ласка, дайте мені знати, які недоліки використання ValidationRequest = false?
— fc123

Відповіді:


194

Знайдено рішення на сторінці помилок. Просто потрібно додати requestValidationMode = "2.0"

<system.web>
    <compilation debug="true" targetFramework="4.0" />
    <httpRuntime requestValidationMode="2.0" />
</system.web>

Інформація про MSDN: Властивість HttpRuntimeSection.RequestValidationMode


1
це дивовижно, але хтось знає про спосіб встановити це на кожній сторінці? Крім того, як я можу це помістити в web.config, щоб він все ще працював з .NET 2?
— МК.

1
@MK: Я не думаю, що для цієї настройки є директива сторінки. Ви не можете змусити його працювати .net 2. Я не думаю, що це було б потрібно. Тому що ви можете просто створити веб-додаток, орієнтований лише на одну рамкову версію. Просто скопіюйте цей рядок на .net 4 web.config, який йому потрібен ...
— HasanG

2
Але що змінилось у валідації для .net 4? Чи є спосіб це зробити без зміни режиму перевірки?
— Хитрий

4
@Sly: Відповідь ви можете знайти тут: asp.net/learn/whitepapers/aspnet4/…
— HasanG

може хто-небудь, будь ласка, дайте мені знати, чому в додатку asp.net 4.0 за допомогою requestValidationMode = "2.0" це гарна ідея?
— fc123

102

Існує спосіб повернути перевірку на 2,0 для однієї сторінки. Просто додайте наведений нижче код до своєї web.config:

<configuration>
    <location path="XX/YY">
        <system.web>
            <httpRuntime requestValidationMode="2.0" />
        </system.web>
    </location>

    ...
    the rest of your configuration
    ...

</configuration>

Місце розташування - це будь-який шлях і базується на будь-якому вузлі нижче папки, яку ви вказали у дереві.
— DFTR

7
Це краще рішення, ніж прийнята відповідь, оскільки це не широке застосування, а досить вузьке до конкретної сфери, яку ви визначаєте на шляху до місцезнаходження
— Чарльз Уеслі,

5
Декларацію <location ..> вище слід розмістити всередині декларації <configuration>, але не вкладати далі.
— rbassett

1
Налаштування сторінки не працює для проектів, орієнтованих на .NET 4.6.1.
— Денніс Т - Відновити Моніку -

56

Я знаю , що це старе питання, але якщо ви зіткнулися з цією проблемою в MVC 3 , то ви можете прикрасити ActionMethodз [ValidateInput(false)]і просто відключити перевірку запитів на один ActionMethod, що дуже зручно. І вам не потрібно вносити жодних змін у web.configфайл, тому ви все одно можете використовувати перевірку запиту .NET 4 скрізь в іншому місці.

напр

[ValidateInput(false)]
public ActionMethod Edit(int id, string value)
{
    // Do your own checking of value since it could contain XSS stuff!
    return View();
}

1
@RossCooper це лише для asp.net MVC
— mxmissle

28

Це працює без зміни режиму перевірки.

Ви повинні використовувати System.Web.Helpers.Validation.Unvalidatedпомічник від System.Web.WebPages.dll. Він поверне UnvalidatedRequestValuesоб'єкт, що дозволяє отримати доступ до форми та QueryString без перевірки.

Наприклад,

var queryValue = Server.UrlDecode(Request.Unvalidated("MyQueryKey"));

Для мене працює для MVC3 та .NET 4.


1
Чи можете ви надати приклад того, як отримати queryString за допомогою цього методу? Я продовжую отримувати "Недійсний не є членом ..." усіх об'єктів, до яких я намагаюся додати. Думаю, мені може бути не вистачає включення
— CodedMonkey

3
var queryValue = Server.UrlDecode (Request.Unvalified ("MyQueryKey"));
— sfuqua

1
Це безумовно має бути прийнятою відповіддю. Забезпечує безпеку і надзвичайно гнучка, оскільки ви можете користуватися нею вибірково.
— cmartin


15

Зауважте, що інший підхід полягає в тому, щоб дотримуватися поведінки валідації 4.0, але визначити свій власний клас, який випливає з RequestValidatorта встановити:

<httpRuntime requestValidationType="YourNamespace.YourValidator" />

(де YourNamespace.YourValidator добре, ви повинні вміти здогадуватися ...)

Таким чином ви зберігаєте переваги поведінки 4.0s (зокрема, що перевірка відбувається раніше під час обробки), одночасно дозволяючи запитам, які вам потрібно пропустити, наскрізь.


7
Це добре знати. Але я все ще думаю, що вся функція перевірки запиту ASP.Net помилкова. Вхід сам по собі не проблема, це те, що ви робите з ним. Ви можете абсолютно допустити прийняття SQL, HTML або JavaScript коду як вхід до вашої програми, якщо ви кодуєте / уникаєте його належним чином, перш ніж виводити його чи зберігати його у вашій базі даних.
— Йордан Рігер

2
@JordanRieger Я частково згоден. OOTB, він, принаймні, має перевагу дефолту, щоб захистити (не продумайте справи, і ви отримаєте помилки, а не 0wned), але це трохи неприємно, і поведінка до 4.0 - це майже все або нічого. Існує щось у здатності мати рівень перевірки, який звикає до будь-якої іншої обробки, як у користувацькому requestValidationType, але багато перевірки потрібно більше пов'язати з іншою обробкою. Я думаю, що це захищає людей із шкідливими звичками від якихось (але не всіх) стилів, ніж заохочувати хороші звички
— Джон Ханна
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.