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
