Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
alright so my name is Bert Beckwith see a lot of familiar faces so I'm not going to do the whole introduction I work for spring source on the girls team and I've done most of the spring security plugins the interesting thing about those the plugins
is that i created the core plugin and I designed it in a way that it would be a small core because the CG plugin had gotten really bloated and sort of what I wanted was something was more modular so I designed a plugin that basically takes plugins an amazing
thing that happened was that I didn't document anything about that and people extended my plugin and they added other plugins like there's a Facebook plugin that I was going to write that someone wrote for me and so I was like oh that's great so
so I've written most of the plugins I've written seven or eight of the security plugins and there's three or four or five more that other people have also done so along the same lines is the earlier talk from this morning one of the things that
I think is under documented and not understood well enough is how do you test security how do you know that your application is secure enough that what you think you're guarding is actually guarded so I when I do a new release of one or more of the plugins
I have a script that I have it's just a it's mostly a bash script in some groovy and some it's a kind of a mishmash and what it does is it programmatically creates applications and then it installs the unreleased plug in into the application and
then i can run functional tests so it's all scripted and it takes a very long time to run but you know I you just let it run and then i create for one for every major for every minor version of Grails that i support i created on versions like when I I
no longer support 13 but when I did I would create a 137 app and a 20 for app and a 211 app you know 220 and and so I create one of each and then and then I have to run five sets of tests for each application so you know it takes forever so I was thinking
that it would be interesting to to sort of pull a lot of that out into some stuff that you guys could take and use and I don't want to imply at all that I think that these are best practices or the only way to do this and in fact I will ask you more questions
than I expect you're going to ask me because I want to know what are you already doing so we'll talk about that a little bit later because to be honest I was talking with this earlier I don't write applications anymore right i mean i write plugins
and I don't get to live in the real world so I'm a little out of touch with you know reality and what it takes to actually have an application production and be nervous that you're going to get hacked and things like that so but you guys are right
out there so I want to learn as much from you hopefully as you're going to learn from the talk so so there are three types of tests in grails right there unit tests integration tests those you get for free without doing anything and if you install a functional
test plug in then you get functional tests as the third type of tests I do not I cannot really think of a any sensible unit tests for security now I was going to just stop there but then I was thinking well you could probably do it because when you create
a controller test either a unit test or a integration test you have a mock response in a mock request right those are Grails classes but they're actually just small wrappers around the spring classes that are they have them at the interface and they have
fake data and the request will give you a mock session that has a backing map the response actually you can write to an output stream and it will write to a byte array so it behaves very much like a real request in response in session and the problem is that
spring security is implemented as a filter chain right so there's one filter in web.xml and that really nests several filters in filter chain and then you can configure those as spring beans so if there's no web server there's no filter chain running
there's nothing that's going to advance the chain right but there's a mock feel there's a mock filter chain or right there's a filter jane class that represents this so i'll sing well you could do that i guess but i still don't
think that it would make sense because you would have to parse the web.xml you'd have to put all the Grails filters in there you'd have to put every filter that it really is in your web.xml it would be brittle it wouldn't I don't think it would
maintain well so it would be theoretically possible to do some of this a lot of this maybe with unit tests if any of you were doing that now or come up with all ways to do it I would love to hear about that but I think for the most part most of the tests really
have to be functional tests but can we do this with integration tests right because we want we want everything to be a unit test unit tests are fast I can run them from my if tests are slow they're not going to get run and I have worked in organizations
where the tests took forever to run their real pain and we just didn't run them and we let our CI server run our test for us and then we would get email saying we broke the build and and then that happens too often that we stopped carrying that the build
is broken and that is so bad because well you know I don't have to tell you that that's terrible so can we do this with integration tests no because spring security is implemented as a filter Jane and there's no web server so yes you do get a mock
request and a mock response and there is available to a class that represents the filter chain but there's still nothing that would advance that chain nothing that would start at the first one call your first filter when you call the do filter method after
your after you've done your work there's nothing that would advance it to know which one's next and advanced to that so there are uses for integration tests will see some primarily I think for testing services so if you have annotated services
especially with acls both shiro or spring security i think you could do a tremendous amount of testing there as integration tests so there's areas are still slower than unit tests but they're not quite as slow as functional tests so I think you know
it's maybe a happy middle ground so you want to think of integration tests really i think we misuse the word integration when i think of an integration test i think of integrating things right testing this plugs together with this and they work together
correctly but that's not really how Grails defines an integration test really the integration test is just unit tests with a running DB it by default in in-memory database but you can switch that out to a test server and you've got spring wired up
you've got hibernate if that's installed or you've got Redis or whatever you're using and you've got plugins you basically have everything but a container so you can spring security will have configured itself all the plugins will be there
so you can test the configuration you can check your your URL guarding rules so if you've annotated your controller or if you use request maps or whatever you have a mapping of this URL pattern is guarded by this these roles or these permissions or whatever
so you could test that that you know the that's appropriately configured but I don't and of course like I said you can do the ACL testing and we'll see some examples of that so we have to do functional tests and I think the answer is yes and deal
[ ... ]
Nota: se han omitido las otras 3.802 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.