Так что я просто перехожу с InMemoryTokenStore
на JdbcTokenStore
. Как обычно, за одним, казалось бы, простым изменением следует несколько побочных эффектов, включая проглоченные исключения - извините за разглагольствование.
Вот как я использовал для доступа к основной записи пользователей:
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
String username = (String) authentication.getPrincipal();
Первый
По какой-то причине getPrincipal()
всегда возвращает только имя пользователя вместо UserDetails
объекта. Это было достаточно хорошо для меня, поэтому я пошел с этим.
Теперь, когда я изменил хранилище токенов, getPrincipal()
действительно действительно возвращает объект UserDetails
. Я могу с этим смириться, но я хотел бы знать, почему это внезапно изменилось - из-за этого мне пришлось рефакторировать некоторый код, поскольку я всегда ожидал, что имя пользователя будет getPrincipal()
до сих пор. Я также хотел бы знать, могу ли я это изменить.
Второй
Из того, что я вижу, JdbcTokenStore
, похоже, сериализует объекты Java. Он пытается сериализовать объект Token
и объект UserDetails
. Столбцы token
и authentication
, кажется, представляют эти сериализованные объекты, и я хотел бы понять, почему это действительно необходимо. В конце концов, это информация, которую можно восстановить во время запуска / выполнения из базы данных. За исключением Token
, конечно, но я не понимаю, почему они не просто хранят токен (String
), но вместо этого объект.
Больше всего: Малейшее изменение любого из этих классов, и они не будут десериализуемы! Каждый пользователь будет вынужден получить новый логин, если один из этих классов будет изменен, что не может быть причиной, по которой я хочу использовать JdbcTokenStore
, во-первых, поэтому должно быть что-то подозрительное, или я его не получаю.
Может быть, кто-то мог бы пролить больше света на это.