Announcement Announcement Module
No announcement yet.
Credential expiration Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Credential expiration

    Is there any reason the loadUserByUsername() method for JdbcDaoImpl has the additional properties of UserDetails hardcoded? Here's the last line of the method:

    return new User(returnUsername, user.getPassword(), user.isEnabled(), true, true, true, arrayAuths);

    I've extended JdbcDaoImpl and overriden initMappingSqlQueries() so that the the UserDetails supports isAccountNonExpired(), isAccountNonLocked() & isCredentialsNonExpired(). But with the line above erases all my hard work .

    Is the guidance to extend loadUserByUsername() ?


  • #2
    Hmmmm, that is indeed a pain. It would be much nicer if the default query simply returned true for those parameters. You could then choose to return them if you want to. I think it would make sense to raise a JIRA issue for this. It is pain! Short term, as you are exending JdbcDaoImpl anyway simply create your own UsersByUsernameMapping. In the mapRow method, set the required values.

        protected void initMappingSqlQueries() {
            this.usersByUsernameMapping = new ExtendedUsersByUsernameMapping(getDataSource());
            this.authoritiesByUsernameMapping = new AuthoritiesByUsernameMapping(getDataSource());
         * Query object to look up a user.
        protected class ExtendedUsersByUsernameMapping extends MappingSqlQuery {
            protected UsersByUsernameMapping(DataSource ds) {
                super(ds, usersByUsernameQuery);
                declareParameter(new SqlParameter(Types.VARCHAR));
            protected Object mapRow(ResultSet rs, int rownum)
                throws SQLException {
                String username = rs.getString(1);
                String password = rs.getString(2);
                boolean enabled = rs.getBoolean(3);
                boolean accountNonExpired= rs.getBoolean(4);
                boolean credentialsNonExpired= rs.getBoolean(5);
                boolean accountNonLocked= rs.getBoolean(6);
                UserDetails user = new User(username, password, enabled, accountNonExpired, credentialsNonExpired, accountNonLocked,
                        new GrantedAuthority[] {new GrantedAuthorityImpl("HOLDER")});
                return user;


    • #3

      I am already doing exactly what you proposed. The issue is loadUserByUsername() takes the User I created from my MappingSqlQuery and creates a new User but doesn't use my values for accountNonExpired, credentialsNonExpired & accountNonLocked:

      return new User(returnUsername, user.getPassword(), user.isEnabled(), true, true, true, arrayAuths);

      I'll just override loadUserByUsername() for the time being unless there are any better ideas.



      • #4
        First of all, are you going to JIRA this? The code below does exactly what you want, you don't have have to override loadUserByUsername(). By overriding the code as I showed you are providing your own mapping and creation of the User. The code example I showed did use the accountNonExpired, credentialsNonExpired and accountNonLocked flags in the creation of the user. Isn't this exactly what you want?


        • #5
          Yes I will open an JIRA issue. I just wanted to make sure I wasn't missing something and opening a bogus issue.

          My code looks exactly like what you provided and yes it creates UserDetails exactly as I want them. But take a look at, as this is what I am looking at:

          In loadUserByUsername() it will use my UserMapping to create the users but the last line of the method then creates a new User and only migrates the password and the enabled field to the user that it returns. The rest are hardcoded to true.

          I only started asking because I thought I saw a post that mentioned that some of these attributes were not fully supported to provide backwards compatibility.



          • #6
            Apologies, yes you'll need to override this as well. As you say, the values from the query would simply be ignored. Might want to add that to the JIRA issue as well.