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

    frontend-fingerprint did not match. Session terminated.

    Kopano WebApp
    7
    12
    1440
    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.
    • bioProjekt GmbH
      bioProjekt GmbH last edited by

      Hi,

      since we upgraded our Firefoxes from 79.13.0esr to 91.0esr we have the following issue:

      1. Open new Firefox window
      2. Navigate to the URL of Kopano WebApp
      3. Login

      After this the circles are circling forever, and the Apache error log of the Kopano server shows

      [Fri Aug 27 11:00:04.030380 2021] [php7:notice] [pid x] [client x.x.x.x:x] frontend-fingerprint did not match. Session terminated. <user>, referer: <URL>

      After pressing F5 and do a second login attempt everything works as expected.

      Are there any ideas what’s going on?

      Thanks for your support and many greets
      Stephan

      steph32 1 Reply Last reply Reply Quote 2
      • steph32
        steph32 @bioProjekt GmbH last edited by

        @bioprojekt-gmbh hi,
        I have the same problem, do you find the solution,

        Thanx,

        Stephane

        1 Reply Last reply Reply Quote 1
        • matthi
          matthi last edited by

          The same here.

          1 Reply Last reply Reply Quote 0
          • rene.bayer
            rene.bayer last edited by

            We commented out the last if statement in /usr/share/kopano-webapp/server/includes/controllers/service.fingerprint.php as a workaround

                    // Single sign on will never go through the login page. So we cannot check
                    // the fingerprint there!
                    //if ( OIDC_ISS === "" && !WebAppAuthentication::isUsingSingleSignOn() && (!isset($_SESSION['frontend-fingerprint']) || $_POST['fingerprint'] !== $_SESSION['frontend-fingerprint']) ){
                    //       error_log('frontend-fingerprint did not match. Session terminated. ' . WebAppAuthentication::getUserName());
                    //        $phpSession->destroy();
                    //        Response::unAuthorized();
                    //}
            
            steph32 1 Reply Last reply Reply Quote 0
            • steph32
              steph32 @rene.bayer last edited by

              @rene-losert said in frontend-fingerprint did not match. Session terminated.:

              mmented out

              It seems to work.
              Thank you very very much.

              Stephane.

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

                Is this the solution? It doesn’t seem right to disable security checks to work around bugs.

                It surely must be possible to solve this bug so that it works fine again with Firefox without just discarding security checks, right?

                1 Reply Last reply Reply Quote 0
                • bioProjekt GmbH
                  bioProjekt GmbH last edited by

                  Hi,

                  since Firefox 91.1.0esr the problem doesn’t occur anymore. Can anybody confirm this? Did Firefox changed its bevaviour?

                  Thanks and greets
                  Stephan

                  loloca Manuel1948 2 Replies Last reply Reply Quote 0
                  • loloca
                    loloca @bioProjekt GmbH last edited by

                    @bioprojekt-gmbh
                    Hi,
                    our customers and employees also complain about this problem. Unfortunately it cannot be solved yet.
                    Thanks, Siegfried

                    1 Reply Last reply Reply Quote 1
                    • Manuel1948
                      Manuel1948 @bioProjekt GmbH last edited by

                      @bioprojekt-gmbh Cant’ confirm, but in normal Firefox version 94.0.2 64bit the problem is still occurring.

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

                        Dear people,

                        the browser executes a javascript function, which sends a fingerprint (special id) to the server (at logon request) and later at login the server checks if the fingerprint is the same.
                        In Firefox (my version 94.0.2 64bit) the second fingerprint differs from the first one.

                        I investigated this issue a little bit further and found out that this fingerprint is based on fonts, which the browser can load from the OS, so basically which fonts from a given array are installed, and which are not.

                        In this case the “Arial Narrow” font isnt recognized at the earlier check, but then later it is, so that why the fingerprint differs - don’t ask me why?

                        The workaround/solution is to remove this “Arial Narrow” font from the javascript, so that the fingerprint doesn’t change because of it.

                        Workaround/Solution
                        In /usr/share/kopano-webapp/client/fingerprint.js search for Arial Narrow; and remove it from this file (marked green), save it and you should be good to go.
                        9f458034-6971-411b-a6f7-d32508fb2757-image.png

                        laurensb 1 Reply Last reply Reply Quote 0
                        • laurensb
                          laurensb @Manuel1948 last edited by

                          @manuel1948 Works for me, many thanks for investigating this and sharing a solution!

                          1 Reply Last reply Reply Quote 0
                          • bioProjekt GmbH
                            bioProjekt GmbH last edited by

                            Hi,

                            last week we ran into this again. Last time we didn’t need to integrate the workaround Manuel mentioned, today we did. Let’s see if things get better. Is this a known bug?

                            Greets
                            Stephan

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