The principal is not propagated to ejb session context
by Dieter Tengelmann
Major security bug or configuration problem?
The principal is not propagated to ejb session context. Is this a known bug?
Or is anything wrong with my configuration? I've tested it with the nightly
build of 2010-10-08
jboss-web.xml:
--------
<security-domain
flushOnSessionInvalidation="true">myDomain</security-domain>
<valve>
<class-name>org.apache.catalina.authenticator.FormAuthenticator</class-name>
</valve>
---------
security-configuration in standalone.xml
----------
<security-domain name="myDomain">
<authentication>
<login-module
code="org.jboss.security.auth.spiDatabaseServerLoginModule" flag="required">
<module-option name="debug" value="true" />
<module-option name="dsJndiName"
value="java:/mydb" />
<module-option name="principalsQuery"
value="SELECT passwd etc" />
<module-option name="rolesQuery" value="SELECT
role etc." />
<module-option name="unauthenticatedIdentity"
value="nobody" />
</login-module>
</authentication>
</security-domain>
Ejb session bean
-------------
@Stateless(name="MyService")
@TransactionManagement(TransactionManagementType.CONTAINER)
@org.jboss.ejb3.annotation.SecurityDomain(value = "myDomain")
public class MyServiceBean {
@Resource SessionContext ctx;
---------------------------
jboss.xml
----------------------
<security-domain>myDomain</security-domain>
----------------------
web.xml
----------------------------
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>login.jsp</form-login-page>
<form-error-page>login-error.jsp</form-error-page>
</form-login-config>
</login-config>
----------------------------
With this configuration ctx.getCallerPrincipal() delivers "anonymous"
principal, and not the successful logged in one
If I remove security-domain from ejb session bean, I get a
javax.ejb.EJBException: java.lang.IllegalStateException: No principal
available
Is there a workaraound, where exactly is the principal propagated to ejb.
Can I use a customized class somewhere?
I've posted already in the forum, without success:
http://community.jboss.org/thread/173494
13 years, 11 months
Please help to investigate deadlock conditions in Management API
by Karel Piwko
Hi,
I'm experiencing deadlocks while working with Management API, either during
deployment or during check of the server status. It manifest itself (in Jenkins)
by creating multiple (thousands) XNIO NIO Read / Write threads until thread
limit is reached. It does not manifest every build but I got this at least 4
times so far.
Both the management operations are fired via Surefire and Arquillian. I don't
think they are related to the Arquillian Container Binding though.
I've filled AS7-2110 (and JBPAPP-7388 with further information). Note I marked
it as blocker as it effectively disallows automatized testing on AS7. Any hint
what should cause this are highly appreciated, I'll be glad to provide more
information.
Thanks,
Karel
13 years, 11 months
Annotations are being ignored, AS7 is silent
by Rostislav Svoboda
Hi guys.
I have problem with AS7 usability. I tried to deploy jar file with WS endpoint defined in EJB. I used standalone server without any additional configuration.
{code}
[standalone@localhost:9999 /] deploy /home/rsvoboda/svn/jbossws-cxf-4.0.0.Beta6/modules/testsuite/shared-tests/target/test-libs/jaxws-benchmark-datatypes-ejb3.jar
'jaxws-benchmark-datatypes-ejb3.jar' deployed successfully.
{code}
There was no error in deployment and I expected to have endpoint accessible. But it wasn't because WS subsystem is enabled only in -preview.xml profile. My deployment was processed only by EJB subsystem.
I would expect something like:
{code}
'jaxws-benchmark-datatypes-ejb3.jar' deployed successfully.
WARN: WS subsystem is not enabled.
{code}
This is general issue, basically unresolved dependencies due to annotations only are not detected.
AS7 should help users to discover possible problems quickly and not be silent.
For me this is usability issue. I would like to know your opinion and possible solutions too :).
Thanks,
Rosta
13 years, 11 months
Default values for Expressions
by Heiko Braun
IMO the default value should be mandatory.
Simply to avoid configurations that are not usable.
Thoughts?
"Your ambiguity is killing me"
Ike
13 years, 11 months
JMS RA access in JBoss AS7
by Marius Bogoevici
Hi all,
Does AS7 provide a way to accessing the messaging ResourceAdapter ?
In JBoss AS 5/6 it was possible to get access to it through the JMX bean
'jboss.jca:name='jms-ra.rar',service=RARDeployment' but I cannot see any
equivalent in AS7 (either JMX, JNDI or other).
Thanks,
Marius
13 years, 12 months
Re: [jboss-as7-dev] [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)
by Brian Stansberry
This was in response to a question about a patch that changed expression
support for an attribute. Replying to the full jboss-as7-dev list as an
FYI to others:
On 10/11/11 10:56 AM, Jaikiran wrote:
> No specific reason against it. I wasn't sure what the convention was. Are we allowing expressions for most of the attribute values and only disallowing wherever it makes sense?
>
This has evolved a bit, so yours is a good question. The console guys
are actively pursuing supporting expressions, so that has removed a
barrier we had to being aggressive about allowing them. The fairly
recent AttributeDefinition stuff that the ejb3 subsystem and some others
is using also greatly reduces the chances of screwing them up, so we can
be more aggressive.
At this point we should support them anywhere it doesn't give you a
queasy feeling. ;) If you can think of an argument not to support them
someplace; fine don't. If you just have a sixth sense it's a bad idea;
fine, don't support an expression. We can always add support in a later
release, but we can't remove it. But otherwise, go ahead and support
it. Expressions will be very important in cloud use cases where
customizing the config file on a per-server basis is a poor option.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 12 months
Re: [jboss-as7-dev] port conflict with AS7 runs
by Thomas Diesler
Can I some how queue the jobs that I know will conflict when run on the
same machine. We have 'localhost' and port numbers hard coded all over
the shop in the testsuite. So I guess the safest would be to run AS jobs
sequentially on the same machine.
-thomas
On 10/12/2011 12:19 PM, Vojtech Juranek wrote:
> Hi Thomas,
> most of the slaves have set up enviroment variables $MYTESTIP_{1,2} (in case
> of dev09, where your last build run, it's 10.16.93.41 and 10.16.93.42, also
> available under $MYTESTIPS) so you can bind each instance to different IP (at
> least AFAIK EAP QA guys use it to avoid such conflits). Another solution is to
> shift all ports of the instance (but I don't remember the option for it from
> top of my head and I'm also not sure if this feature is present in AS7).
>
> Or you meant, that you run your build, but there was another (different) build
> running on the same machines, which caused the conflict?
>
> Cheers
> Vojta
>
>> Hi Vojtech,
>>
>> I have several test runs fail
>> <https://hudson.qa.jboss.com/hudson/view/JBossOSGi/job/jboss-as7-as1601/16/
>> console> because they simultaneously run the AS7 testsuite on the same
>> machine. What is the best way to avoid these conflicts? I assume that
>> 'localhost' is hardcoded into the testsuite.
>>
>> cheers
>> -thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
13 years, 12 months
