Глобальный ресурс по сравнению с Локальным ресурсом в ASP.NET
** Предупреждение: подход, описанный в этом ответе, применим только к очень конкретным сценариям и не является безопасным, поскольку атаки SQL-инъекции не только полагаются на возможность вставлять X=Y. **
Если злоумышленники пытаются взломать форму с помощью переменной PHP $_GET или с помощью строки запроса URL, вы сможете поймать их, если они не защищены.
RewriteCond %{QUERY_STRING} ([0-9]+)=([0-9]+)
RewriteRule ^(.*) ^/track.php
Поскольку 1=1, 2=2, 1=2, 2=1, 1+1=2 и т. д. ... являются распространенными вопросами к базе данных SQL злоумышленника. Возможно, он также используется многими хакерскими приложениями.
Но вы должны быть осторожны, чтобы не переписывать безопасный запрос с вашего сайта. Вышеупомянутый код дает вам возможность переписать или перенаправить (зависит от вас) эту динамическую строку запроса, зависящую от хакерства, на страницу, в которой будет храниться IP-адрес злоумышленника или EVEN THEIR COOKIES, история , браузера или любой другой конфиденциальной информации, поэтому вы можете иметь дело с ними позже, запретив их учетную запись или контактные органы.
2 ответа
Я продолжил искать инструкции и нашел это в MSDN:
Выбор между глобальными и локальными файлами ресурсов
Можно использовать любую комбинацию глобальных и локальных файлов ресурсов в веб-приложении. Обычно Вы добавляете ресурсы к глобальному файлу ресурсов, когда Вы хотите совместно использовать ресурсы между страницами. Ресурсы в глобальных файлах ресурсов также со строгим контролем типов для того, когда Вы хотите получить доступ к файлам программно.
Однако глобальные файлы ресурсов могут стать большими при хранении всех локализованных ресурсов в них. Глобальными файлами ресурсов может также быть более трудно управлять, если больше чем один разработчик работает на различных страницах, но в единственном файле ресурсов.
Локальные файлы ресурсов помогают управлять ресурсами для единственной Веб-страницы ASP.NET. Но Вы не можете совместно использовать ресурсы между страницами. Кроме того, Вы могли бы создать много локальных файлов ресурсов, если у Вас есть много страниц, которые должны быть локализованы на многие языки. Если сайты являются большими со многими папками и языками, локальные ресурсы могут быстро развернуть количество блоков в домене приложения.
При внесении изменения в файл ресурсов по умолчанию, или локальный или глобальный, ASP.NET перекомпилировал ресурсы и перезапускает приложение ASP.NET. Это может влиять на общую производительность Вашего сайта. Если Вы добавляете спутниковые файлы ресурсов, это не вызывает перекомпиляцию ресурсов, но приложение ASP.NET перезапустит.
Таким образом, кажется, что это действительно до команды программистов, чтобы взвесить за и против каждого метода и выбрать то, что хорошо для них.
Joe90 - я должен сказать, что, по моему опыту, не могу согласиться, что управление большим количеством локальных файлов ресурсов, рассеянных в течение Вашего целого проекта, легче, чем управление тем, глобальным файлом ресурсов. Нет ничего для остановки повторения тех же переводов снова и снова, и их очень трудно разыскать. Доступ к Глобальному файлу ресурсов очень легко скоординировать в команде, и многочисленные пользователи видят сразу, был ли их необходимый перевод уже сделан.
я начался с точно той же политикой как Lea - т.е. запустите с локального файла ресурсов и затем переместите это в глобальный файл ресурсов, если на нее сослались несколько раз. Это скоро стало загрузками стычки для управления, и я с тех пор переместил в использование глобальных файлов ресурсов каждый раз теперь.
, кажется, нет никаких четких инструкций Microsoft относительно того, что лучшая практика, или даже, как эти два метода реализованы так, чтобы мы могли рисковать предположением!
я предположение , сравнение/выплата - то, что локальные файлы ресурсов только требуют перекомпилировать файла, которого они касаются, тогда как изменение глобального файла ресурсов, кажется, требует, чтобы перекомпилировать целого веб-сайта - со свойственной потерей состояния сеанса и т.д. так потребовало, чтобы выведение из эксплуатации сайта во время обновления было безопасно.