ColdFusion: проверка на стороне сервера

Question

Есть ли способ улучшить эти проверки полей пользовательских полей на стороне сервера?

<cfif Form.LoginName EQ ""><h1>Login Name is required.</h1></cfif> 
<cfif Form.Password EQ ""><h1>Password is required.</h1></cfif> 
<cfif Form.Password NEQ Form.PasswordConfirmation><h1>Password confirmation does not match Password.</h1></cfif> 
<cfif Form.FirstName EQ ""><h1>First Name is required.</h1></cfif> 
<cfif Form.LastName EQ ""><h1>Last Name is required.</h1></cfif> 

<cfif Form.LoginName EQ "" OR Form.Password EQ "" OR Form.Password NEQ Form.PasswordConfirmation OR Form.FirstName EQ "" OR Form.LastName EQ ""> 
    <p>User has not been created</p> 
    <p>You can use your browser's back button to keep form fields filled and try again.</p> 
    <p><a href="users.cfm">Return to users list</a>.</p> 
    <cfabort> 
</cfif> 

Answer 1

То, как вы связываете свою бизнес-логику с вашим дисплеем, оставляет желать лучшего. Вероятно, вы могли бы воспользоваться чтением на MVC и separation of concerns.

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

Я хотел бы дать некоторые мысли перестать думать процедурно, и думать в более ОО моды, и определить понятие User.cfc, и есть какие-то службы проверки (см ValidateThis). Или что-то типа того.

И, наконец, на самом деле это не вопрос, который лучше всего задал на переполнении стека, но это было бы полезно для Code Review. На этот вопрос нет единого ответа, поэтому люди склонны предлагать закрыть его за то, что они «в основном основаны на мнениях».

Я также собираюсь отложить это как просто «ColdFusion», а не «ColdFusion 10», поскольку он действительно не имеет ничего общего с CF10, это просто вопрос CFML. Вы получите большую аудиторию, которая будет обозначаться как «ColdFusion».

Answer 2

Это другой способ. Вы сами можете решить, лучше ли это.

Шаг 1 - создать переменную сообщения об ошибке.

Шаг 2 - Сделайте свои чеки. Если вы видите что-то, что вам не нравится, добавьте текст в свою переменную.

<cfif len(trim(form.LoginName)) gt 0> 
<cfset ErrorMessage &= "<h3>Login Name is required</h3>"> 
</cfif> 
more checks 

Шаг 3 - Проверить длину сообщения об ошибке переменной

<cfif len(ErrorMessage) gt 0> 
display it 
<cfelse> 
code for no errors 
</cfif> 

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

Еще одна вещь. Вместо тега привязки обратно на страницу формы, как это,

<p><a href="users.cfm">Return to users list</a>.</p> 

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

<p><a href="javascript:history.back()">Return to users list</a>.</p> 

Answer 3

Вместо того, чтобы делиться кодами с вами, я хотел бы представить вам эти концепции. Первое, что вам нужно сделать, это прочитать OWASP recommendations for Data Validation. В ней они предлагают, чтобы было четыре стратегии для проверки данных, и их следует использовать в следующем порядке. Я выложу несколько выдержек здесь, но я настоятельно рекомендую вам прочитать всю статью.

1. Accept удачная
   Эта стратегия также известна как «белый список» или «положительная» проверка. Идея состоит в том, что вы должны проверить, что данные являются одним из наборов сильно ограниченных известных хороших значений. Любые данные, которые не совпадают, должны быть отклонены.

2. Отказ известен плохо
   Эта стратегия, также известная как «отрицательная» или «черная» проверка, является слабой альтернативой положительной проверке. По сути, если вы не ожидаете увидеть такие символы, как% 3f или JavaScript или аналогичные, отбросьте строки, содержащие их. Это опасная стратегия, потому что набор возможных плохих данных потенциально бесконечен. Принятие этой стратегии означает, что вам придется вести список «известных плохих» символов и шаблонов навсегда, и по определению вы будете иметь неполную защиту.

3. Санируйте
   Вместо того, чтобы принять или отклонить вход, еще один вариант заключается в изменении пользовательского ввода в приемлемом формате

4. Нет проверки
   Это по своей сути небезопасным и настоятельно не рекомендуется. Бизнес должен подписать каждый пример отсутствия проверки, поскольку отсутствие проверки обычно приводит к прямому устранению элементов управления приложениями, хостами и сетью.

В статье обсуждаются все эти вопросы более подробно и многое другое.