Dika
Тут все понимают, что важное нужно валидировать на сервере
O.
Суть повторения пароля для пользователя - для запоминания пароля пользователем (своего введённого пароля) и проверки того, что он сам же ввел.
Случается, что пользователь вводит первый пароль не такой, какой он хотел на самом деле.
Для каких целей сравнивать два пароля в серверной? Т.е. задача отправить два пароля, сравнить и в случае не удачи показать пользователю? Но зачем?
В случае проверки двух паролей на фронте, отправляйте один пароль на сервер. Пользователь удостоверился что пароль ввёл тот, который хотел.
Разве не так, поправьте.
O.
А на сервере проверяйте пароль как угодно уже. Один.
Dika
Суть повторения пароля для пользователя - для запоминания пароля пользователем (своего введённого пароля) и проверки того, что он сам же ввел.
Случается, что пользователь вводит первый пароль не такой, какой он хотел на самом деле.
Для каких целей сравнивать два пароля в серверной? Т.е. задача отправить два пароля, сравнить и в случае не удачи показать пользователю? Но зачем?
В случае проверки двух паролей на фронте, отправляйте один пароль на сервер. Пользователь удостоверился что пароль ввёл тот, который хотел.
Разве не так, поправьте.
И я о том же говорил, бессмысленно сравнивать два пароля на сервере.
O.
Зачем ещё два пароля сравнивать? Для каких целей для этого сервер?
O.
Если он такой кулхацкер, мол, взял и обманул фронт на наличие проверки второго пароля, и что? Молодец, твой же пароль, а мы тебе просто помогли ещё не забыть.
O.
Если говорить о пароле, то можно поговорить ещё и E-Mail. Иногда просят ввести дважды, чтобы не смог ошибку допустить.
O.
А ещё просят повторить ответ на контрольный вопрос.
Aleksand
Зачем ещё два пароля сравнивать? Для каких целей для этого сервер?
зачем тебе два поля пароля на сервере? валидируй форму на фронте, и шли одно поле, но проверять что тебе прислали все равно нужно
Dika
никто не говорил, что не нужно
O.
Я просто понял то, что сказали что два пароля нужно отправлять.
Aleksand
ну подтверждение пароля при регистрации это олдскул вообще
O.
Не просто так же написал :)
Anonymous
Aleksandr уже не актуально?)
Aleksand
при смене еще куда ни шло
O.
ну подтверждение пароля при регистрации это олдскул вообще
Согласен, но используют.
Так сказать помогают пользователю не ввести то, что он не хотел.
O.
А про валидицию на сервере естественно.
Aleksand
А про валидицию на сервере естественно.
ну выше несколько человек удивлялись мол да зачем это вообще?
Dika
Нет, они говорили про другое.
Dika
ну выше несколько человек удивлялись мол да зачем это вообще?
Они говорили про валидацию для юзверей, подобно сравнению Password === Confirm Password. Никто не говорил, что не нужно вообще не проверять данные, что приходят на сервер.
Mikhail
Написал библиотеку для ВК ботов, скоро повесят ее в оф документацию ВК, хотелось бы услышать ваше мнение о ней: https://github.com/bifot/botact
O.
Единственный вопрос который хотел задать, этакий опрос касаемо валидации данных на сервере.
Предположим есть Mongo & Mongoose со своими требования к полям, ок, есть.
В случае не правильных данных, получаем еррор и показываем фронту.
А есть ещё валидация входных параметров в метод (так скажем)?
Вопрос, юзать один? Но какой? Или юзать оба?
Многие говорят один, и не говорят какой.
O.
O.
А так мне нравится
Mikhail
Да, на него подсматривал, Телеграф — отличный фреймворк.
O.
Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.
O.
надо и там и там сравнивать
O.
Цитата: "И там и там сравнивать"
Когда прочитал, понял что Александр имеет ввиду сравнивать два пароля как на сервере, так и на фронте и решил подключиться.
Зная то, что могу быть не прав, решил написать свою точку зрения и спросить у общества :)
CherryTea
[прошел час...]
Aleksand
Цитата: "И там и там сравнивать"
Когда прочитал, понял что Александр имеет ввиду сравнивать два пароля как на сервере, так и на фронте и решил подключиться.
Зная то, что могу быть не прав, решил написать свою точку зрения и спросить у общества :)
ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат
O.
ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат
То, что одна валидация - уже давно понял, но что преимущественнее?
O.
Ответ на данный вопрос ожидал в основном :)
O.
ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат
ixplo
Aleksand
Две валидации:
1. Метод.
2. База.
если ты про валидацию на сервере то в БД надо класть только уже очищенные и валидные данные, сама БД ничего не должна проверять. так делают далеко не всегда)
O.
К примеру у меня есть валидации в так называемых схемах/моделях Mongo, а конкретнее в Mongoose. Скажем что одно поле - обязательно, другое такое, а другое такое.
O.
Т.е. проверка на данные есть.
O.
Но проверка осуществляется тогда, когда я пытаюсь уже сохранить, т.е. уже получил данные, обратился к сохранению и получил ошибку.
O.
Т.е. валидация есть.
O.
Другой вопрос, использовать две валидации? Или одну? Одна к примеру у Mongoose, другая у самого метода. Т.е. есть мидлварь функцию проверяющая данные.
O.
Вот к чему клоню :)
O.
Мне просто интересно на самом деле.
O.
Я не пытаюсь так докалупаться или ещё чего-нибудь :)
O.
Просто интерес ответ.
O.
Мне нужна проверка на наличие параметра. У параметра тип данных, связь в базе (у Mongoose можно), количество данных в чем-либо и т.д. и т.д.
Aleksand
Другой вопрос, использовать две валидации? Или одну? Одна к примеру у Mongoose, другая у самого метода. Т.е. есть мидлварь функцию проверяющая данные.
ну пытаться совать в любую БД данные в которых ты не уверен уж точно не стоит, надо предварительно проверить и очистить их
O.
Раньше я ещё попутно кроме самой базы юзал и валидации в самом методе.
O.
С недавних пор отказался.
O.
Дали по голове, сказали что мол куда две валидации то? Мол там и тут? Зачем? Ну я такой говорю что так безопасней (хотя частично, очень очень маленький процент).
O.
Интересно пол года с инъекция на монгу, в итоге два проекта положил насмерть
O.
Ума хватило не прод бомбануть
O.
Это как раньше студенты искали порты монги и они все открытые были
O.
Вот потеха была...
O.
Сейчас то хоть конфиги монги не открывают внешний порт
O.
А так разрабы и не проверяли даже...
Aleksand
Это как раньше студенты искали порты монги и они все открытые были
теперь ищут порты докера и майнят на них
O.
Я не из этой темы
O.
А хотелось бы, очень 😥
O.
Я про докер :)
Aleksand
Дали по голове, сказали что мол куда две валидации то? Мол там и тут? Зачем? Ну я такой говорю что так безопасней (хотя частично, очень очень маленький процент).
на мой взгляд нужно делать валидацию до работы с любым хранилищем
O.
И там и там значит
O.
И метод, и база.
O.
Логика есть
O.
Мол если хороший валидатор, тесты есть, то для меньшего потребления ресурсов отключить все валидации
O.
Ну там должны быть ещё валидации
O.
Как связи к примеру
O.
Хорошо штука работает
O.
В Mongoose естественно.
O.
Типа хуков небольших
Aleksand
Мол если хороший валидатор, тесты есть, то для меньшего потребления ресурсов отключить все валидации
ну дублировать логику валидации в БД не особенно нужно, а перепутать типы и связи она не даст
O.
Понял, спасибо за ответ и небольшой совет :)
KlonD90
ну дублировать логику валидации в БД не особенно нужно, а перепутать типы и связи она не даст
ну ток тесты надо написать тогда интеграционные что у тебя бд правильно подключена
Aleksand
ну ток тесты надо написать тогда интеграционные что у тебя бд правильно подключена
а что ты имеешь ввиду по "правильно подключена"?