Какие стандарты для символов разрешены в текстовых полях - PullRequest
3 голосов
/ 20 января 2009

Какие типичные символы допускаются в текстовых полях при регистрации нового пользователя? Существуют ли стандарты www? Особенно интересны разрешенные типы символов «Имя пользователя» и «Пароль».

Ответы [ 10 ]

12 голосов
/ 20 января 2009

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

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

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

4 голосов
/ 20 января 2009

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

4 голосов
/ 20 января 2009

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

3 голосов
/ 20 января 2009

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

2 голосов
/ 20 января 2009

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

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

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

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

Как минимум разрешить использование европейских символов, таких как à é è ì.

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

Похоже, вы не можете составить список разрешенных персонажей, если не хотите свести с ума.

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

2 голосов
/ 20 января 2009

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

1 голос
/ 30 ноября 2009

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

1 голос
/ 20 января 2009

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

...