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 >>>>> >>>> >>>> >>> >> >
