Navigation

    Kopano
    • Register
    • Login
    • Search
    • Categories
    • Get Official Kopano Support
    • Recent
    Statement regarding the closure of the Kopano community forum and the end of the community edition

    DeskApp 1.7 - net:ERR_FAILED Bug (including solution)

    Kopano DeskApp
    2
    8
    1267
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Harti
      Harti last edited by

      I just identified an issue with profiles in the DeskApp (causing net:ERR_FAILED to occur).

      The web server URL is being trimmed from e.g. “https://” to “//” (which usually checks by itself whether the service has SSL enabled, so it’s common practice) after saving the profile.

      This causes authentication to fail once you’re trying to sign in, because the application tries sending an XHR to “chrome://example.com/webapp/” instead of “//example.com/webapp/”. I’m assuming XHRs do not default to the automatic SSL lookup behavior and need their protocol to work.

      Hence, the whole code in modules/WebAppWindow.js is erroneous. I could not identify where exactly the “https:” part is being omitted, but created a function to sanitize this.profile.requestOptions.url that is being called whenever that variable is being referenced.

      Your engineers might want to look into hotfixing this.
      See this gist as a guide.

      -Harti

      1 Reply Last reply Reply Quote 0
      • bjoernneumann
        bjoernneumann Kopano (Inactive) last edited by

        Hi Harti,

        thank you very much for your findings and the solution.

        I’d like to find the root cause for that. Are you able to reproduce this issue?

        Cheers, Björn

        1 Reply Last reply Reply Quote 0
        • Harti
          Harti last edited by

          I don’t know what environments you’re using, and what you suggest “the issue” is - however this issue is reproducible for our whole office.

          I believe the issue is the part where it saves your profile configuration and trims the “https:” from the URL. I haven’t investigated what kind of XHR calls you are making when saving the config, but it should be easy to find out for your software developers why the string value is getting converted.
          Usually, when a user specifies that their Kopano WebApp address is HTTPS, it’s fair to assume that the user wanted to put HTTPS and not the “take whichever protocol” wildcard ("//"). It’s also very unlikely that a HTTPS service ever changes to HTTP only.

          As for the “//” causing a lookup issue, this could theoretically be due to Windows 10 Pro or our DNS doing weird things, but I doubt that this should be resolved on our end.

          1 Reply Last reply Reply Quote 0
          • bjoernneumann
            bjoernneumann Kopano (Inactive) last edited by

            @Harti
            We never had such an issue in our environments.
            But sure, looks like a protocol-relative URL.

            Maybe the Location header returned by the webserver looks like that.
            Could you check what the webserver returns in “Location:”?

            Harti 1 Reply Last reply Reply Quote 0
            • Harti
              Harti @bjoernneumann last edited by

              @bjoernneumann said in DeskApp 1.7 - net:ERR_FAILED Bug (including solution):

              Maybe the Location header returned by the webserver looks like that.
              Could you check what the webserver returns in “Location:”?

              You’re correct, that returned the protocol relative URL starting with “//”.

              I think it’s running behind a proxy but I’m not the sysadmin so take this information with a grain of salt.

              1 Reply Last reply Reply Quote 0
              • bjoernneumann
                bjoernneumann Kopano (Inactive) last edited by

                @Harti
                Thanks for checking.
                I’ve created https://jira.kopano.io/browse/KD-363

                1 Reply Last reply Reply Quote 0
                • Harti
                  Harti last edited by Harti

                  @bjoernneumann
                  I had our sysadmin check/fix the Location header, DevTools now return “https://”, but the result stays the same unfortunately (even after deleting and re-creating a profile).
                  Thanks for creating the bug report.

                  1 Reply Last reply Reply Quote 0
                  • bjoernneumann
                    bjoernneumann Kopano (Inactive) last edited by bjoernneumann

                    @Harti
                    Created a fix for this. As we cannot reproduce this internally, would it be possible for you to test it?

                    https://stash.kopano.io/projects/KD/repos/kopano-deskapp/commits/f0ab20481f5bebea986d7acf7091f9018661cbba
                    https://stash.kopano.io/projects/KD/repos/kopano-deskapp/commits/59e762d4f34fd1bed72c66374a1ab4489842822b

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post