Skip to content
Snippets Groups Projects
  1. Oct 13, 2016
    • Nicholas Blair's avatar
    • Nicholas Blair's avatar
    • Nicholas Blair's avatar
      Merge branch 'deprecate-attributesmapper' into 'master' · 08e0a2e6
      Nicholas Blair authored
      deprecate: LocalUserDetailsAttributesMapper
      
      I'm preparing a 1.7.0 release, thought I'd stick this in there as well.
      
      See merge request !26
      08e0a2e6
    • Nicholas Blair's avatar
      deprecate: LocalUserDetailsAttributesMapper · 664b7383
      Nicholas Blair authored
      Use LocalUserDetailsLoader instead.
      664b7383
    • Nicholas Blair's avatar
      Merge branch 'udsperson-constructor' into 'master' · dd3aeb01
      Nicholas Blair authored
      refactor: change injection strategy for UdsPersonUserDetailsServiceImpl
      
      `UdsPersonUserDetailsServiceImpl` is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).
          
       Registering more than 1 `UserDetailsService` - say one for the uw-spring-security stack, and a different one for `UdsPersonUserDetailsServiceImpl` - will result in ApplicationContext initialization errors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.
          
      The recommended use now for `UdsPersonUserDetailsServiceImpl` is to provide the needed `UserDetailsService` by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.
      
      See merge request !25
      dd3aeb01
    • Nicholas Blair's avatar
      chore: bump to 1.7.x · 909d54fb
      Nicholas Blair authored
      Change to UdsPersonUserDetailsServiceImpl construction necessitates.
      909d54fb
    • Nicholas Blair's avatar
      refactor: switch autowiring to constructor injection · 62f063e5
      Nicholas Blair authored
      UdsPersonUserDetailsServiceImpl is not initialized automatically by either of the primary 'local-users' or 'preauth' Profiles. It's typically constructed by downstream projects manually (not by component scanning).
      
      Registering more than 1 UserDetailsService - say one for the uw-spring-security stack, and a different one for UdsPersonUserDetailsServiceImpl - will result in ApplicationContext initializationerrors as the Configuration classes provided in uw-spring-security-config expect 1 and only 1 UserDetailsService.
      
      The recommended use now for UdsPersonUserDetailsServiceImpl is to provide the needed UserDetailsService by hand, not by automatic autowiring. If the 1 UserDetailsService provided by uw-spring-security is appropriate, it's easy to retrieve from the ApplicationContext; if an alternate one is required it can be constructed without registering it as a @Bean.
      62f063e5
  2. Sep 30, 2016
  3. Sep 13, 2016
  4. Sep 09, 2016
  5. Aug 24, 2016
  6. Aug 22, 2016
Loading