запрос превышает настроенный maxQueryStringLength при использовании [Authorize]

122

введите описание изображения здесь
У меня есть сайт MVC3 на C #, у меня есть конкретное представление, в которое загружаются параметры запроса из функции JavaScript, функция перенаправляет на сайт через

window.location.href = "../ActionName?" + query_string;

query_string - строка динамических параметров запроса, созданная функцией JavaScript.

Причина этой странности заключается в том, что иногда одна и та же функция передает URL-адрес веб-форме ASP.Net из-за того, что ей необходимо использовать элемент управления reportviewer , альтернативным действием является сохранение некоторых параметров, в этом случае он передается в представление. (Могу рассказать подробнее, если это не имеет смысла)

Все работает нормально, пока я не введу [Authorize] в метод действия. Ломается, если он установлен, отлично работает без него, а [Авторизация] отлично работает со всеми другими методами.

Весь URL-адрес в этом случае составляет 966 символов, после исследования кажется, что значение maxQueryStringLength по умолчанию равно 2048, но может быть переопределено на любое значение типа integer, поэтому просто для усмешки я добавил

<security>
  <requestFiltering>
    <requestLimits maxQueryString="2048"></requestLimits>
  </requestFiltering>
</security>

ключ к файлу веб-конфигурации под ключом.

Никакой радости там не было, поэтому я стал смешным и сделал 4096, но все равно никакой радости.

Теперь, когда весь URL-адрес составляет 966 символов, атрибут authorize не может серьезно добавлять еще 1082-3130 символов, так как я могу определить, что на самом деле ошибка или почему параметр не вступает в силу.

VS2010 Pro с пакетом обновления 1 (SP1)

сабля
источник
Добавьте подробное сообщение об ошибке, которое вы получаете.
Counsellorben

Ответы:

70

Когда поступает неавторизованный запрос, весь запрос кодируется в URL-адресе и добавляется в виде строки запроса к запросу в форму авторизации, поэтому я могу видеть, где это может привести к проблеме в вашей ситуации.

Согласно MSDN, правильный элемент, который нужно изменить для сброса maxQueryStringLength в web.config, - это <httpRuntime>элемент внутри <system.web>элемента, см. Элемент httpRuntime (схема параметров ASP.NET) . Попробуйте изменить этот элемент.

counsellorben
источник
1
Увы, размещение его в правильном месте кажется уловкой, достаточно интересного intellisense ведет меня к тому же ключу в том месте, где я его изначально разместил.
Sabre
8
Также полезно знать, что максимальное значение для этого параметра составляет 2097151 - сначала я пытался использовать Int32.MaxValue, но исключение, которое было выдано во время выполнения, указывало мне на использование значения от 0 до 2097151.
TimDog
не работает см. это. stackoverflow.com/questions/31624710/…
Джитендра Панчоли
1
Я считаю, что хотя вы можете установить максимальное значение для этого параметра равным 2097151, есть и другие параметры, которые влияют на максимальную длину принимаемого запроса. У меня была строка запроса намного короче этого максимума, которая не была принята - она ​​была длиной 3393 символа. Другой запрос длиной 3200 символов работал нормально.
markthewizard1234 03
@ markthewizard1234: Согласовано: я увеличил мой от 2048 до 4096. Это уже имело некоторый эффект, как исходное сообщение об ошибке с 404.something для строки запроса слишком длинные, не появляется больше. Но теперь возвращается другое сообщение об ошибке с кодом 400, также указывающее на слишком длинную строку запроса.
OR Mapper
213

В корне web.configвашего проекта под system.webузлом:

<system.web>
    <httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />
...

Кроме того, мне пришлось добавить это под system.webServerузлом, иначе я получил ошибку безопасности для моих длинных строк запроса:

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>
...
theJerm
источник
1
Создает ли это открытие какие-либо серьезные недостатки в безопасности? Какие недостатки есть у установки maxurl и maxquery на 2097151?
Брайан
1
Брайан, это хороший вопрос - я не вижу никаких недостатков безопасности, если только добавление чего-то большего в строку запроса, помимо ограничения браузера, может быть вредным. Приоритет ли строки запроса максимальной длины браузера над этим значением - это еще один вопрос, на который у меня нет ответа. Спасибо, что спросили, может быть, кто-то здесь сможет пролить свет на это.
theJerm
Я предполагаю, что существует потенциальная уязвимость DOS, но это зависит от того, как вы на самом деле обрабатываете запрос. Я столкнулся с этим при попытке добавить 100 пользователей за один запрос. В любом случае, я не хочу этого.
Martin
4
Это немедленно решило мою проблему, так как у меня была такая же проблема в проекте MVC 4. Добавление обоих вышеперечисленных разрешило мою ошибку. Огромное спасибо!!
Эд ДеГань
3
Имейте в виду, что maxQueryStringэто длина в байтах как uint с максимальным значением 4294967295 и maxQueryStringLengthдлина в символах как int, но с диапазоном 0-2097151.
marsze
5

Для всех, кто может столкнуться с этой проблемой, и она не решена ни одним из вышеперечисленных вариантов, это то, что сработало для меня.

1. Click on the website in IIS
2. Double Click on Authentication under IIS
3. Enable Anonymous Authentication

Я отключил это, потому что мы использовали наш собственный Auth, но это привело к той же проблеме, и принятый ответ никоим образом не помог.

dball
источник
4

у меня эта ошибка с использованием datatables.net

Я исправил изменение по умолчанию ajax Get на POST в свойствах DataTable ()

"ajax": {
        "url": "../ControllerName/MethodJson",
        "type": "POST"
    },
elblogdelbeto
источник
Я также использовал таблицы данных, и после безуспешных попыток описанных выше предложений этот трюк сработал.
AidaM