Hello All,
I am trying to leverage the API proxy feature to have a javascript widget from my solution call the dataAPI so it does not interrupt a user when it needs to refresh the data. I am trying to create a script that can test my calls from within my filemaker solution first. I think the proper way to create the call is with the headers. Does anyone have any resources about how I can construct the headers to include the bearer token properly/securely?
If you are building anything with JavaScript, I strongly suggest you look into the ProofKit packages we publish. For your case, the @proofkit/fmdapi package would help you make the Data API calls you need from Node.js.
Security Note: When building in a webviewer, it’s not recommended to make these calls directly to your filemaker server because you will be required to expose the credentials (either Data API key or username/password) to the browser. So if you want a truly uninterrupted flow where you’re not calling a FileMaker script, you probably need a proxy layer in between to manage the authentication. Let me know if you want more details about that.
But to answer your original question, to construct the headers with a Data API key, you simply add an Authorization header with the value Bearer <your_api_key> and then just add /otto at the beginning of your URL path (e.g. https://filemaker.example.com/otto/fmi/...)
Thank you so much for pointing me at Proofkit - It looks like the primary way Proofkit talks to a Filemaker server is via the Data API rather than oData. Is that correct? Also, I would like to know a little more about the proxy layer you described - I want to attempt to write more of my code in JS and not have to call every function as a Filemaker script. Thank you in advance.
Yes, right now we publish a Data API package and not an OData package, but we are exploring how we can leverage OData in the future and there will certainly be an OData library from ProofKit in the future.
The proxy layer that I describe would be server-side JavaScript code. This means Node.js running on either a serverless function (like AWS Lambda or CloudFlare workers) or a long-running traditional server. There are many many ways to accomplish this, but probably the most simple is Vercel because it will automatically deploy your code to a URL that you can call from the browser. This deployment can be linked up with a GitHub repository, so that it happens each time you push your code (which is also kinda like “saving your changes” in git terms).
But this then exposes another security concern, because you now need to validate that requests to that URL are allowed to access your data. Again, many solutions to this, but it’s something to be aware of. When I’ve done this method in the past, we setup an API key that the server-side code verifies before processing the request, and that API key gets injected into the WebViewer at startup, using “Perform JavaScript in WebViewer” script step.
You can have both of these in a single app if you use a framework like Next.js. This is what the ProofKit CLI will build for you if you create a new project and choose “Web app for browsers” rather than the WebViewer option. With Next.js, any file that starts with “use client” at the top will run in the browser (or webviewer) and you can still use the @proofkit/webviewer package to call FileMaker scripts sometimes, but other times you can call the API functions within Next.js to run the server-side code which can talk directly to the FileMaker server. You’ll still need to protect those API routes with some kind of authentication, but hopefully this will help you get a litter further!