ICEfaces
  1. ICEfaces
  2. ICE-2051

ACEGI SSL configuration causes Bridge js permission exceptions

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Invalid
          • Affects Version/s: 1.6
          • Fix Version/s: 1.6.2
          • Component/s: Tool Integrations
          • Labels:
            None
          • Environment:
            any
          • Support Case References:
            support case: #4204

            Description

            When configuring ACEGI with SSL it doesn't work with ICEfaces.
            The same configuration works in a standard JSF environment.

              Activity

              Ascending order - Click to sort in descending order
              Michael Thiem created issue -
              Michael Thiem made changes -
              Field Original Value New Value
              Support Case References support case: #4204
              Hide
              Permalink
              Michael Thiem added a comment -

              example application tested on tomcat 6.0

              Show
              Michael Thiem added a comment - example application tested on tomcat 6.0
              Michael Thiem made changes -
              Attachment ICEfacesAcegiExample.war [ 10641 ]
              Michael Thiem made changes -
              Attachment ICEfacesAcegiExample-src.zip [ 10642 ]
              Hide
              Permalink
              Daniel Hirscher added a comment -

              The problem is the channelProcessingFilter. If this filter is active (listed in the filterChainProxy) then icefaces does not work.
              The icefaces acegi example does not contain this filter. Maybe this is a known problem.
              However, switching from a non-secure to a secure channel is a fundamental requirement of a secure application.

              Show
              Daniel Hirscher added a comment - The problem is the channelProcessingFilter. If this filter is active (listed in the filterChainProxy) then icefaces does not work. The icefaces acegi example does not contain this filter. Maybe this is a known problem. However, switching from a non-secure to a secure channel is a fundamental requirement of a secure application.
              Hide
              Permalink
              Philip Breau added a comment -

              Specifically, it seems that using the filterChainProxy causes the AJAX Bridge to throw an uncaught exception in synchronizer.js line 39:

              if (window.frames[0].location.hash.length > 0) this.reload();

              "uncaught exception: Permission denied to get property Location.hash"

              Show
              Philip Breau added a comment - Specifically, it seems that using the filterChainProxy causes the AJAX Bridge to throw an uncaught exception in synchronizer.js line 39: if (window.frames [0] .location.hash.length > 0) this.reload(); "uncaught exception: Permission denied to get property Location.hash"
              Philip Breau made changes -
              Summary ACEGI SSL configuration won't work when used with ICEfaces ACEGI SSL configuration causes Bridge js permission exceptions
              Philip Breau made changes -
              Assignee Mircea Toma [ mircea.toma ]
              Ken Fyten made changes -
              Fix Version/s 1.6.2 [ 10111 ]
              Assignee Priority P2
              Hide
              Permalink
              Mircea Toma added a comment -

              It looks like the installed ACEGI servlet filters are blocking the requests for the Javascript files and redirect them to the context root path (/ICEfacesAcegiExample).
              The components contained in the login page are not working because they rely on the Bridge being available and running.

              One solution to the problem would be to not filter the requests made for /block/* and /xmlhttp/* paths (or maybe filter just on *.iface since the servlet pattern matching is not very powerful).
              A second solution would be to not use Icefaces components in the login page. Once logged in the requests for the Javascript files won't be redirected anymore.

              Show
              Mircea Toma added a comment - It looks like the installed ACEGI servlet filters are blocking the requests for the Javascript files and redirect them to the context root path (/ICEfacesAcegiExample). The components contained in the login page are not working because they rely on the Bridge being available and running. One solution to the problem would be to not filter the requests made for /block/* and /xmlhttp/* paths (or maybe filter just on *.iface since the servlet pattern matching is not very powerful). A second solution would be to not use Icefaces components in the login page. Once logged in the requests for the Javascript files won't be redirected anymore.
              Mircea Toma made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Invalid [ 6 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]
              Assignee Priority P2
              Assignee Mircea Toma [ mircea.toma ]

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Michael Thiem
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: