Вопросы Теги

Каков наилучший способ проверки ввода пользователя. PHP или Javascript? [Дубликат]

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

Предположим, у вас есть веб-форма Contact.aspx, чей класс codebehind Свяжитесь с вами, и у вас есть имя объекта Contact.

Затем следующий код вызовет исключение NullReferenceException при вызове context.SaveChanges () 

Contact contact = new Contact { Name = "Abhinav"};
var context = new DataContext();
context.Contacts.Add(contact);
context.SaveChanges(); // NullReferenceException at this line

Ради полноты класса DataContext 

public class DataContext : DbContext 
{
    public DbSet Contacts {get; set;}
}

и класс сущности контакта. Иногда классы сущностей являются частичными классами, так что вы можете распространять их и в других файлах. 

public partial class Contact 
{
    public string Name {get; set;}
}

Ошибка возникает, когда оба класса entity и codebehind находятся в одном и том же пространстве имен. Чтобы исправить это, переименуйте класс сущности или класс codebehind для Contact.aspx.

Причина. Я все еще не уверен в причине. Но всякий раз, когда какой-либо из классов сущностей расширяет System.Web.UI.Page, возникает эта ошибка.

Для обсуждения рассмотрим NullReferenceException в DbContext.saveChanges ()

145
задан Yi Jiang 15 March 2011 в 07:01
поделиться

12 ответов

Как говорили другие, вы должны сделать то и другое. Вот почему:

Сторона клиента

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

Если вы только проверяете на сервере, они должны отправить форму, получить сообщение об ошибке и попытаться выследить проблему.

(Эта боль может быть ослаблена, если сервер повторно отобразит форму с исходным входом пользователя, но проверка на стороне клиента еще быстрее.)

Сторона сервера

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

Очень опасно доверять вашему пользовательскому интерфейсу. Мало того, что они могут злоупотреблять вашим пользовательским интерфейсом, но они могут вообще не использовать ваш пользовательский интерфейс или даже браузер. Что делать, если пользователь вручную редактирует URL-адрес или запускает собственный Javascript или настраивает свои HTTP-запросы другим инструментом? Что делать, если они отправляют пользовательские HTTP-запросы из curl или из сценария, например?

( Это не теоретически, например, я работал в поисковой системе путешествия, которая повторно отправила пользовательскую искать во многих авиакомпаниях, автобусных компаниях и т. д., отправив POST запросы, как если бы пользователь заполнил форму поиска каждой компании, а затем собрал и отсортировал все результаты. Форма этих компаний JS никогда не исполнялась, и для нас это было важно что они предоставляют сообщения об ошибках в возвращенном HTML. Конечно, API был бы приятным, но это было то, что мы должны были сделать. )

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

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

Addendum - December 2016

Существуют некоторые проверки, которые даже не могут быть правильно выполнены в коде приложения на стороне сервера и совершенно невозможны в клиентском коде, поскольку они зависят от текущего состояния базы данных. Например, «никто еще не зарегистрировал это имя пользователя» или «сообщение в блоге, которое вы комментируете по-прежнему существует», или «отсутствие существующего резервирования не совпадает с запрошенными вами датами» или «баланс вашего аккаунта по-прежнему достаточно для покрытия этой покупки «. Только база данных может достоверно проверять данные, которые зависят от связанных данных. Разработчики регулярно закручивают это , но PostgreSQL предоставляет некоторые хорошие решения .

284
ответ дан Nathan Long 28 August 2018 в 06:39
поделиться

Клиентская сторона должна использовать базовую проверку с помощью типов входных типов HTML5 и и поскольку они используются только для прогрессивных улучшений для лучшего удобства пользователя (даже если они не являются поддерживается на & lt; IE9 и сафари, но мы не полагаемся на них). Но основная проверка должна произойти на стороне сервера.

4
ответ дан adardesign 28 August 2018 в 06:39
поделиться

Вы можете выполнить проверку на стороне сервера и отправить обратно объект JSON с результатами проверки для каждого поля, с минимальным клиентом Javascript (просто отображать результаты) и по-прежнему иметь удобный интерфейс без необходимости повторять себя как на клиенте, так и на сервер.

8
ответ дан Jonathan 28 August 2018 в 06:39
поделиться

Ну, я все еще нахожу какую-то комнату для ответа.

В дополнение к ответам Роба и Натана, я бы добавил, что валидация на стороне клиента имеет значение. Когда вы применяете проверки на своих веб-формах, вы должны следовать этим рекомендациям:

Клиентская сторона

  1. Необходимо использовать проверки на стороне клиента для фильтрации подлинных запросов, поступающих от настоящих пользователей на вашем веб-сайте.
  2. Валидация на стороне клиента должна использоваться для уменьшения ошибок, которые могут возникать при обработке на стороне сервера.
  3. Валидация на стороне клиента должна использоваться для минимизации серверно- чтобы вы сохраняли пропускную способность и запросы на пользователя.

