Какие стандарты для символов разрешены в текстовых полях

ПОЖАЛУЙСТА, разрешите апострофы для всех имен О'Брайенов, О'Мэлли, О'Рейли и других имен, содержащих апострофы!

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

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

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

Только не забывайте экранировать вводимые пользователем данные, когда вы выводите их снова.

По какой причине вы должны когда-либо отказываться от каких-либо персонажей? Вы должны просто разрешить все, за возможным исключением нулевого символа. Вам придется кодировать имена пользователей, когда вы печатаете их на своем сайте, чтобы избежать проблем с межсайтовым скриптингом, но вам, вероятно, все равно стоит это сделать, даже если вы фильтруете «опасные» символы на всякий случай. Разрешение использования всех символов, особенно для паролей, значительно увеличивает удобство использования (и безопасность в случае паролей). Также имейте в виду, что некоторые пользователи могут захотеть ввести символы UTF8, если в их именах есть диакритические знаки (или если они используют нелатинский алфавит, например китайский или русский).

Пароли, как абсолютный минимум, должны разрешать доступ к каждому символу с клавиатуры в целевом языковом стандарте (ах).

Если вы ограничиваете символы, это не должен для безопасности (например, предотвращение кавычек, чтобы люди не могли вставлять SQL). Ваш код должен уметь обрабатывать любые символы во входной строке, правильно экранируя их всякий раз, когда они куда-то отправляются. Но их можно ограничить по бизнес-причинам или по некоторым другим практическим причинам (например, пример Зака ​​с URL-адресом).

Будет ли ваше приложение использоваться неанглоязычными пользователями?

По крайней мере разрешите европейские символы вроде á à é è ì.

Конечно, если он должен быть действительно интернационализированным, вы должны разрешить любые символы на таких языках, как китайский и арабский.

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

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

• Поля пароля должны разрешать любые персонажи (вы все равно собираетесь его хешировать, верно?)
• Текстовые поля должны быть ограничены нет определенными символами (например, [A-Za-z]). В противном случае вы запретите людям, которые нуждаются (или хотят) использовать символы с диакритическими знаками. Со стороны базы данных / обработки вы будете экранировать или использовать привязку для сохранения ваших данных.
• Если у вас есть конкретное поле, то знать может принимать только определенный набор символов (бизнес-причины и т. д., Как указано JW). Например, формы, предназначенные только для аудитории из США, могут ограничиваться числами и тире для почтовых индексов.

тоже добавьте к тому, что сказали другие: пароль: все и вся, но хешировать их (конечно)

имя пользователя: все, кроме, возможно, пробела ... или нескольких пробелов (т. е. один пробел в порядке, более одного пробела = 1 пробел)

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