[Yanel-dev] Problem with yanel user resource and the security api

[Josias Thöny]

Paloma Gomez wrote:
> Hi all,
> 
> Before adding more functionalities to the yanel user resource (e.g 
> managing the groups a user belongs to) I decided to write some tests for 
> the current implementation.
> 
> I have tested the password change functionality and it works. However, 
> some of my tests don't agree and I can't understand why, because they 
> seem to prove contradictory statements.
> 
> #TEST 1: testSuccessfulPasswordUpdate1()
> 
> This test tries to change alice's password from "alicia" to "foo" using 
> the form. To verify the updating took place it tests if the "Password 
> updated successfully" message is received after clicking on the submit 
> button. I wanted to check the file directly, so that I don't have to 
> rely on the UI messages, so I used the new security api  to test it. 
> (This test is the source of all my confusion... :-()

Hi Paloma,

I guess the problem has to do with the HtmlUnit tests being run outside 
of yanel. I mean, the HtmlUnit tests simulate a browser, and therefore 
don't have access to the yanel internals. They might even run in a 
separate JVM than yanel.
So if you create a yanel instance inside your HtmlUnit test, it's not 
the same instance as the one running on the server. You will therefore 
get a different instance of the IdentityManager, UserManager, and the 
Users etc. as well.
The User class does not reload its configuration when the file has been 
changed, and that's probably why your test fails.
It seems to me that in a HtmlUnit test, you should access yanel only via 
the web, and not by calling any methods of yanel.
I know sometimes it's difficult to verify the result of a test, but with 
the password you could just try to change the password twice because it 
checks the old password, right?

hth,
josias



> 
> code:
> -------------------------------------------------------------------------------- 
> 
> [...]
> click(button1);         assertPageContainsText("Password updated 
> successfully");
>                   User user = 
> realm.getIdentityManager().getUserManager().getUser("alice");
> [...]    
> assertTrue(user.authenticate("alicia"));
> --------------------------------------------------------------------------------- 
> 
> 
> This test succeeds, but it shouldn't since the password should have been 
> updated. If one goes to the alice ui after running the test can verify 
> the password is actually "foo" as it should be. If one checks the 
> alice.xml file before and after running the test, one can verify thet is 
> has been actually updated:
> 
> #Alice
> Before: <password>e94ef563867e9c9df3fcc999bdb045f5</password> => alicia
> After:   <password>acbd18db4cc2f85cedef654fccc4a4d8</password> => foo
> 
> 
> This made me think there must be a bug either in the authenticate method 
> or the ui so I wrote three extra tests:
> 
> 
> #TEST 2: testMyTest()
> 
> This test tries to change lenya's password using the new security api.
> 
> code:
> ------------------------------------------------------------------------------- 
> 
> assertTrue(user.authenticate("levi"));
>      user.setPassword("foo");
> assertTrue(user.authenticate("foo"));
>      user.setPassword("levi");
> assertTrue(user.authenticate("levi"));
> -------------------------------------------------------------------------------- 
> 
> 
> I think it should fail if there is a bug in the authenticate method, 
> however it succeeds.
> 
> #TEST 3: testSuccessfulPasswordUpdate2()
> 
> This test tries to change the password twice using the ui. My idea was 
> that if there is a bug in the ui change password functionality, two 
> consecutive attempts of changing the password should fail: eg: If I 
> change the password from "paloma" to "foo" and then from "foo" to 
> "paloma" the second change should fail if the password was not actually 
> updated in the first attempt. However it succeeds.
> 
> 
> #TEST 4: testMyTest2()
> 
> This test checks if the authentication method always returns true. It 
> occurred to me that the first test might succeed because of this. Well, 
> this test fails as it should.
> 
> 
> 
> I can't understand why the first test succeeds if the password has been 
> actually updated. And it has been updated, since I have checked all user 
> files before and after running the tests:
> 
> #Alice
> Before: <password>e94ef563867e9c9df3fcc999bdb045f5</password> => alicia
> After:   <password>acbd18db4cc2f85cedef654fccc4a4d8</password> => foo
> 
> #Lenya
> Before: <password>8e07dafd13495561db9063ebe4db4b27</password> => levi
> After:   <password>8e07dafd13495561db9063ebe4db4b27</password>
> 
> #Joe
> Before: <password>8ff32489f92f33416694be8fdc2d4c22</password> => joe
> After:   <password>8ff32489f92f33416694be8fdc2d4c22</password>
> 
> #Paloma
> Before: <password>a20df7f02202e665e6a7b674bbfb1fcc</password> => paloma
> After:   <password>a20df7f02202e665e6a7b674bbfb1fcc</password>
> 
> 
> I think I'm missing something really obvious here but I can't figure out 
> what it is. Any hints would be very much appreciated.
> 
> Thanks,
> Paloma
> 
> _______________________________________________
> Yanel-development mailing list
> Yanel-development at wyona.com
> http://wyona.com/cgi-bin/mailman/listinfo/yanel-development
>