Cineasts UserRepository and UserRepositoryImpl disconnection

[bytor99999]

So I basically copied and pasted all the code for Spring Security, User, UserDetails and UserDetailsService from the Cineasts sample project. Well, today I can across something I thought Odd.

UserRepositoryImpl only implements CineastsUserDetailsService and it implements UserDetailsService, so therefore UserRepositoryImpl doesn't have any connection to UserRepository Interface. Unless it somehow magically with ApsectJ get introduced. Although in the Cineasts projects it isn't using the aspects portion.

But in the Domain tests it is able to call UserRepository methods introduced by Spring Data.

Basically, my findByLogin(String login) isn't working, it is returning null, when I in fact have a User with that login in the database.

Although I did change the line of code in findByLogin to

return template.lookup(User.class,"login",login).to(User. class).singleOrNull();

Because if there wasn't a user with a particular login a call to single() would throw an Exception.

It is in the findByLogin method that is in the UserRepositoryImpl that I am trying to call an introduced method using this.findByProperty() or something along those lines.

What am I missing here?

Thanks

Mark

[bytor99999]

This is odd, In one scenario it found by login, but in another it didn't. Here are my users in the db

[{"nodeId":17,"login":"auser","firstName":"John","l astName":"Doe","twitterAccountName":null,"role":[]},{"nodeId":19,"login":"cuser","firstName":"Tom"," lastName":"Smith","twitterAccountName":null,"role" :[]},{"nodeId":18,"login":"buser","firstName":"Mike", "lastName":"Smith","twitterAccountName":null,"role ":[]},{"nodeId":32,"login":"bytor","firstName":"mark", "lastName":"spritzler","twitterAccountName":null," role":null},{"nodeId":33,"login":"test","firstName ":"test","lastName":"test","twitterAccountName":nu ll,"role":null}]

If I findByLogin("bytor") it succeeds in finding it, but if I findByLogin("auser") it returns null.

I even overwrote the getGrantedAuthorities so that every user returns ROLE_USER. Since if you are a User in the db, it means you added through my register page.

@Override
        public Collection<GrantedAuthority> getAuthorities() {
            //User.Roles[] roles = user.getRole();
            //if (roles ==null) {
                GrantedAuthority grantedAuthority = new SimpleGrantedAuthority("ROLE_USER");
                GrantedAuthority[] authorities = {grantedAuthority};
                return Arrays.asList(authorities);
            //}
            //return Arrays.<GrantedAuthority>asList(roles);
        }

I just feel lost, and it really isn't rocket science here. You guys made it really easy to do, I just can't seem to do easy.

Mark

[bytor99999]

OK, doing more debugging, going deep into Spring Security Code. I find it odd, but in the check on password, it doesn't match. Like the encoder used in Spring Security is a different encoder than what is used in the Cineasts code to encode. In the Cineasts it is used the MD5Encoder, but in Spring Security it is using MessageDigestPasswordEncoder which looks to return a different value

I know no one uses the password "password" so if I post the MD5 and MessageDigest encoding, without telling you my salt, then that wouldn't be a security breach.

so in MD5Encoder I get 845e711374568ed7f6af654050000eed
with MessageDigest I get 36a63b1b183cf5b90247783e937acd00

Two different values.

So I am going to change my User code to use MessageDigestPasswordEncoder instead, and that should work.

I'll let you know.

Thanks

Mark

[bytor99999]

It gets stranger by the minute. So while I see in the debugger two different results, and code with two different encoders. MD5Encoder extends MessageDigestPasswordEncoder, and further oddity, is the code in DaoAuthenticationProvider is

if (!passwordEncoder.isPasswordValid(userDetails.getP assword(), presentedPassword, salt)) {

where passwordEncoder is an instance variable of DaoAuthenticationProvider and it is assigned to

private PasswordEncoder passwordEncoder = new PlaintextPasswordEncoder();

So, while I stated that our User was using MD5Encoder and DaoAuthenticationProvider was using MessageDigestPasswordEncoder as if they were two different encoders, they are actually the same encoder at different levels of the object heirarchy. So using MD5Encoder would call up to the super class of MessageDigestPasswordEncoder encode() method.

But still doesn't answer why the values are different, unless in one scenario the salt wasn't applied, even though it is coded that way. Have to double check my code again.

Maybe I should just keep the passwords in plain text in the db. JK

Mark

[bytor99999]

I really do like talking to myself.

OK, resolved. I think because I had had setter methods for password, and didn't call encode there that was the problem.

Mark

[MichaelHunger]

Great that you resolved, it and good conversation for others to look up. Often the devil is in the details, but so you at least learned stuff about Spring Security which is a biggie on its own

Regarding the repositories:

The ~Impl is connected via class-name lookup as described in the Spring Data Commons docs (which I refer to in the repositories section).

And the findByLogin is actually a derived finder method which uses the meta-data SDN gathers about your entities to create cypher queries from those. So it knows that "login" is an indexed field of User and so can create:

start user = node:User(login={0}) return user

If the method name would contain more expressions those would be taken into account as well, including relationship-navigation.

Cheers

Michael