#217 Stateful session activation fails

v2.4 (stable)
closed-invalid
5
2002-05-03
2002-05-03
No

A stateful session bean with references to other beans
fails to activate after being passivated. A security
check exception occurs while loading the bean references.

To fix this problem I moved the security interceptor in
the Standard stateful bean configuration from the end
of the chain to before the transaction interceptors.
The following patch may not be exactly accurate since I
have other customizations in my test system.

--- default/standardjboss.xml Fri May 3 10:02:42 2002
+++ adpro/standardjboss.xml Fri May 3 14:15:41 2002
@@ -154,6 +158,7 @@

<container-invoker>org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker</container-invoker>
<container-interceptors>

<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
+
<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
<!-- CMT -->
<interceptor
transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
<interceptor transaction="Container"
metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
@@ -162,7 +167,6 @@
<interceptor
transaction="Bean">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
<interceptor
transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
<interceptor transaction="Bean"
metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
-
<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
</container-interceptors>

<instance-cache>org.jboss.ejb.plugins.StatefulSessionInstanceCache</instance-cache>

<persistence-manager>org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager</persistence-manager>
@@ -194,6 +199,7 @@

<container-invoker>org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker</container-invoker>
<container-interceptors>

<interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
+
<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
<!-- CMT -->
<interceptor
transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
<interceptor transaction="Container"
metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
@@ -202,7 +208,6 @@
<interceptor
transaction="Bean">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
<interceptor
transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
<interceptor transaction="Bean"
metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor</interceptor>
-
<interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
</container-interceptors>

<instance-cache>org.jboss.ejb.plugins.StatefulSessionInstanceCache</instance-cache>

<persistence-manager>org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager</persistence-manager>

Discussion

  • Scott M Stark

    Scott M Stark - 2002-05-03
    • assigned_to: nobody --> starksm
    • status: open --> closed-invalid
     
  • Scott M Stark

    Scott M Stark - 2002-05-03

    Logged In: YES
    user_id=175228

    This patch is not valid as a security exception will not
    invalidate the session and throw it away as required by the
    ejb spec. Post a bug with the example demonstrating the
    original passivation failure.

     
  • Victor Langelo

    Victor Langelo - 2002-05-03

    Logged In: YES
    user_id=169968

    OK, I'll post a bug when I get a chance. But I think you
    miss understand the problem. You will always get a security
    exception when activating a passivated bean if the
    referenced beans have security constraints on their
    create/findbyPrimaryKey methods. The exception states that
    the principal=null. The security interceptor isn't in the
    stack trace when StatefulSessionInstanceInterceptor.invoice
    method calls cache.get.

    Believe me it's a bug. I've been tracing it since yesterday
    which is why I fixed the passivation problems. Right now
    I've got an update of our product to get out because people
    are suffering.

     
  • Scott M Stark

    Scott M Stark - 2002-05-03

    Logged In: YES
    user_id=175228

    I understand the problem as we have seen the issue before
    and a change was made to set the caller security context
    before accessing the stateful session cache. There may
    still be a problem here, but your suggested fix is not the
    correct solution.

     
  • Victor Langelo

    Victor Langelo - 2002-05-03

    Logged In: YES
    user_id=169968

    Well this might not be the best solution, but I don't see
    another good one. Are you're referring to the following
    lines in ContainerFactory.addInterceptors as the fix?

    /* If there is a security proxy associated with the
    container add its
    interceptor just before the container interceptor
    */
    if( container.getSecurityProxy() != null )
    container.addInterceptor(new
    SecurityProxyInterceptor());

    I'm afraid this code won't work in the case of stateful
    session beans. The StatefulSessionInstanceInterceptor is
    already in the interceptor chain by the time this code is
    reached.

    The configuration for all the other beans types add the
    security interceptor before the transaction and instance
    interceptors. I figured it couldn't be such a bad solution
    for stateful beans.

     
  • Scott M Stark

    Scott M Stark - 2002-05-03

    Logged In: YES
    user_id=175228

    No, that is the not the code. The stateful session beans
    are the only container that does have the security
    interceptor have the instance interceptor simply because it
    is the only bean that is defined as being invalidated when
    a security exception occurs. Once that happens the session
    bean is unusable. Your suggested fix would allow
    invocations in the context of a session in clear violation
    of the spec. We had a test case for a stateful session with
    references to secured ejbs to test this very issue. I'll
    try to track that down when I get a chance.

     
  • Victor Langelo

    Victor Langelo - 2002-05-04

    Logged In: YES
    user_id=169968

    OK, thanks for pointing that out. I don't have my nose in
    the spec much these days. We definately have a more
    complicated problem than I realized. See bug 552157.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks