так как это правильно

я впервые пишу на nodejs, и хочу валидировать на бэкенде

оно в целом везде одинаково, тут нода прям сильно не аффектит ничего

это понятно

просто советы а-ля валидируй на фронте, или вообще всё пропускай

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

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

так как это правильно

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

на фронте - простая валидация для проверки пустоты, может минимальный regexp

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

Например, зачем сравнивать поля Password и Confirm Password на сервере?

на фронте - простая валидация для проверки пустоты, может минимальный regexp

О такой валидации и шла речь в том разговоре, насколько я понял

на фронте - простая валидация для проверки пустоты, может минимальный regexp

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

Например, зачем сравнивать поля Password и Confirm Password на сервере?

Именно так в вк и зародились лица среднего пола родившиеся в -3876 году

Например, зачем сравнивать поля Password и Confirm Password на сервере?

какое брать? первое второе? или полагать что они одинаковые слепо?

49 квентебря

Верните мне мой 2009

какое брать? первое второе? или полагать что они одинаковые слепо?

Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.

Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.

надо и там и там сравнивать

зачем?

какое брать? первое второе? или полагать что они одинаковые слепо?

Из поля "пароль", очевидно.

ребят вы серьезно? я уже две статьи прочитал, и вы все спорите НАДО ЛИ ВАЛИДИРОВАТЬ

надо и там и там сравнивать

Это где например?

ребят вы серьезно? я уже две статьи прочитал, и вы все спорите НАДО ЛИ ВАЛИДИРОВАТЬ

спор ни о чем

Это где например?

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

спор ни о чем

да, кому нужны эти уязвимости смешные

Тут все понимают, что важное нужно валидировать на сервере

Суть повторения пароля для пользователя - для запоминания пароля пользователем (своего введённого пароля) и проверки того, что он сам же ввел. Случается, что пользователь вводит первый пароль не такой, какой он хотел на самом деле. Для каких целей сравнивать два пароля в серверной? Т.е. задача отправить два пароля, сравнить и в случае не удачи показать пользователю? Но зачем? В случае проверки двух паролей на фронте, отправляйте один пароль на сервер. Пользователь удостоверился что пароль ввёл тот, который хотел. Разве не так, поправьте.

А на сервере проверяйте пароль как угодно уже. Один.

Суть повторения пароля для пользователя - для запоминания пароля пользователем (своего введённого пароля) и проверки того, что он сам же ввел. Случается, что пользователь вводит первый пароль не такой, какой он хотел на самом деле. Для каких целей сравнивать два пароля в серверной? Т.е. задача отправить два пароля, сравнить и в случае не удачи показать пользователю? Но зачем? В случае проверки двух паролей на фронте, отправляйте один пароль на сервер. Пользователь удостоверился что пароль ввёл тот, который хотел. Разве не так, поправьте.

И я о том же говорил, бессмысленно сравнивать два пароля на сервере.

Зачем ещё два пароля сравнивать? Для каких целей для этого сервер?

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

Если говорить о пароле, то можно поговорить ещё и E-Mail. Иногда просят ввести дважды, чтобы не смог ошибку допустить.

А ещё просят повторить ответ на контрольный вопрос.

Зачем ещё два пароля сравнивать? Для каких целей для этого сервер?

зачем тебе два поля пароля на сервере? валидируй форму на фронте, и шли одно поле, но проверять что тебе прислали все равно нужно

зачем тебе два поля пароля на сервере? валидируй форму на фронте, и шли одно поле, но проверять что тебе прислали все равно нужно

А, это да.

никто не говорил, что не нужно

Я просто понял то, что сказали что два пароля нужно отправлять.

ну подтверждение пароля при регистрации это олдскул вообще

Не просто так же написал :)

Aleksandr уже не актуально?)

при смене еще куда ни шло

ну подтверждение пароля при регистрации это олдскул вообще

Согласен, но используют. Так сказать помогают пользователю не ввести то, что он не хотел.

А про валидицию на сервере естественно.

А про валидицию на сервере естественно.

ну выше несколько человек удивлялись мол да зачем это вообще?

Нет, они говорили про другое.

https://twitter.com/nodejs/status/884822255032823810

ну выше несколько человек удивлялись мол да зачем это вообще?

Они говорили про валидацию для юзверей, подобно сравнению Password === Confirm Password. Никто не говорил, что не нужно вообще не проверять данные, что приходят на сервер.

Написал библиотеку для ВК ботов, скоро повесят ее в оф документацию ВК, хотелось бы услышать ваше мнение о ней: https://github.com/bifot/botact

