PHP websites en FM server 2023

[Marsau]

Beste mensen, het is bekend dat de FileMaker PHP API 'depreciated' is, en dat sinds een aantal versies ook niet meer in de standaard-installatie zit. Het wordt beschouwd als 'obsolete' technologie.

Zie ook deze Claris Engineering Blog over dit onderwerp.

Dat is voor een klant van mij met uitgebreide PHP websites een reden om vast te houden aan versie <19.4.  Er is weinig animo om de sites geschikt te maken voor de FM Data API

Maar... voor zover ik tot nu toe heb begrepen werkt het nog wel onder de laatste FMS versie ( 20.3.2.205) , mits je het juiste PHP-pakket op de juiste wijze installeert. Ik ben benieuwd of jullie dit kunnen bevestigen; wellicht hebben jullie een PHP-implementatie op een FMS in beheer...

 

 

[Peter Wagemans]

Misschien interessant om te weten: ik had hetzelfde probleem met een klant die kalenders in FileMaker heeft, en we hebben dus een prima werkende php oplossing die de queries naar FileMaker uitvoert, maar die met FileMaker Server 20 dus niet meer werkt.

De reden is: kalender subscription urls. Die kan je niet laten werken via de data API, maar wel via een php paginaatje. Maar waarschijnlijk denkt Claris dat ook kalenders "obsolete" technologie zijn 🤔 of dat de bijkomende servers die nu benodigd zijn, op de klanten hun rug groeien.

Hoe dan ook, eerste poging was php mogelijk maken via de nginx web server, want Apache is waarschijnlijk ook obsolete technologie. Maar dat is niet zomaar mogelijk, en na een paar uur pielen en allerlei web sites aflopen voor ingewikkelde oplossingen, vond ik het welletjes.

Apache geinstalleerd en in de conf file ingesteld op 81 en 444.

Vervolgens dit stukje bijgevoegd in de conf file van nginx:

/opt/FileMaker/FileMaker Server/NginxServer/conf/fms_nginx.conf

    # server omniorb using wss
    location ^~ /fms/ws {
      proxy_pass http://127.0.0.1:8091/fms/ws;
      proxy_read_timeout 86400s;
      proxy_send_timeout 86400s;
      keepalive_timeout 86400s;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection  $connection_upgrade;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Host $host:$server_port;
    }

	location ~ \.php$ {
            # this block will catch any requests with a .php extension
            # normally in this block data would be passed to a FastCGI process
 
            # these two lines tell Apache the actual IP of the client being forwarded
            # Apache requires mod_proxy (http://bit.ly/mod_proxy) for these to work
            # Most Apache 2.0+ servers have mod_proxy configured already
 
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $remote_addr;
 
            # this next line adds the Host header so that apache knows which vHost to serve
            # the $host variable is automatically set to the hostname Nginx is responding to
 
            proxy_set_header Host $host;
 
            # And now we pass back to apache
            # if you're using a side-by-side configuration the IP can be changed to
            # apache's bound IP at port 80 such as http://192.170.2.1:80
 
            proxy_pass http://127.0.0.1:81;
      }

   # location / {
     # First attempt to serve request as file, then
     # as directory, then fall back to displaying a 404.
     # try_files $uri $uri/ =404;
   # }

Alle PHP requests worden nu geproxied naar de Apache server op dezelfde machine (Ubuntu hier in dit geval). Is geen wizardry want de conf file staat vol met dat soort proxy loodgieterij. Ik kwam dit ergens tegen op een web site, en heb het mits een kleine aanpassing aan de location parameter schaamteloos overgenomen

Heb de FileMaker authenticatie niet voor mekaar, maar da's niet erg. In de php code staan de credentials voor de kalenders, en voor de rest gebruik ik een .htaccess filetje zodat de php file via basic authentication beschermd is. De php file gebruikte curl en de FMData API. Ik heb zelfs de urls compatibel gehouden met de oude php code.

Werkt prima, maar als iemand weet hoe je authenticatie kan doorpijplijnen, wees welkom om hier wat licht op de situatie te schijnen. Ik weet gewoon niet genoeg over nginx om dit voor mekaar te krijgen, en heb het voor deze specifieke oplossing ook niet nodig omdat de subscription kalender code voor elke gebruiker dezelfde data moet doorsturen.