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