nepster-web: Мое мнение, вы слишком заморачиваетесь и ключи к jwt не нужены.
Есть базовый secret-key и его вполне хватает на все операции.
Токен формируется на основе набора данных и шифрованной соли (что бы токен был уникальный)
При запросе данные будут видны всегда. По этому желательно использовать https
Далее идет проверка на беке.
Если все ок, то вам возвращается массив с ролями и токеном.
DarthJS: Если идет разделение на фронт/бек, то angular.
Обратно возвращается токен.
Естественно в проекте не должно быть php сессий.
Все работы происходят посредством jwt authentication
Евгений: Да, для каждой сущности выбираете все что вам потребуется и отображаете.
Если нагрузка будет возрастать (1000+ запросов в минуту), то тут стоит продумать архитектуру.
Но я этим не буду заниматься, мне своего хватает.
Я кстати использую mongodb. Но и система немного друга.
На любой чих в проекте создается лог и из него ясно, кто что сделал.
Уведомления сидят в комнатах на websockets. Сервер для уведомления, мессенджера и т.д., написан на Go.
Весь остальной бекенд в проекте крутится на php 7.1 / mysql, SF3+DDD+Bus+CQRS
Фронтенд, это совершенно отдельный сайт, реализованный на js/ts (angular)? который общается с беком по api.
un1t: Работал я там в 2010-2011г. На тот момент оклад белый был 90т.р. + 13 зп. + премии.
Хороший чистый офис, еда и т.д.
Получил отличный опыт и знания.
Нашли меня они сами.
Опыт работы программистом на тот момент 10 лет.
Сейчас я конечно в офис работать не пойду, если только кто то предложит больше 250к и хорошие условия.
Два года назад искал работу, предложили в крупной азиатской компании 200к зп.
Пришел я в офис и сразу попросил показать рабочее место.
Увидев душное помещение, "школьную парту", обычный офисный стул, монитор 21 дюйм и слабое железо, ушел с собеседования.
Как раз после банка, я привык уже работать за большим собственным столом, монитором от 27, кожаное кресло и т.д. Теперь меня в обычное пространство не загнать.
Никита Братский: Для хранения ссылки, используйте varchar
для UUID_SHORT bigint.
Для чистого UUID используется BINARY(16) или CHAR(16). Но первый предпочтительнее.
Максим Черепанцев: В Яндексе есть подобная система безопасности, не такая жесткая но все же.
Просто на проектах для пользователей от нее нет смысла. (music, calendar, disk etc.)
Большинство кода Яндекса частично или полностью открыт. О нем можно подробно узнать на эвентах или семинарах.
Но вот данные с той же mongodb (disk), оч. даже защищены и к ней имеет доступ только узкий круг лиц.
Так же как и данные по money.
Больше там сильно защищать нечего.
Это вам не миллионы финансовых проводок, это не счета клиентов банка (которые я кстати видел и знаю их финансы, но договор на 10 лет обязывает молчать)
Короче есть два варианта:
1) Серьезная безопасность от утечки данных на уровне крупных учреждений.
2) Фиктивная безопасность за счет договора и честности сотрудника.
Есть базовый secret-key и его вполне хватает на все операции.
Токен формируется на основе набора данных и шифрованной соли (что бы токен был уникальный)