Вопросы Теги

Руководящая сложная сеть. Файлы конфигурации между средами развертывания

Я использую три разных способа предотвращения уязвимости моего веб-приложения для SQL-инъекции.

  1. Использование mysql_real_escape_string(), которое является предопределенной функцией в PHP , и этот код добавляет обратную косую черту к следующим символам: \x00, \n, \r, \, ', " и \x1a. Передайте входные значения в качестве параметров, чтобы свести к минимуму вероятность внедрения SQL.
  2. Самый продвинутый способ - использовать PDO.

Надеюсь, это поможет вам.

Рассмотрим следующий запрос:

$iId = mysql_real_escape_string("1 OR 1=1"); $sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string () здесь не защитит. Если вы используете одиночные кавычки ('') вокруг ваших переменных внутри вашего запроса, это то, что защищает вас от этого. Ниже приведено ниже решение:

$iId = (int) mysql_real_escape_string("1 OR 1=1"); $sSql = "SELECT * FROM table WHERE id = $iId";

В этом вопросе есть хорошие ответы.

Я предлагаю , наилучшим вариантом является использование PDO.

Изменить:

mysql_real_escape_string() устарел с PHP 5.5.0. Используйте либо mysqli, либо PDO.

Альтернативой mysql_real_escape_string () является 

string mysqli_real_escape_string ( mysqli $link , string $escapestr )

Пример: 

$iId = $mysqli->real_escape_string("1 OR 1=1");
$mysqli->query("SELECT * FROM table WHERE id = $iId");

53
задан Robert 2 July 2015 в 02:18
поделиться

9 ответов

Мы разделяем весь регион определенные настройки в их собственный файл конфигурации. Под корнем веб-приложения мы создаем папку конфигурации и размещаем регион определенные настройки туда. Так независимо от того, что файлы живут под корнем конфигурации, будет взят.

наш web.config смотрит что-то как: 

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
    <MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
    <MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
    <MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

Поэтому, если мы развертываемся к региону выпуска, инструмент сборки будет просто иметь действие для замены файлов в корне конфигурации с файлами от соответствующей папки региона. Файловая структура смотрит что-то как:

ДОБАВИЛ: Это - то, как структура управления исходным кодом смотрит, развертываемое приложение просто имело бы dir конфигурации без sub папок или курса 

\Root
   web.config    
   \Config    
       appsettings.config    
       services.config    
       logging.config    
       \release    
          appsettings.config    
          services.config    
          logging.config    
       \debug
          appsettings.config    
          services.config    
          logging.config

, Это довольно чисто и поддерживается любым автоматизированным инструментом сборки (копирование/замена файлов). Хорошее влияние стороны - то, что разработчики могут создать различные разновидности и сохранить их при управлении исходным кодом, не влияя на "реальные" конфигурации.

20
ответ дан Dan 7 November 2019 в 08:52
поделиться

Вы хотите задачу XmlMassUpdate в MSBuildCommunityTasks (делает то, что Вы пытаетесь сделать со своим xml консольным приложением)

http://msbuildtasks.tigris.org/

использование это как это 

  <XmlMassUpdate Condition=" '@(ConfigTemplateFile)'!='' And '@(ConfigSubstitutionsFile)'!=''"
    ContentFile="@(ConfigTemplateFile)"
    SubstitutionsFile="@(ConfigSubstitutionsFile)"
    MergedFile="@(ConfigFile)"
    ContentRoot="/configuration"
    SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>
7
ответ дан JeremyWeir 7 November 2019 в 08:52
поделиться

Вы могли использовать События Сборки для управления веб-конфигурациями. Hanselman имеет хорошую статью об этом.

В основном у Вас есть весь свой различный web.configs в решении, Вы тогда создаете (немного) новые типы сборки. В зависимости от сборки вводят Вас, работает, web.config копируется по, на который ссылаются!

7
ответ дан cgreeno 7 November 2019 в 08:52
поделиться

Я использую метод, объясненный Scott Hanselman (он объясняет его намного лучше, чем я могу воспроизвести это, так перейдите по ссылке:)) Это хорошо работало для меня...

4
ответ дан Cohen 7 November 2019 в 08:52
поделиться

Я использую этот инструмент: xmlpreprocess

мы поддерживаем отдельные файлы 'свойства' для каждой среды, которые объединяются в сценарием развертывания.

4
ответ дан Graham Ambrose 7 November 2019 в 08:52
поделиться

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

2
ответ дан Pedro 7 November 2019 в 08:52
поделиться

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

Lavablast, которым хорошо иметь только один шаблонный файл конфигурации для управления.

недостаток состоит в том, что у Вас не может легко быть пользовательских "разделов".

2
ответ дан mathieu 7 November 2019 в 08:52
поделиться

Я традиционно использовал несколько web.configs, как Вы упомянули. Это может быть боль, но это смягчено файлом, сравнивают инструменты, такие как BeyoneComapare2 или KDIff...

1
ответ дан Jeff Martin 7 November 2019 в 08:52
поделиться

Раздражение:

я упомянул свое небольшое cmd приложение строки для слияния документов XML в моем 1-м обновлении... Хорошо, чтобы сделать это я просто использую XmlDocument, и в конечном счете просто.Save () это к FileStream.

Unfortuantely, узлы не находятся действительно ни в каком конкретном порядке, и по-видимому.NET требует < configSections> элемент быть 1-м ребенком документа.

я думал, что все эти необычные инструменты, как предполагалось, сделали жизнь программирования легче ?

0
ответ дан CodingWithSpike 7 November 2019 в 08:52
поделиться