Hmm. I did try that, but it kept failing. I guess that was because I specified a realm and it tried to actually authenticate it. That will work much better for my tests.
Quintin Beukes On Fri, Sep 25, 2009 at 7:08 AM, David Blevins <[email protected]> wrote: > > On Sep 21, 2009, at 4:57 AM, Quintin Beukes wrote: > >> Hey, >> >> On the OpenEJB site there is an example for testing EJB security by >> creating a dedicated EJB with a RunAs annotation, to have that EJB >> execute as the specified role, and thus emulate what it would be like >> when that user executes. This is fine for just quickly testing if your >> roles work. >> >> But what if your EJB security is strict on some methods, and the only >> way to execute it is as a given role. Or more you want to test the >> functionality of a method as different users. >> >> And to add to this, what if you're using JTA? >> >> Then once you enter the unit test EJB, you will be starting a CMT, and >> your unit test won't run things exactly as it would, had you executed >> the same calls from a remote client for instance. The reason for this >> is because the RunAs EJB wraps the transactions of the EJBs you are >> calling, and the result can be undefined, and definitely not accurate >> to real world situations. You're most likely to notice this when you >> start using multiple persistence units and EJB jars, like I just did a >> few moments ago. > > Check out the 'testing-security-2' example. Here's the meat of that: > > http://svn.apache.org/repos/asf/openejb/tags/openejb-3.1.1/examples/testing-security-2/src/test/java/org/superbiz/injection/secure/MovieTest.java > > That would be identical to how a user would login from a remote client. > Also has no transactions. > > >> A possible solution would be to add >> "@TransactionAttribute(TransactionAttributeType.NEVER)" as another >> annotation to your test EJB, so it ends up something like this: >> @Stateless >> @RunAs("VDS Admin") >> @TransactionAttribute(TransactionAttributeType.NEVER) >> public class VdsAdminBean implements >> { >> } > > That or NOT_SUPPORTED or SUPPORTS would work as well for ensuring the > security bean doesn't start a transaction. But, right, if you're really > wanting to test things as a specific user (rather than role) the approach in > 'testing-security-2' is really the way to go. > > -David > >
