Word of caution: As should be clear from the post, my custom client is the result of me figuring out an undocumented API for a couple of hours in the evening. $ python3 upload.py admin password test.fmp12 If all works, the output looks like this. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |