У меня есть веб-сайт, который предоставляет своим клиентам доступ к API c для отслеживания их заказов с помощью номера заказа. Я позволил им использовать POST или GET (с параметром URI) для передачи мне номера заказа. Однако некоторые из них написали неосторожные коды, которые передают недопустимые символы (звездочку, двоеточие или неправильно закодированные азиатские символы), например, https://mycompany.com/tracking/orderno:ODR12345, который вызывает исключение IIS:
Exception information:
Exception type: HttpException
Exception message: A potentially dangerous Request.Path value was detected from the client (:).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Я унаследовал метод Application_Error для входа это исключение. Но он по-прежнему выдается как ошибка 400 Bad Request в браузер пользователя и оставляет событие 1309 в моей программе просмотра событий, следовательно, спамит в нем журнал.
Я знаю, что могу отключить нелегальный-chars-exam из Интернета .config универсально, но это угроза безопасности. Я просто хочу иметь возможность обработать это исключение самостоятельно: перехватить его, записать его по-своему, предоставить полезный ответ пользователю, а затем подавить его, чтобы оно не загрязняло мой системный журнал. Как я могу это сделать?
Лекс дал мне идею переписать URL. Я думаю, что я могу поместить параметр в строку запроса вместо того, чтобы оставить его частью пути, так что опасная ошибка пути исчезнет. Затем я написал следующее правило:
<rule name="TrackingRewrite" enabled="true" stopProcessing="true">
<match url="/tracking/(.*)" />
<action type="Rewrite" url="tracking?querystring={R:1}" />
</rule>
Так что https://mycompany.com/tracking/orderno:ODR12345 становится https://mycompany.com/tracking?querystring=orderno:ODR12345, и правильное действие было выполнено, и пользователи получают ответ 200 с информацией отслеживания. Однако - после того, как возвращено действие контроллера, обратный вызов Applciation_Error по-прежнему вызывается с «потенциально опасным значением Request.Path, обнаруженным клиентом (:)». исключение и системный журнал был добавлен. Разрыв обратного вызова Applciation_Error и печать Request.Url показывает исходный недопустимый URL-адрес, а не переписанный. Как понять это поведение?