Ниже по коментам уже предложили несколько вариантов:
— помогать генерить сложный пароль
— ввести подсказку-валидатор
— ничего не делать(юзер сам дурак)
— вообще забить на регистрацию и делать через OpenID
Я вас понял, тут вопрос только в валидации данных. Конечно ограничение должно быть, но в пределах нормы. В статье как раз по этому поводу есть 2 пункта:
Не забываем проверять переменные на граничные значения.
Не позволяем загружать длинные строки и тяжелые файлы.
латиница(большие и маленькие буквы), цифры и различные символы уже около 100 символов. Теперь для 10-символьного пароля все возможные варианты 100^10. Что-то я сильно сомневаюсь что перебор поможет.
Согласен, пользователь сам себе злобный буратино, но о последствиях тоже надо думать. Потому как с украдеными акками пользователь побежит сразу к вам и будет требовать вернуть доступ. Но если это не является проблемой, то почему и нет?
Длина пароля никак не влияет на длину хэша. Тут вопрос стоит в том, чтобы выбрать безопасную хэш функцию и обязательно соль.
Если в двух словах: не используйте md5, используйте sha. Почитать можно например тут
Как вариант можно помогать самому пользователю сгенерить хороший пароль. Тут еще вопрос юзабилити, чтоб было и удобно, у просто, и самое главное безопасно.
Вообще тема ddos достаточно обширная. Ее похорошему можно вынести в отдельный пункт. От целенаправленного ddos скорее всего сам не отобьешься, а вот чтобы не завалить себя хабраэффектом — это уже вопрос оптимизации приложения.
«А зачем» еще возникает, когда к примеру в одной онлайн игре хранят в открытом виде и логин и пароль. И при восстановлении пароля отсылают его на email 2 раза. Один раз бот через cron, второй для надежности сам модератор.
согласен, но и разрешать пользователям пароли вида:123456,qwerty,password тоже нельзя. Если и не делать сложных валидаторов, то хотя бы проверять в топе популярных паролей.
В монго эт можно сделать одним запросом. Для таких случаев есть Aggregation framework
Если в двух словах объяснять: сначала $match для нужных нам фильтров, $unwind по оставшимся фильтрам, ну а далее стандартный $group на оставшиеся товары.
Как это работает можете посмотреть на примере в этой статье. Ничего против Seach engine не имею, но такие задачи можно решать и через NoSQL
Как раз для такой ситуации, когда структура товара не однородна и по ним требуется фильтр, подходят NoSQL решения. Притом на той же MongoDB ваша выборка (характеристика1 = true AND (характеристика2 < 100)) OR (характеристика1 = false AND (характеристика3 > 17)) ... далее обычно мешанина из AND\OR
делается одной строчкой, со всеми сортировками, поисками по ключу, без каких-либо проблем.
Как вариант сделать свое IDE для планшетов. На айпаде программить не удобно из-за отсутствия клавиатуры, тут эта проблема решена. Тач скрин для нод подходит идеально.
— помогать генерить сложный пароль
— ввести подсказку-валидатор
— ничего не делать(юзер сам дурак)
— вообще забить на регистрацию и делать через OpenID
Если в двух словах: не используйте md5, используйте sha. Почитать можно например тут
Если в двух словах объяснять: сначала $match для нужных нам фильтров, $unwind по оставшимся фильтрам, ну а далее стандартный $group на оставшиеся товары.
Как это работает можете посмотреть на примере в этой статье. Ничего против Seach engine не имею, но такие задачи можно решать и через NoSQL
(характеристика1 = true AND (характеристика2 < 100)) OR (характеристика1 = false AND (характеристика3 > 17)) ... далее обычно мешанина из AND\ORделается одной строчкой, со всеми сортировками, поисками по ключу, без каких-либо проблем.
У самого было где-то под сотню
dd if=/dev/zero of=tempfile count=512 bs=1024k conv=fdatasync512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 1.68047 s, 319 MB/s