Uploaded another one. So far this one seems to be doing the trick. All our tests on the current project have been changed to using this, and it's DEFINITELY, without doubt helping.
I feel it can use a lot more work, and ideas would be great. Just let me know what you're thinking, and any design ideas and I'll have at it. Quintin Beukes On Wed, Sep 30, 2009 at 2:53 PM, Quintin Beukes <[email protected]> wrote: > I must say that writing my tests go much quicker now, and that > compared to before the runner they are MUCH shorter. I had a lot of > extra code for all the different security role tests. Those > @TestSecurity and @RunTestAs annotations help a lot. > > Quintin Beukes > > > > On Wed, Sep 30, 2009 at 11:10 AM, Quintin Beukes <[email protected]> > wrote: >> The bug is solved. Haven't uploaded it again. Will do so this afternoon. >> >> Added a constant: TestSecurity.UNAUTHENTICATED. It basically equals >> "". You can use that as follows: >> >> @Test >> @TestSecurity( >> authorized={"Admin", "Payroll"}, >> unauthorized={"Employee", TestSecurity.UNAUTHENTICATED} >> ) >> public void testAddEmployee() >> { >> ... >> } >> >> Quintin Beukes >> >> >> >> On Tue, Sep 29, 2009 at 5:12 PM, Quintin Beukes <[email protected]> >> wrote: >>> OK. Uploaded the mentioned one. Also added a @RunTestAs annotation, >>> which is used similar to @RunAs. >>> >>> There is one bug with the TestSecurity, when "unauthorized" property >>> contains only a "", ie. "guest" user. Will fix it tonight. >>> >>> Quintin Beukes >>> >>> >>> >>> On Tue, Sep 29, 2009 at 4:00 PM, Quintin Beukes <[email protected]> >>> wrote: >>>> I added the license and changed the way security roles are specified. >>>> >>>> I remove the securityRole option from the ContextConfig annotation, >>>> and added a @TestSecurity annotation. I has 2 String arrays are >>>> options, nl. authorized and unauthorized. You can use it like this: >>>> �...@testsecurity( >>>> authorized={"Admin", "Payroll"}, >>>> unauthorized={"Employee", ""} >>>> ) >>>> >>>> "" is treated as unauthorized (no login). This might not be ideal, >>>> though it is not something you might test very often, and it works >>>> well when specifed as a constant. >>>> >>>> This can be both class and method level, but works best method level. >>>> >>>> It basically builds a compound JUnit statement, which executes the >>>> same test for each of those roles. The authorized executions must >>>> succeed, and the unauthorized executions must fail with an >>>> EJBAccessException (it's basically like annotating a test with >>>> "@Test(expected=EJBAccessException.class)"). >>>> >>>> It forces a certain testing style when testing your security, so a >>>> third option called "role" which takes a single string (acts the same >>>> as authorized={"role"}) can be used to just run the test as one role, >>>> or a separate annotation. This way you can build separate tests for >>>> testing unauthorized access. What I am referring to here is when you >>>> don't feel like running a whole test, preparing data and all that, >>>> just to test the failure at the end. It will work fine, but some >>>> people might feel it redundant, and it might leave extra data in the >>>> database. >>>> >>>> What I do to avoid this, with the above is split my >>>> authorized/unauthorized into 2 tests. The first is for "authorized", >>>> and I test it for all my authorized roles. The second is for >>>> "unauthorized", and all it does is execute the final line. This is >>>> what I meant with "force a certain style of testing", a style which is >>>> different from those listed in the OpenEJB security-testing examples - >>>> which is probably what people are used to doing. Though change towards >>>> something more optimal isn't always bad. The question is just which is >>>> more optimal? >>>> >>>> I will upload the new code in about an hour. just in case I made any >>>> more changes. >>>> >>>> Quintin Beukes >>>> >>>> >>>> >>>> On Tue, Sep 29, 2009 at 10:08 AM, Quintin Beukes <[email protected]> >>>> wrote: >>>>> Re. TestNG. >>>>> >>>>> TestNG has factories. haven't used it, but if I recall correctly you >>>>> can have a separate class as a factory, and then just reference that >>>>> class in your configuration. So if you have a smart factory, you could >>>>> probably initialize the InitialContext and then create the test. I'll >>>>> have a look at it and see if it's possible to achieve the same power >>>>> for TestNG (ie. method level configurations and what not). >>>>> >>>>> TestNG has some great features, like parallel testing and test >>>>> dependencies. These can speed up your tests a lot, especially when the >>>>> projects grows and a single failure causes you to wait 10 minutes just >>>>> to see you have 2000 tests that failed. JUnit can learn a lot from >>>>> them. >>>>> >>>>> Quintin Beukes >>>>> >>>>> >>>>> >>>>> On Tue, Sep 29, 2009 at 9:51 AM, Quintin Beukes <[email protected]> >>>>> wrote: >>>>>> Glad I could be of service. >>>>>> >>>>>> Will do the license file and upload it. Then I'll wait until it's in >>>>>> SVN and just send patches. Beats uploading the whole thing to JIRA >>>>>> everytime (it's small, but still feels like overkill). >>>>>> >>>>>> Then, re. the code. I know it can use a lot of API changes. Not a lot >>>>>> of time went into designing the layout. I did some quick thoughts on >>>>>> it, and this is what I came up with - though it still doesn't feel >>>>>> right. Would be great to see it evolve and learn from you guys. >>>>>> OpenEJB's design (source level) is brilliant. >>>>>> >>>>>> Quintin Beukes >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Sep 29, 2009 at 3:33 AM, David Blevins <[email protected]> >>>>>> wrote: >>>>>>> Responded on dev@ >>>>>>> >>>>>>> On Sep 27, 2009, at 12:16 PM, Quintin Beukes wrote: >>>>>>> >>>>>>>> Hey, >>>>>>>> >>>>>>>> The previous runner I started modifying extensively to customize for >>>>>>>> our company's tests. I already had a small testing framework for the >>>>>>>> tests, which used Spring to initial OpenEJB and do the lookups. I >>>>>>>> changed this to use the runner technique. >>>>>>>> >>>>>>>> Then over the weekend I decided to extract the runner code into an >>>>>>>> openejb-junit project, and make it extensible so I could use the >>>>>>>> library's code and only extend to give our tests the same >>>>>>>> functionality. >>>>>>>> >>>>>>>> This is what I came up with: >>>>>>>> https://issues.apache.org/jira/browse/OPENEJB-1078 >>>>>>>> >>>>>>>> The JUnit tests demonstrate it's behaviour. These 3 tests are the best >>>>>>>> examples: >>>>>>>> org.apache.openejb.junit.TestEjbBasic >>>>>>>> org.apache.openejb.junit.TestEjbSecurity >>>>>>>> org.apache.openejb.junit.TestDualConfigOverride >>>>>>>> >>>>>>>> It supports class level configuration of the InitialContext, and then >>>>>>>> method specific configurations. You can configure the InitialContext >>>>>>>> from a file, or by directly specifying properties. You can have >>>>>>>> OpenEJB do any of it's supported injections, or you can have the >>>>>>>> runner inject the InitialContext (or it's initialization Properties >>>>>>>> object) and do your own lookups. You can specify as which role to load >>>>>>>> the InitialContext (basically a RunAs). >>>>>>>> >>>>>>>> I'm planning on doing resource configurations, such as datasources. >>>>>>>> Any other suggestions, please throw them my way. And please send me >>>>>>>> feedback. So far it's working very well for my tests. I have yet to >>>>>>>> complete the spring modification, but for those tests which don't >>>>>>>> require it, it works very well. Especially the role tests. >>>>>>>> >>>>>>>> Not that it still doesn't support JUnit 3. If you require JUnit 3, let >>>>>>>> me know and I'll prioritize implementing JUnit 3 support. >>>>>>>> >>>>>>>> An basic example would be the following: >>>>>>>> @RunWith(OpenEjbRunner.class) >>>>>>>> @ContextConfig( >>>>>>>> properties={ >>>>>>>> >>>>>>>> @Property("java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory") >>>>>>>> } >>>>>>>> ) >>>>>>>> @LocalClient >>>>>>>> public class TestEjbSecurity >>>>>>>> { >>>>>>>> �...@ejb >>>>>>>> private MyBusinessBean myBean; >>>>>>>> >>>>>>>> �...@testresource >>>>>>>> private InitialContext currentInitialContext; >>>>>>>> >>>>>>>> �...@test >>>>>>>> �...@contextconfig( >>>>>>>> securityRole="Admin" >>>>>>>> ) >>>>>>>> public void testAsAdmin() >>>>>>>> { >>>>>>>> myBean.someMethod(); >>>>>>>> currentInitialContext.lookup("some/custom/lookup"); >>>>>>>> } >>>>>>>> >>>>>>>> �...@test >>>>>>>> �...@contextconfig( >>>>>>>> propertiesFile="/META-INF/employee-context.properties", >>>>>>>> securityRole="Employe" >>>>>>>> ) >>>>>>>> public void testAsEmployee() >>>>>>>> { >>>>>>>> myBean.someMethod(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Quintin Beukes >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