Единственный вопрос который хотел задать, этакий опрос касаемо валидации данных на сервере. Предположим есть Mongo & Mongoose со своими требования к полям, ок, есть. В случае не правильных данных, получаем еррор и показываем фронту. А есть ещё валидация входных параметров в метод (так скажем)? Вопрос, юзать один? Но какой? Или юзать оба? Многие говорят один, и не говорят какой.

Написал библиотеку для ВК ботов, скоро повесят ее в оф документацию ВК, хотелось бы услышать ваше мнение о ней: https://github.com/bifot/botact

Очень походит на Telegraf

А так мне нравится

Да, на него подсматривал, Телеграф — отличный фреймворк.

Я имею в виду, что нет смысла сравнивать Password === Confirm Password на бэкэнде, а не на фронте.

надо и там и там сравнивать

Цитата: "И там и там сравнивать" Когда прочитал, понял что Александр имеет ввиду сравнивать два пароля как на сервере, так и на фронте и решил подключиться. Зная то, что могу быть не прав, решил написать свою точку зрения и спросить у общества :)

[прошел час...]

[прошел час...]

Я здесь не более 10 минут :) больше не буду.

Единственный вопрос который хотел задать, этакий опрос касаемо валидации данных на сервере. Предположим есть Mongo & Mongoose со своими требования к полям, ок, есть. В случае не правильных данных, получаем еррор и показываем фронту. А есть ещё валидация входных параметров в метод (так скажем)? Вопрос, юзать один? Но какой? Или юзать оба? Многие говорят один, и не говорят какой.

Есть ответ у кого-нибудь?

Цитата: "И там и там сравнивать" Когда прочитал, понял что Александр имеет ввиду сравнивать два пароля как на сервере, так и на фронте и решил подключиться. Зная то, что могу быть не прав, решил написать свою точку зрения и спросить у общества :)

ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат

ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат

То, что одна валидация - уже давно понял, но что преимущественнее?

Ответ на данный вопрос ожидал в основном :)

То, что одна валидация - уже давно понял, но что преимущественнее?

преимущественнее чего?

преимущественнее чего?

Две валидации: 1. Метод. 2. База.

ну конкретно в этом случае лучше использовать вообще одно и валидировать только формат

Две валидации: 1. Метод. 2. База.

если ты про валидацию на сервере то в БД надо класть только уже очищенные и валидные данные, сама БД ничего не должна проверять. так делают далеко не всегда)

К примеру у меня есть валидации в так называемых схемах/моделях Mongo, а конкретнее в Mongoose. Скажем что одно поле - обязательно, другое такое, а другое такое.

Т.е. проверка на данные есть.

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

ERROR: S client not available

Т.е. валидация есть.

Другой вопрос, использовать две валидации? Или одну? Одна к примеру у Mongoose, другая у самого метода. Т.е. есть мидлварь функцию проверяющая данные.

Вот к чему клоню :)

Мне просто интересно на самом деле.

Я не пытаюсь так докалупаться или ещё чего-нибудь :)

Просто интерес ответ.

Т.е. валидация есть.

валидация формата, но у тебя данные имеют не только формат же

Мне нужна проверка на наличие параметра. У параметра тип данных, связь в базе (у Mongoose можно), количество данных в чем-либо и т.д. и т.д.

Другой вопрос, использовать две валидации? Или одну? Одна к примеру у Mongoose, другая у самого метода. Т.е. есть мидлварь функцию проверяющая данные.

ну пытаться совать в любую БД данные в которых ты не уверен уж точно не стоит, надо предварительно проверить и очистить их

Раньше я ещё попутно кроме самой базы юзал и валидации в самом методе.

С недавних пор отказался.

Дали по голове, сказали что мол куда две валидации то? Мол там и тут? Зачем? Ну я такой говорю что так безопасней (хотя частично, очень очень маленький процент).

Интересно пол года с инъекция на монгу, в итоге два проекта положил насмерть

Ума хватило не прод бомбануть

Это как раньше студенты искали порты монги и они все открытые были

Вот потеха была...

Сейчас то хоть конфиги монги не открывают внешний порт

А так разрабы и не проверяли даже...

Это как раньше студенты искали порты монги и они все открытые были

теперь ищут порты докера и майнят на них

Я не из этой темы

А хотелось бы, очень ?

Я про докер :)

Дали по голове, сказали что мол куда две валидации то? Мол там и тут? Зачем? Ну я такой говорю что так безопасней (хотя частично, очень очень маленький процент).

на мой взгляд нужно делать валидацию до работы с любым хранилищем

И там и там значит

И метод, и база.

И там и там значит

в базе на мой взгляд не обязательно

Логика есть

Мол если хороший валидатор, тесты есть, то для меньшего потребления ресурсов отключить все валидации

Ну там должны быть ещё валидации

Как связи к примеру

Хорошо штука работает

В Mongoose естественно.