Menu ▾ ▴

#1003 Inconsistent Proxy States in the remote classloading frontend

1.0
closed-fixed
onlyNuwanda
JFireBase (268)
6
2010-09-29
2009-10-19
jfirechief
No

DO NOT EDIT OR ANSWER THIS ISSUE. SEE THE ORIGINAL ISSUE INSTEAD:
https://www.jfire.org/modules/bugs/view.php?id=1334
ORIGINAL REPORTER: Nuwanda

The cached JFireRCLBackendRemote proxys aren't cleared once a user logs off!

This may result in the use of inappropriate proxys: The user switched from normal transport to https transport, but the remote classloading still tries to fetch the classes via the standard socket connection.
Additionally the default LoginInitialContextFactory only logs in when creating a new NamingContext, hence after changing to https and thereby using our own org.nightlabs.unifiedjndi.jboss.client.UnifiedNamingContextFactory, the user will be confronted with lots of "You don't have enough permissions for the requested action" error messages, due to the new UnifiedNamingContextFactory logging off after each method call.

Steps to reproduce:

1) Log in using the standard JBoss LoginInitialContextFactory and then log off
2) Login again using org.nightlabs.unifiedjndi.jboss.client.UnifiedNamingContextFactory (see https://www.jfire.org/modules/phpwiki/index.php/Secure%20communication%20via%20SSL%20encryption\) as well as another transportation layer (http(s)).
3) Open a previously unused perspective (to trigger the classloading mechanism)

Discussion

  • jfirechief

    jfirechief - 2009-10-19
    • labels: --> JFireBase
    • milestone: --> 1.0
    • priority: 5 --> 6
    • assigned_to: nobody --> onlynuwanda
    • status: open --> open-fixed
     

  • jfirechief

    jfirechief - 2009-10-19

    ORIGINAL COMMENT BY Nuwanda, VIEW IT HERE:
    https://www.jfire.org/modules/bugs/view.php?id=1334

    A LoginStateListener clears not the cached bean proxys from the JFireRCLBackendPool.

    Still there exists a problem related to the JBoss LoginInitialContextFactory: It only authenticates once when created, but if a user switches to our UnifiedNamingContext, the JAAS subsystem is set to check authentication on a per thread basis instead of the whole JVM.
    So after having used our UnifedNamingContext you cannot!! use the JBoss LoginInitialContextFactory anymore, since the retrieved stubs are rendered useless due to the lack of an authenication before a method call.

    We either have to completely ditch the JBoss's LoginInitialContextFactory, but then we'd need our UnifiedNamingContextFactory which needs JBoss classes and hence cannot be a required bundle of org.nightlabs.jfire.base.ui. (A login factory registry would be an alternative option.)
    Or we keep it and have to reset the JAAS subsystem when changing away from our UnifiedNamingContextFactory.

     

  • jfirechief

    jfirechief - 2010-09-29
    • status: open-fixed --> closed-fixed
     

  • jfirechief

    jfirechief - 2010-09-29

    ORIGINAL COMMENT BY Nuwanda, VIEW IT HERE:
    https://www.jfire.org/modules/bugs/view.php?id=1334

    A LoginStateListener clears not the cached bean proxys from the JFireRCLBackendPool.

    Still there exists a problem related to the JBoss LoginInitialContextFactory: It only authenticates once when created, but if a user switches to our UnifiedNamingContext, the JAAS subsystem is set to check authentication on a per thread basis instead of the whole JVM.
    So after having used our UnifedNamingContext you cannot!! use the JBoss LoginInitialContextFactory anymore, since the retrieved stubs are rendered useless due to the lack of an authenication before a method call.

    We either have to completely ditch the JBoss's LoginInitialContextFactory, but then we'd need our UnifiedNamingContextFactory which needs JBoss classes and hence cannot be a required bundle of org.nightlabs.jfire.base.ui. (A login factory registry would be an alternative option.)
    Or we keep it and have to reset the JAAS subsystem when changing away from our UnifiedNamingContextFactory.

     

Log in to post a comment.