Пользователей нужно разрешить введенному пароль с пространством вначале или концом? [закрытый]
Проблема решена, во многом благодаря всем, кто помог мне понять, что я не делаю CORS должным образом. По сути, было две проблемы: 1. Я не знал, как правильно установить заголовки в бэкэнде, и 2. Я не форматировал свои данные JSON должным образом.
Я заметил, что это довольно популярная проблема переполнения стека, возможно, отчасти потому, что некоторые из нас не совсем понимают, как работают запросы. Итак, вот резюме, взятое из бесценной и просто написанной документации Mozilla и комментариев пользователя user268396. Я новичок в этом, поэтому, пожалуйста, поправьте меня, если я ошибаюсь.
Обычно это просто: когда вы хотите что-то запросить, браузер устанавливает соответствующие заголовки на основе того, что у вас уже есть, и отправляет запрос. Сервер отвечает.
Но, предполагая, что у вас есть конечная точка API POST на вашем внутреннем сервере и внешний интерфейс в том же домене (я полагаю, это большинство из нас в разработке, хотя, возможно, не в производстве), и вы работаете с чем-то другим, кроме application / x-www-form-urlencoded, multipart / form-data и text / plain, тогда это немного по-другому. В моем случае я работаю с приложением / JSON. Итак, это выглядит так:
-
Браузер отправляет запрос методом OPTIONS, спрашивая, какие методы и типы контента и другие вещи разрешены. Это называется предполетным запросом. Он еще не отправил мой объект JSON.
-
Сервер отвечает на предварительный запрос.
Чтобы сервер отвечал разрешенными вещами, нам нужно правильно настроить серверную часть, чтобы разрешить метод OPTIONS в Access-Control-Allow-Methods, и если вы, как и я, используете Gorilla mux, запомните разрешить это и в router.HandleFunc().
Поскольку наши передние и внутренние части находятся в одном домене ( http: // localhost ), проще всего установить Access-Control-Allow-Origin в «*». Тем не менее, мы, вероятно, не хотим делать это на производстве в зависимости от наших потребностей, поскольку * означает, что весь мир и за его пределами могут отправлять запросы.
Поскольку я хочу получать JSON, я также установил Content-Type в бэкэнде на application / json. Это была другая половина моей проблемы. Короче говоря, независимо от того, что сработало для других людей, по какой-то причине мне все же пришлось применить JSON.stringify() к моим необработанным данным JSON. Тогда это сработало идеально.
- Как только браузер получает обратно разрешенные ОПЦИИ, он отфильтровывает запрещенные данные и отправляет запрос только с соответствующими данными. В моем случае это будет объект JSON.
И это все.
10 ответов
Да, они должны.
- меня ни к какому концу раздражает, когда люди решают, как мой пароль должен вести себя особенно, когда это бессмысленно. Я хотел бы больше чем 8 символов.
- необходимо хешировать пароль, таким образом, максимальные длины знака и пробелы в конце не имеют значения.
нет, Вы не должны обрезать его.
- Вы требуете, чтобы пользователь ввел пароль дважды (при создании его) для устранения опечаток. Поэтому пространство не имеет значения.
Позвольте мне рассказать Вам историю.
я должен был создать учетную запись на сайте электронной коммерции, таким образом, я выполнил свой случайный генератор пароля для создания 8 символьных верхних/ниже/чисел/пунктуации паролей, вставил его в дважды для подтверждения этого, закончил регистрироваться во всех своих персональных данных и сохранил случайный пароль в локальном PGP-зашифрованном-файле для более позднего использования.
Позже я пытался войти в систему, но вставить пароль снова не работало. После небольшого количества тестирования я был испуган, чтобы найти, что сайт разделил все знаки пунктуации от старого пароля, в некоторой дезинформированной попытке санитизации, уменьшив мой пароль до трех легко грубых forceable букв.
не обрезают или санируют пароли пользователей.
Никогда не "очищайте" пароль просто для составления "ввода ошибок". Это смутит пользователей и в некоторых случаях лишит возможности их входить в систему. На самом деле никогда не изменяйтесь, пароль за спиной пользователя... всегда предупреждают их, что пароль является неверным, и позвольте им попробовать новый.
А хороший пример, с которым я недавно столкнулся, был с переключателем 3Com. Веб-интерфейс позволил мне изменять пароль администратора, но не предупредил меня, что пароль был ограничен восемью символами. Я ввел пароль, который был дольше, чем восемью символами. Когда я пытался войти в систему после изменения это просто отклонило мой пароль. Если я только использовал первые восемь символов, однако, я смог войти в систему (метод проб и ошибок с моей стороны, не забава).
Пароли в эти дни не смотрят способ, для которого они привыкли. Например, мои пароли часто похожи на это:
Man, this program is really ticking me off!
Необходимо проверить пароль с полем подтверждения так или иначе. Если они делают опечатку дважды - тогда Вы, надо надеяться, имеете, забыл пароль или функцию сброса на месте.
пространство не должно иметь значения, поскольку Вы не должны хранить его в простом тексте.
Моментом Вы принимаете такое решение, является момент, Вы начинаете спускаться с пути микроуправления (по Вашим пользователям в этом случае).
Делает пароль, содержащий повреждение пространства Ваша система? Или действительно ли это - угроза безопасности? Тогда не волнуйтесь. Позвольте своим пользователям иметь дело со своими собственными ошибками, даже если это означает, что они должны быть расстроены. Их опечатка никогда не должна быть Вашей проблемой.
Я не раз бывал на конференции, где кто-то входил в свою учетную запись для демонстрации после того, как дисплей компьютера уже был на большом экране, неправильно менял фокус на поле пароля и, следовательно, его пароль было открыто всей аудитории.
Любой, кому может потребоваться ввести учетные данные перед другими, должен на всякий случай оставить один или три символа в конце своего пароля. И при создании систем аутентификации вы не должны никогда обрезать эти пробелы.
Я не забочусь. Пока независимо от того, что Вы делаете к паролю, когда он устанавливается, также сделан к нему, будучи вводимым позже. Обрезка, усеченная, случай изменения, соль, хеш, безотносительно - просто, последовательно делает это.
, По-видимому, Вы не храните фактический пароль так или иначе, таким образом...
Пробел является обычным символом пароля, и вы не должны его удалять.
Поскольку вы, вероятно, хешируете пароль перед сохранением его в базе данных, пробел будет обрабатываться как любой другой символ.
Так как это - плохой амулет для хранения пароля как текста, нет никакой потребности обрезать () пароль, так как это будет сразу хешировано.
... на подобной ноте, я корректен в вере, что пароли не должны должны быть быть regex, проверенным к для внедрения SQL, так как они будут хешированы и не вставлены как простой текст в базе данных?
Хорошо, чтобы пароль содержал его, как уже упоминалось, однако я бы добавил, что при создании новых случайных паролей (скажем, для разумной системы сброса паролей с потерями) следует избегать генерации паролей, содержащих такие хитрые символы.
Если пароль достаточно длинный и случайный, это компенсирует ограничение в несколько хитрых символов, что значительно облегчит жизнь конечному пользователю ...