А у нас потопы. Даже в Краков Висла из берегов вышла, я за 3 года такого не видел и близко. А Силезию и Татры вообще затопило, мы только собирались на выходные сгонять в ту сторону, вовремя передумали.
SHA-256 по умолчанию.
В итоге написал декоратор( надеюсь никому не нужно обьяснять что это за паттерн), который по умолчению применяется на все роуты и проверяет права пользователя. Теперь даже случайно не удастся сделать страницу с неправильным доступом. Автоматом перекидывает на страницу логина.
Теперь ломаю голову над правильной организацией БД
Тут уже много ответов. Уточняй, какие вопросы возникли
Принимается, если говорить в таком ключе. Но сакцентирую - это не предмет топика. Мне интересен перевод определенного интерфейса, который будет очень редко, практически никогда меняться. Для этого использовать БД нецелесообразно.
Перечитай название темы для начала. При чем тут меню? Я тоже когда то в проекте делал динамическое добавление страниц в меню. Записи с определенным типом, например, категория, автоматически добавлялись в меняю. В этой теме разговор идет о простом и быстром переводе интерфейса, тратить ресурс базы данных на который будет только очень неумелый разработчик.
Ну так за него платить же надо, от 250 Евро в год, откуда у вебмастеров такие деньги)))
Обожаю продукты от JenBrains, считаю их лучшими на рынке. Но они хотят хорошего железа чем дальше тем больше. С год назад пришлось работать на на очень дохлой VDI через Citrix. Попробовал VScode и как то незаметно он стал для меня основной идешкой. В чем то даже удобнее Пайчарма. Причем обновление 23 года сделало его интерфейс похожим на как раз VSCode
Довольно странное заявление. Ты когда-нибудь заглядывал в код или в БД популярных CMS? Попробуй заглянуть. У них меню в базе данных. Либо генерится "на лету" в случае динамического контента (но это явно не случай ТС). Никакими файлами там и не пахнет. Правда, есть и исключения - Битрикс, например.Хранение данных в БД - общепринятая практика. Для того и разрабатывались реляционные базы данных.
Не стоит рассуждать о том, в чем не разбираешься. Приводить в пример то, как построены "популярные ЦМС" - показывать свою ограниченность. Они разработаны для массового пользователя, там цель - не максимальная скорость и гибкость, а дать юзеру с поверхностными знаниями возможность быстренько создать сайтик. Ты хоть раз делал профилирование запросов? Одно дело, когда на сайт заходит 5-10-20 тысяч пользователей почитать новости там пообщаться. И другое дело когда сидят постоянно такое количество и работают плотно с информацией. Все слезы тут на форуме - ой у меня все тормозит... Мой сервис будет работать на одноядерной машине с гигом оперативы быстрее на порядок, чем тот же вордпресс на 10-ти ядрах на 8 гигах оперативы при одинаковом количестве пользователей только за счет оптимизации работы с базой и с памятью. Твое мнение неинтересно абсолютно, предпочитаю общение с теми, у кого есть нормальный опыт.
md5? При сливе базы пароли легко восстановить через базу соответствия хэшей популярных паролей.Пароли надо хранить в зашифрованном виде md5(pass + salt) где salt - уникальная для каждого пользователя строка, хранящаяся в базе. Таким образом, даже если пароль у пользователя 123, то хэширование пароля с уникальной солью даёт 100% невозможность узнать пароль при сливе базы.
Никто не использует md5 для хэширования паролей давно) Что-то ты подзастрял в прошлом) Давно уже в ходу SHA1/2/3 Про соль думаю, не знают только вбемастера местные, которые в пример ставят вордпресс на любой вопрос. Вопрос был не про хранение пароля в базе, а как обеспечить безопасную работу с данными на фронте, иначе говоря - авторизацию.
