![]() On GitHub you can find the script that let’s you upload a single file. With this information I had everything I needed to replicate the HTTP traffic for uploading a file. The public key is stored on the server at /opt/FileMaker/FileMaker Server/CStore/machinePublicKey and obviously differs from installation to installation. This worked and I got a valid session token back. So I just tried to encrypt my admin credentials using the public key which the server gives the client as part of the step before the authentication (via the /fmws/serverInfo endpoint). The ciphertexts were changing with every authentication but were nicely aligned in size. Since the server needs to be able to decrypt the encrypted credentials, the client needs to use information the server actually has as well. This was helpful to figure out one important thing: how does the client encrypt the username and password (the credentials that are also used for the admin console/api). Once I had the basic structure of the requests, I could easily experiment with different headers and payloads. So I decided to try to build my own “quick and dirty” client to be able to upload files. While the above may sound quite involved, it takes a relatively short time to figure out the relevant requests and responses when you control all the components (the client, the network and the server). If your app uses remote containers, these are sent as well to the /fmws/MainDB/UploadTemp_FMS/ endpoint (followed by the container folder structure). There are a couple of more requests to send a start and end event, a request to open the database, a status check and so on, but essentially this is all there is to uploading a database. Change the cipher to AES128-SHA (to not have to worry about forward secrecy).Disable the TLSv1.2 and TLSv1.3 protocol.In the config I relaxed the security settings a bit so that I can easily decrypt the traffic on the fly. Nginx actually gives the traffic to the fmserverd process which has a listener on the loopback interface on port 1895. I had my test FileMaker Server installed on Linux, so I checked the SSL settings in the nginx config at /opt/FileMaker/FileMaker Server/NginxServer/conf/fms_nf as nginx receives all the traffic on port 443. Since the traffic was going to port 443 rather than FileMaker Server’s default 5003 I assumed this was just encrypted HTTP traffic. I started the FileMaker Pro client, selected the Upload feature and listened to the network traffic.īy default, all you see is TLS traffic which isn’t so helpful. So I decided to have a quick look at it – and it turns out, FileMaker Pro is actually just using an internal HTTP API. upload by copying files directly onto the server (manually or scripted)Ī couple of days ago I wondered if there’s any technical reason the Admin HTTP API doesn’t support this feature or if the Pro client does something special.The only two options to upload fmp12 files to the server are thus: Later, as the Admin REST API was released, the upload feature was still missing. Rather, the upload feature was integrated into the Pro client. For some reason this feature did not survive the admin console rewrite a decade (?) ago. Uploading files to FileMaker Server without a Pro clientīack in the dark ages the FileMaker Server admin console (then Java Web Start) allowed you to remotely upload new fmp12 files to the server.
0 Comments
Leave a Reply. |