ok you win :)
It seems you have put a lot more work into this than I did and I do
think your solution is a lot better, sadly I have to object for some
little parts.
I have trim this down to only those parts, everything else I agree 100%
> (Jorge's proposals fall into first approach mentioned above, so from my point
> of view they are just an alternate way to do the same thing and get the same
> side effects).
>
For the record I simply "made it work" this way I know it isn't the best one :)
> I can tell you that testing authentication with official repoze.who plugins is
> a waste of time, because they are all pretty well tested. At most you may want
> to make sure that they are integrated correctly, with the ~3 tests I mentioned
> above.
>
that's good to know I didn't knew that.
> ***** So, while testing protected areas, what you really must test is
> identification and authorization. Authentication must be absolutely bypassed
> -- Tested separately if you really have to. *****
>
> SHOW ME SOME CODE!
>
> If I've not already bored you with so much text, at this point you must be
> eager to see some code. So here I go...
>
haha totally
> The "reasonable"/"official" way to test protected areas, using "/admin/" as an
> example, which should had been available since day 1 is:
>
> <=====
> class TestAdmin(TestController):
> def test_index(self):
> resp = self.app.get('/admin/', extra_environ={'userid': 'manager'},
> status=200)
> assert "some text" in resp.body
>
> def test_foo(self):
> resp = self.app.get('/admin/foo', extra_environ={'userid': 'manager'},
> status=200)
> assert "some text" in resp.body
>
> def test_authorization_denied_anonymous(self):
> """If the user is anonymous, the status must be 401"""
> self.app.get('/admin/', status=401)
> self.app.get('/admin/foo', status=401)
> self.app.get('/admin/bar', status=401)
>
> def test_authorization_denied_authenticated(self):
> """If the user is authenticated, but still authorization is denied,
> the status must be 403"""
> self.app.get('/admin/', extra_environ={'userid': 'editor'},
> status=403)
> self.app.get('/admin/foo', extra_environ={'userid': 'editor'},
> status=403)
> self.app.get('/admin/bar', extra_environ={'userid': 'editor'},
> status=403)
> =====>
>
totally I'll love to use that.
> Then, you can use a test case like the one below to test authentication
> itself, as it will behave in the real-world:
>
> <=====
> class TestAuthentication(unittest.TestCase):
just wondering why make it a TestCase instead of a TestClass for nose
to sniff? a while back we decided to standardize on nose and even
though some TG code still uses TestCase ideally all new stuff should
use nose.
> Finally, this is how I'll implement this:
> 1.- I have a repoze.who plugin which acts as identifier and challenger to
> make the tests above possible.
> 2.- I'll make repoze.what-quickstart use it, replacing the default form
> plugin, when we're asked to skip authentication.
> Now, I can integrate this functionality nicely in TG2 if you accept it. The
> implementation would be simple and backwards compatible:
> 1.- We'd have to add one line to test.ini (under [DEFAULT]), in the
> quickstart template:
> skip_authentication = True
I believe mark said there is an environment variable for this
paste.testing I think, why can't we use that?
> 2.- Next, pass the value of this variable, if defined, to repoze.what-
> quickstart. Specifically, I'd have to pass its value as an argument to
> tg.configuration:AppConfig.add_auth_middleware(), which will pass it to
> repoze.what.plugins.quickstart:setup_sql_auth().
>
yea so instead of passing pick it up from the env.
> I hope I've made the problem clear. I'm absolutely convinced that this is the
> way to go and I want to correct it in TG2 apps.
>
I also agree with Florent both classes (one for authentication, and
one for /secure) should be added to the quickstart. I say /secure
because it will be great for the tests to mimic the examples in words
that the templates have. Bonus points if we get one for /admin :)
Also keep in mind a fix (mainly unnoticed) I did to the unitesting of
tg.devtools now should warn you if you broke something as it has a
nice test that will quickstart a project with auth and then run it's
unitests, therefore in theory you can modify this a lot and it will
make sure you don't break things. So we can finally be more confident
about changing quickstart without breaking stuff.
The only drawback it has now is that you still need to manually
quickstart with auth=no or geo=yes as I couldn't find a way to test
different flags.
> Cheers!
>
>
> On Monday February 23, 2009 07:34:49 Jorge Vargas wrote:
>> As agreed with gustavo we'll continue this on the mailing list.
>>
>> To the ones just joining we are discussing how to write webtests for
>> auth enable pages.
>>
>> My suggestion is to add something like the following to the end of
>> http://trac.turbogears.org/browser/projects/tg.devtools/trunk/devtools/temp
>>lates/turbogears/%2Bpackage%2B/tests/__init__.py_tmpl
>>
>> class AuthTestController(TestController):
>> def login(self,username,password):
>> <some code>
>> def logout(self):
>> <some code>
>>
>> --------------------------------------
>> So you will write tests like
>>
>> class TestAdminPermissions(AuthTestController):
>> def setup():
>> self.login('manager',managepass')
>> def test_go_admin(self):
>> self.app.get('/admin')
>> <success manager can see /admin>
>> .....
>>
>> class TestUserPermission(AuthTestController):
>> def test_go_admin(self):
>> self.app.get('/admin')
>> <fail anon can't see /admin>
>>
>>
>> This means one test class = one set of rules satisfied by one
>> predicate (or set of predicates) the drawback is that you will have to
>> set users for each type/group of predicate instead of testing directly
>> for the predicate.
>>
>> A second option is to simply provide login and logout as two module
>> level functions this will allow even more rich testing sets as you can
>> call them from any of the nose fixtures. (package, module, class or
>> even function)
>>
>> Another variable of this was 'contributed' by ChrisP and is posted
>> here http://paste.turbogears.org/paste/34752 the problem with this one
>> is that it
>> a- by passes authentication
>> b- uses "private" r.what api
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
