Results 1 to 6 of 6

Thread: Trouble with Oracle Application Server and channelProcessingFilter

  1. #1
    Join Date
    Mar 2005
    Posts
    6

    Default Trouble with Oracle Application Server and channelProcessingFilter

    I added "channelProcessingFilter" to the front of my "filterChainProxy" to secure login, changepassword, and signup pages. This worked great when I deployed it to tomcat. I have to deploy ultimately to Oracle Application Server however, and there I ran into trouble. Has anyone run into a similar problem and found a way to fix it?

    For example, when I attempt to access the login page using http, the request is successfully redirected to use https. When the login page is submitted I can see in the log that the user is authenticated. After that I see each servlet container redirecting the request to the login success page. I compared my log files between tomcat and oc4j and everything is the same through line 305 of FilterChainProxy$VirtualFilterChain.doFilter, where the log states "firing Filter: 'net.sf.acegisecurity.context.HttpSessionContextIn tegrationFilter@...'. At this point tomcat follows with:
    "HttpSessionContextIntegrationFilter.doFilter( 180) | Obtained from ACEGI_SECURITY_CONTEXT a valid Context and set to ..."

    oc4j, on the other hand, has lost track of the session at this point:
    HttpSessionContextIntegrationFilter.doFilter(202) | No HttpSession Currently exists
    Stu Smiley

  2. #2
    Join Date
    Sep 2004
    Location
    Christchurch, New Zealand
    Posts
    73

    Default

    I think you may need to set the shared attribute of <web-app> to true:

    https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id= 295578.1

    https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id= 231419.1

    and the following statement at:

    http://www.oracle.com/pls/as1012/to_URL?remark=drilldown&urlname=http:%2F%2Fdownloa d-west.oracle.com%2Fdocs%2Fcd%2FB14099_12%2Fweb.1012 %2Fb14017%2Fconfdesc.htm%23sthref586

    shared: Allows sharing of a published Web module between Web sites, when a Web site is defined by a particular pairing of a protocol and a port. Supported values are "true" and "false" (default). Sharing implies the sharing of everything that makes up a Web application, including sessions, servlet instances, and context values. An example is to share a Web application in OC4J standalone between an HTTP site and an HTTPS site at the same context path, when SSL is required for some but not all the communications. (Performance is improved by encrypting only sensitive information, rather than all information.)

    If an HTTPS Web application is marked as shared, its session tracking strategy reverts from SSL session tracking to session tracking through cookies or URL rewriting. This could possibly make the Web application less secure, but may be necessary to work around issues such as SSL session timeouts not being properly supported in some browsers.
    Note though that the doco says this only applied to standalone OC4J, but does not say how 'shared' is dealt with in an OC4J instance in 10gAS.

    Chris

  3. #3
    Join Date
    Mar 2005
    Posts
    6

    Default

    Thanks for the lead Chris. I tried setting shared="true", but it had no affect. This appears to be a reoccurring problem in Oracle > Application Server > OC4J/J2EE forum. Setting shared="true" seemed to work for some folks and not for others.
    Stu Smiley

  4. #4
    Join Date
    Sep 2004
    Location
    Christchurch, New Zealand
    Posts
    73

    Default

    What version of OC4J (java -jar oc4j.jar -version) are you using?

  5. #5
    Join Date
    Mar 2005
    Posts
    6

    Default

    I am using version 9.0.4.0.0
    Stu Smiley

  6. #6
    Join Date
    Sep 2004
    Location
    Christchurch, New Zealand
    Posts
    73

    Default

    I am using a later version (10.1.2.0.0), but here is a couple of things you can try. Set the debug flag

    -Dhttp.session.debug=true

    when you start OC4J, this will give you extra information about what OC4J thinks it is doing with sessions. You could also try deploying your app to a later version of OC4J, 10.1.2.0.2 (the lattest production release) and/or 10.1.3dp4, to see if your problem persists in a later version.

    This may either highlight a bug in 9.0.4.0.0, or at least give you some more info or were OC4J lost track of the session.

    Chris

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •