Зачем хранить все выданные токены, если внутри них есть дата окончания и они подписаны. Вот именно, что можно хранить только НЕИСТЕКШИЕ и ОТОЗВАННЫЕ токены. Как только у отозванного токена истекает время его можно безболезненно удалить из хранилища.
С другой стороны обычно из-за безопасности хранят все токены. Это нужно для того, чтобы при запросе пользователя о разлогинивании отовсюду, все активные токены сразу отозвать. (Или логика от обратного — если токена нет в базе активных, значит он отозван).
Во втором, чистом варианте, делается предположение, что можно взять адрес переданной структуры. В первом варианте никаких дополнительных предположений о переданных параметрах не делается, он более безопасный и правильный.
Нормальные формы применяются только к описанию таблиц (атрибуты)а не к их наполнению (количество строк). Тут, конечно, скользкий вопрос. Но, все таки, я не называл бы отдельную таблицу со снапшотом состояния как денормализацию.
Вообще денормализация это понижение уровня нормальной формы на котором находится база данных. Другими словами объединение нескольких стобцов разных таблиц в одну общую, дублируя информацию. В вашем примере никокого объединения стобцов или дублирования информации нет. Это не денормализация а снапшот. То есть, если пользоваться правильно определениями, такой вопрос не возник бы вообще. Правильный вопрос — делать ли снпшоты.
Подведем итог: если ты спамер — ты эффективный сотрудник. Спасибо Микрософт, как оказалось оценка сотрудника — это просто!
ЗЫ Менеджеры замеряли эффективность программиста размером написанного исходного кода, судя по-всему это прилетела обратка. :)
Все эти странности идут из стандарта IEE 754. Собрались люди и сделали стандарт так, что какую бы чушь ты не считал, чтобы получил адекватный результат. (Чушь — адекватный результат, хм, ладно....)
Глядя на это все иногда возникает чувство, что тут немного перемудрили…
Работа сделана большая.
Но, мне кажется в конце концов все равно вас не спасут разные типы ссылок, и вам прийдется создават сборщик мусора.
Вопрос — глядя на все эти проблемы, и кучу доп софта для решения этих проблем, потратив столько же ресурсов и времени смогли бы написать сборщик мусора?
ЗЫ: У меня был проект на дельфи orm. Мне очень понятно с чем вы столкнулись. После первых проблем сразу написали сборщик мусора и в дальнейшем это показало что это было самое правильное решение.
С учетом того, что сейчас программист пишет обычно на нескольких языках(c, java, sql, javascipt), полагаться на порядок операторов, это бомба. Я, например, пишу всегда скобки, и не засоряю мозг какой порядок операторов в конкретном языке.
Если вам нужен бин в зависимости от проперти то лучше использовать @ConditionalOnProperty аннотацию.
Пример выше можно сделать, добавляя аннотацию @ConditionalOnProperty над каждым классом, который может там использоваться и значение проперти в аннотации это само название этого класса.
А зачем отдельная таблица? Если вы создаете xml то его можно напрямую использовать в native query.
И еслу уж вобще придираться, возможен вариант с native query и массивом как параметр, тогда вообще xml не нужен.
Мне сага, например, тоже не нравится. Если в первом случае есть только общая точка отказа — менеджер транзакций а бизнес логика может быть распределена между микросервисами. То в случае саги наша бизнес логика перетекает полностью в хореографера — монолит от которого пытались уйти. Да еще и он является и общей точкой отказа.
Как получить юзера
Плюс если вы используете спрингтдата, то в sql полностью доступен spel через который можно получить пользователя. Другими словами, вам не нужен напрямую пользователь в контролере, а информация о нем будет автоматически используя spel добавлена в sql запрос. Например Query(«select * from users where id=?#{principal.id}»)
Ну вы же не просто так целый объект User в виде параметра передаете. Скорее всего дальше вы из него что-то вытягиваете, например список групп, и смотрите, есть ли определенная группа или нет. Вот это и есть лишний код.
ЗЫ Если нужно было контролировать, что пользователь зарегистрирован, то опять это можно было сделать в виде АОР и какой-то аннотации, например @AuthenticationNeeded, что более читаемо.
ЗЫЗЫ В спринг секюрити это выглядело-бы так @PreAuthorize(«isAuthenticated()»). F А если нужно роль проверить @PreAuthorize(«hasRole('ROLE_ADMIN')»). А если нужно значение параметра проверить @PreAuthorize("#param=123"). А если все сложно, вызвать бин @PreAuthorize("@bean.check(#param)")
Если не нравится статический метод, ест прямая ижекция из коробки как параметр метода контроллера.
PS Лучше почитать про спринг секюрити. Для вашей задачи нужно было написать 15 строк кода и вы бы получили крутой и безопасный функционал у вас в программме а не велосипед с врзможно дырой в безопасности.
PPS Ваша реализация получения пользователя для контроля доступа неправильна даже аритектурно — так как контроль доступа и бизнес логика должны быт разделены, что и предоставляет спринг секюрити.
С другой стороны обычно из-за безопасности хранят все токены. Это нужно для того, чтобы при запросе пользователя о разлогинивании отовсюду, все активные токены сразу отозвать. (Или логика от обратного — если токена нет в базе активных, значит он отозван).
ЗЫ Менеджеры замеряли эффективность программиста размером написанного исходного кода, судя по-всему это прилетела обратка. :)
Глядя на это все иногда возникает чувство, что тут немного перемудрили…
Но, мне кажется в конце концов все равно вас не спасут разные типы ссылок, и вам прийдется создават сборщик мусора.
Вопрос — глядя на все эти проблемы, и кучу доп софта для решения этих проблем, потратив столько же ресурсов и времени смогли бы написать сборщик мусора?
ЗЫ: У меня был проект на дельфи orm. Мне очень понятно с чем вы столкнулись. После первых проблем сразу написали сборщик мусора и в дальнейшем это показало что это было самое правильное решение.
Пример выше можно сделать, добавляя аннотацию @ConditionalOnProperty над каждым классом, который может там использоваться и значение проперти в аннотации это само название этого класса.
И еслу уж вобще придираться, возможен вариант с native query и массивом как параметр, тогда вообще xml не нужен.
Плюс если вы используете спрингтдата, то в sql полностью доступен spel через который можно получить пользователя. Другими словами, вам не нужен напрямую пользователь в контролере, а информация о нем будет автоматически используя spel добавлена в sql запрос. Например
Query(«select * from users where id=?#{principal.id}»)
Надпись на телефоне: «Группа обеззараживания прибудет через 30 минут. Ожидайте»
ЗЫ Если нужно было контролировать, что пользователь зарегистрирован, то опять это можно было сделать в виде АОР и какой-то аннотации, например @AuthenticationNeeded, что более читаемо.
ЗЫЗЫ В спринг секюрити это выглядело-бы так @PreAuthorize(«isAuthenticated()»). F А если нужно роль проверить @PreAuthorize(«hasRole('ROLE_ADMIN')»). А если нужно значение параметра проверить @PreAuthorize("#param=123"). А если все сложно, вызвать бин @PreAuthorize("@bean.check(#param)")
PS Лучше почитать про спринг секюрити. Для вашей задачи нужно было написать 15 строк кода и вы бы получили крутой и безопасный функционал у вас в программме а не велосипед с врзможно дырой в безопасности.
PPS Ваша реализация получения пользователя для контроля доступа неправильна даже аритектурно — так как контроль доступа и бизнес логика должны быт разделены, что и предоставляет спринг секюрити.