You are correct, we are setting the security context when a message is sent to use the credentials provided on the JMS connection.
I have written a patch and attached it to the JIRA you can apply this to trunk and build a fix to see if it works how you expect. I tried building your code but there were no build scripts or instructions.
You will have to configure hornetq-jboss-beans.xml as follows:
set allowClientLogin to true. This will tell the HornetQ security manager to allow client login and use those credentials instead.
set authoriseOnClientLogin to true. Since Client Login module only allows the setting of the security context via your callback handler this will tell HornetQ to authroise using the client login credentials. If this is true you will have to add the user and roles to hornetq-useres.properties and hornetq-roles.properties to allow authorisation. Leaving this as false basically bypasses HormetQ security.
One other point, When sending messages via HornetQ they can be sent non blocking or blocking. The default is non blocking for non persistent messages and blocking for persistent messages. If non blocking is used it may be possible that your code logs out of the client module before the message has actually arrived at the server, in this case a security exception may occur. You can configure blockonsend via the connection factory, see the user manual for more details.
Let me know how the patch works.
It's taking some time to get the TRUNK set up to apply the patch, but once that's tested I'll get back to you.
The only build "script" is an IntelliJ project file, which problably isn't much use without IntelliJ.
I have attached a generated ant build script; it's rather ugly, but it should build the various pieces provided that you set the properties appropriately - in particular, "idea.home" should be the parent of a "lib" directory containing javaee.jar and junit.jar.
The test case class is com.actual_systems.test.client.Main, which is a JUnit testcase (use with the JUnit TestRunner class, or run directly in most IDEs). The naming provider URL points to "pinpro", which happened to be the machine name running JBoss onto which the EAR file is deployed.
ServletSessionCallError.zip 6.7 KB