Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    loginRequiredMarker: document.domain is immutable in chrome >= 115

    We use de loginRequiredMarker in our login-Page as described in the SmartClient Documentation.

    Now we run into troubles with newer Chrome Versions (115, 116):
    - The Message 'document.domain mutation is ignored because the surrounding agent cluster is origin-keyed' is displayed in the console
    - Chrome is 'hanging', and the Tab will be closed after a while.

    When we remove loginRequiredMarker from the login-Page it is working again.

    See also https://developer.chrome.com/blog/do...r-deprecation/

    regards Bruno

    #2
    Thanks for the report and details - we're taking a look and we'll update here shortly.

    Comment


      #3
      Hi Bruno, some questions:

      1. are you saying that this happens when you access your login page directly, or when your SmartClient application makes a data request and the login page is received as a response?

      2. If the latter, the code in the loginRequiredMarker would not normally actually execute, if the request was made with xmlHttpRequest. It would only execute with “hiddenFrame” comm. Are you forcing “hiddenFrame” comm for some reason?

      3. If the former, you should be able to just remove the line from the loginRequiredMarker that attempts to set document.domain.

      Comment


        #4
        Hi

        it happens when a user is accessing our application and is redirected to the login page. So its case 1 (access login page directly).
        It does not happen to all users but to many of them, we don't know when its happening and when not.

        if i remove all 4 lines where document.domain is set or updated the most of the loginRequiredMarker is deleted, only the last 3 lines are remaining.
        Is this ok?

        Regards Bruno

        Comment


          #5
          You should be able to just comment the entire condition that contains all the references to document.domain, yes.

          We're looking into dealing with this in loginRequiredMarker and will update here shortly when we have more information.

          Comment


            #6
            Hi Bruno,

            When we add the loginRequiredMarker to a sample login page, we do see deprecation warnings in Chrome, but we do not see the "hung tab" effect that you describe.

            Is it possible that you somewhat modified the marker, combining it with other logic in the same <script> tag, so that other logic that is needed for your page doesn't execute after the error in the loginRequiredMarker?

            Or perhaps we have misunderstood the circumstance of the error. Let's say a user has bookmarked the login page and goes directly there. Is there an issue?

            Comment


              #7
              This has also created a production critical bug for us. In our landing page, we have this as the initial code:
              Code:
                  <SCRIPT>//'"]]>>isc_loginSuccess
                  //
                  // When doing relogin with a webserver-based authenticator, protect this page with it and
                  // target your login attempts at this page such that when the login succeeds, this page is
                  // returned.
                  //
                  // If you are integrating with a web service that returns a fault, paste this entire script
                  // block VERBATIM into the fault text.
                  //=======
              
                      if (!window.isc && document.domain && document.domain.indexOf(".") != -1
                          && !(new RegExp("^(\\d{1,3}\\.){3}\\d{1,3}$").test(document.domain))) {
              
                          var set = false;
              
                          while (document.domain.indexOf(".") != -1) {
                              try {
                                  if (window.opener && window.opener.isc) break;
                                  if (window.top.isc) break;
              
                                  if (!set) { document.domain = document.domain; set = true; }
                                  else { document.domain = document.domain.replace(/.*?\./, ''); }
                              } catch (e) {
                                  try {
                                      if (!set) { document.domain = document.domain; set = true }
                                      else { document.domain = document.domain.replace(/.*?\./, ''); }
                                  } catch (ee) {
                                      break;
                                  }
                              }
                          }
                      }
              
                      var isc = top.isc ? top.isc : window.opener ? window.opener.isc : null;
              
                      if (isc) isc.RPCManager.delayCall("handleLoginSuccess", [window]);
                  </SCRIPT>
              Are there any suggestions on what will be recommended since we can't use document.domain anymore?

              Comment


                #8
                Have you read the rest of this thread? The solution is already above (#5) - you can just comment out the code that attempts to access document.domain.

                However, please also answer the questions above (#3). So far, no one at Isomorphic has been able to reproduce anything more than deprecation warnings from Chrome, but you seem to be saying this is a "production critical" problem, so presumably, that means you are getting more than deprecation warnings.

                Comment


                  #9
                  We ran into this as well, but only when running from localhost. Thank you for the info on where this is coming from.

                  Comment


                    #10
                    We are also using the 'loginRequiredMarker' login page and it "hung tab" and no response. It happens on both MS Edge and Chrome browsers.

                    changes to document.domain is not allowed in the latest browsers. Any solution/alternative to this issue?

                    Comment


                      #11
                      Yes, simply read the thread you have replied to, the solution is already there.

                      Comment

                      Working...
                      X