Серверная сторона

  1. Вы НЕ ДОЛЖНЫ предполагать, что проверка, выполненная на стороне клиента, на 100% идеальна. Неважно, даже если он обслуживает менее 50 пользователей. Вы никогда не знаете, какой из ваших пользователей / emplyee превращается в «зло» и совершает какую-то вредную деятельность, зная, что у вас нет надлежащих валидаций.
  2. Даже если он совершенен с точки зрения проверки адреса электронной почты, телефонных номеров или проверяя некоторые допустимые входы, он может содержать очень вредные данные. Который должен быть отфильтрован на стороне сервера, независимо от его правильности или неправильности.
  3. Если проверка на стороне клиента обойдена, ваши проверки на стороне сервера приходят, чтобы спасти вас от любого потенциального ущерба вашей серверной стороне обработка. В последнее время мы уже слышали много историй о SQL Injections и других методах, которые могут быть применены для получения некоторых злых преимуществ.

Оба типа валидаций играют важную роль в их соответствующий охват, но самый сильный - серверный. Если вы получаете 10 тыс. Пользователей в один момент времени, то вы, несомненно, в конечном итоге отфильтровываете количество запросов, поступающих на ваш веб-сервер. Если вы обнаружите, что произошла одна ошибка, например, неверный адрес электронной почты, они снова отправляют форму и просят пользователя исправить ее, что определенно будет использовать ресурсы вашего сервера и пропускную способность. Поэтому лучше применять проверку JavaScript. Если javascript отключен, ваша проверка на стороне сервера придет на помощь, и я ставлю, что только несколько пользователей могут случайно отключить его, так как 99,99% веб-сайтов используют javascript и уже включены по умолчанию во всех современных браузерах.

6
ответ дан KMX 28 August 2018 в 06:39
поделиться

Вы должны всегда проверять на сервере.

Кроме того, проверка подлинности на клиенте приятна для пользователей, но совершенно небезопасна.

17
ответ дан Peter Boughton 28 August 2018 в 06:39
поделиться

Преимущество проверки на стороне сервера с помощью проверки на стороне клиента заключается в том, что проверка на стороне клиента может быть обойдена / изменена:

  • Конечный пользователь может отключить javascript
  • Данные могут быть отправлены непосредственно на ваш сервер кем-то, кто даже не использует ваш сайт, с помощью специального приложения, предназначенного для этого.
  • Ошибка Javascript на вашей странице (вызванная любым количеством вещей) может привести к некоторые, но не все, вашей проверки работоспособности

Короче - всегда всегда проверяйте серверную сторону, а затем рассматривайте проверку на стороне клиента как добавленную «дополнительную», чтобы улучшить работу конечного пользователя .

30
ответ дан Rob 28 August 2018 в 06:39
поделиться

Я столкнулся с интересной ссылкой, которая делает различие между грубыми, систематическими и случайными ошибками.

Client-Side validation идеально подходит для предотвращения грубых и случайных ошибок. Обычно максимальная длина текстуры и ввода. Не имитируйте правило проверки на стороне сервера; (например, 200 символов на стороне клиента, n на стороне сервера, продиктованной сильным бизнес-правилом).

Server-side validation идеально подходит для предотвращения систематического ошибки; он будет обеспечивать соблюдение бизнес-правил.

В проекте, в котором я участвую, проверка выполняется на сервере через запросы ajax. На клиенте я отображаю сообщения об ошибках соответственно.

Дальнейшее чтение: грубые, систематические случайные ошибки:

https://answers.yahoo.com/question/index? QID = 20080918203131AAEt6GO

1
ответ дан roland 28 August 2018 в 06:39
поделиться

JavaScript может быть изменен во время выполнения.

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

Вам понадобится отдельная логика проверки на обоих концах, например:

"required" атрибуты на стороне inputs на стороне клиента

field.length > 0 server- .

Но использование той же спецификации проверки исключает некоторую избыточность (и ошибки) проверки зеркалирования на обоих концах.

2
ответ дан TaylorMac 28 August 2018 в 06:39
поделиться

Я просто повторю его, потому что это очень важно:

Всегда проверяйте на сервере

и добавляйте JavaScript для пользовательской реакции .

35
ответ дан Toby Hede 28 August 2018 в 06:39
поделиться

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

-2
ответ дан Tom 28 August 2018 в 06:39
поделиться

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

74
ответ дан Vinko Vrsalovic 28 August 2018 в 06:39
поделиться

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

Update Jul 23 2018: следующая ссылка больше недоступна:

Здесь вы можете найти соответствующую информацию http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

2
ответ дан yogescicak 28 August 2018 в 06:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: