4 Replies Latest reply on Oct 28, 2015 7:13 AM by Jonathan Jeffery

    Filemaker PHP custom web publishing fails

    Jonathan Jeffery

      FileMaker Server 14.0.3.302

      Win Server 2012 R2

       

      When I try to connect to a database via the PHP API, I get the return

      "XML error: Not well-formed (invalid token) at line 1"

       

      I have tried various databases (including ones made just for testing)

       

      The API is undoubtedly functioning, as I can get the API version, and I receive appropriate error messages if I change the IP.

       

      However, any other request returns the error above.

       

      I've found this error reported occasionally on forums, for different versions of filemaker, but never with a resolution.

       

      A basic php script would look like this:

      // 1a. Include the FileMaker PHP API

      $File = "FileMaker.php";

      require_once ($File);

       

      // 1b. Set DB values

      $FM_IP =  '127.0.0.1' ;

      $FM_File =  'TestOfPHP.fmp12' ;

      $FM_User = "User";

      $FM_Pass = "Password" ;

       

      // 2. create the FileMaker Object

      $fm = new FileMaker( $FM_IP, $FM_File, $FM_User , $FM_Pass );

      $AIPversion = $fm->getAPIVersion () ;

       

      // 3. check username and password

      // create 'find all' object for $fm and execute

      $logon_test = $fm->newFindAnyCommand('Test'); //set find method

      $logon_result = $logon_test->execute(); //execute find method

       

      // if no log-in, $logon_result will be an FM_ERROR object

      if (FileMaker::isError($logon_result)) {

        $ErrorMessage = $logon_result->getMessage() ;

        die( $ErrorMessage );

        }


      I've already checked:

      1. The username/password is correct

      2. The user privset has access via PHP web publishing

      3. The correct ports are all open ( error occurs even if the firewall is switched off)

       

      My FM server has an SSL certificate installed, and it is working fine for Filemaker client connections (I get the green padlock), but interestingly, when I test the technologies via the admin console, the php test uses the IP address, not the host name, and complains about the SSL host name (the certificate includes both DNS name and machine name in the Subject Alternate Name setting)

        • 1. Re: Filemaker PHP custom web publishing fails
          TSGal

          jonj:

           

          Thank you for your post.

           

          Although I have not seen this occur with FileMaker Server 14, another customer on the forum encountered the same issue with FileMaker Server 13, but after rebooting the machine, the error no longer occurred.  For more details, see:

          CWP XML Error 1 in new installs on Windows

           

          Also, launch Admin Console (locally or remotely) and make sure the Web Server and Web Publishing both turned on (green checkmarks).

           

          Keep me updated with any progress.

           

          TSGal

          FileMaker, Inc.

          • 2. Re: Filemaker PHP custom web publishing fails
            Jonathan Jeffery

            Hi,

             

            I’m afraid that a server restart doesn't fix anything.

             

            The admin console shows custom web publishing and WebDirect as green.

             

            I have a test database on the server using XML custom web publishing and another that uses WebDirect, both are working fine (both as a guest and as a passworded account).

             

            However, the 'technology test' page for PHP reports the same error (XML error: Not well-formed (invalid token) at line 1). It also accesses the page using the public IP address, rather than the server name, which means that the SSL certificate isn’t going to work!

             

            This is a recent, clean install (last Wednesday). Having installed a certificate on the server, and configured a couple of other websites on the server, if would be a real pain to have to start from scratch (with no idea what went wrong, and therefore no idea if the effort will be worthwhile…)

             

            I have an older server running FM13 and the php module in a very similar set-up and I can’t spot any real differences in the configuration, except that for some reason the older set-up has the 64bit version of php, but the newer set-up has the 32bit version of php (both servers are fully updated win2012 R2 64bit)

             

            regards,

             

            J

             

            --

            Dr Jon Jeffery 

            jon@donnasaxby.com  •  07719 688 292  •  01242 461 137 

            10 Copt Elm Close  •  Cheltenham  •  GL53 8AD  •  K

            • 3. Re: Filemaker PHP custom web publishing fails
              TSGal

              jonj:

               

              Thank you for the additional information.

               

              First, to test any possible network issue, try accessing the test page from the server.  If that doesn't work, temporarily disconnect the server from the network.  Lastly, getting back to the bare bones basics, disable the other websites from the server so only FileMaker Server is available.

               

              Both FileMaker Server 13 and FileMaker Server 14 installed PHP 32-bit.  If your solution was working fine in FileMaker Server 13 with PHP 64-bit, then as a test, try using the same PHP 64-bit with FileMaker Server 14.

               

              Continue to keep me updated.

               

              TSGal

              FileMaker, Inc.

              • 4. Re: Filemaker PHP custom web publishing fails
                Jonathan Jeffery

                Ah ha, fixed... I was using the URL rewrite module in IIS to swap users seamlessly to a secure connection (i.e. http://myserver.com/fmi/webD would automatically be swapped to https://myserver.com/fmi/webD ).

                 

                I like this, as it means that everyone connects securely without having to understand the different URLs.

                 

                However, as my database was hosted locally, the php connection was to 127.0.0.1 (localhost) -- it looks like this was also being redirected to a secure connection. The 'XML error' was probably a normal 404 error saying that the page https://127.0.0.1 doesn't exist!

                 

                I adjusted my URL rewrite rule to swap to a secure connection UNLESS the connection is from localhost, and now the php api is working as expected.