OttoFMS on Windows with IIS — Setup Guide & CORS Issue

OttoFMS
1

Hey guys I ran into some issues installing ottoFMS on one of my clients dev server. I used Claude to help me troubleshoot. While I was able to get it to work, I ended up having to manually change some things in the web.config file. Here is the summarized findings. Can you tell me what I should be doing properly?

Environment:

  • Windows Server with IIS already installed
  • FileMaker Server 22.0.4
  • OttoFMS 4.16.2
  • OttoDeploy 2.3.0

Problem 1: OttoFMS console not accessible after installation

After installing OttoFMS on a Windows server that also had IIS running, navigating to https://[server-domain]/otto returned an IIS 404 error. The physical path in the error pointed to D:\FMDATA\BINS\www\otto, confirming IIS was intercepting requests before FileMaker’s Nginx could handle them.

Root cause: IIS was occupying port 443, preventing FileMaker’s built-in Nginx from binding to it. OttoFMS logs confirmed it was running correctly on http://localhost:3061 but traffic never reached it.

Fix: Added an IIS URL rewrite rule to the web.config file to proxy /otto traffic to OttoFMS on port 3061:

xml

<rule name="Otto" enabled="true" stopProcessing="true">
  <match url="^otto(/(.*))?" />
  <action type="Rewrite" url="http://127.0.0.1:3061/otto/{R:2}" />
</rule>

This rule should be placed at the top of the <rules> section, before all other rules. The web.config is typically located at D:\[FMDATA]\BINS\www\web.config.

Problem 2: OttoDeploy “Add Server” showing OttoFMS not installed / Otto Version: unknown

Even after the console was accessible, OttoDeploy’s Add Server dialog showed “OttoFMS not installed” with Otto Version: unknown — despite FileMaker version being detected correctly.

Verified that https://[server-domain]/otto/api/info returned correct OttoFMS data in the browser. The issue was therefore not the Otto rewrite rule itself.

Root cause: The web.config had custom CORS headers in the <customHeaders> section:

xml

<add name="Access-Control-Allow-Origin" value="[machine-hostname]" />
<add name="Access-Control-Allow-Headers" value="Content-Type, Authorization" />
<add name="Access-Control-Allow-Credentials" value="true" />

OttoFMS sets its own Access-Control-Allow-Origin header. With IIS also setting one, the response contained two Access-Control-Allow-Origin headers, which browsers and FileMaker’s fetch API reject — causing OttoDeploy to silently fail the version check.

Fix: Remove those three CORS header lines from web.config, then run iisreset in an elevated Command Prompt.

Follow-up concern: OttoFMS sets Access-Control-Allow-Origin: *

After removing the IIS CORS headers, we confirmed via browser developer tools that OttoFMS itself is setting Access-Control-Allow-Origin: * (wildcard) on the /otto/api/info endpoint. This was flagged as a potential security concern by a colleague.

Questions for the OttoFMS team:

  1. Is the wildcard Access-Control-Allow-Origin: * on OttoFMS API endpoints intentional?
  2. Is there a plan to implement more restrictive CORS policies (e.g., specific allowed origins)?
  3. Is there official documentation or a recommended web.config configuration for Windows/IIS servers running alongside OttoFMS? The current IIS conflict is not documented and caused significant troubleshooting.
2

Hey @szheng ,

Are y’all running your own IIS instance outside of the FileMaker IIS instance? OttoFMS updates the FileMaker IIS and Nginx setups to add the proper rewrites, but it cannot update IIS configs that are not he FileMaker one automatically. I can add some documentation on what rules may be necessary in this situation.

We build the configs in such a way that it makes sense when they are running with default configurations, so if you have a custom IIS setup you’ll likely have to make some changes so that it will work properly.

As for the CORS question, OttoFMS has no way to know which origins are calling to it and it should not block origins that are different, as the whole point is that it can be used as the web server for multiple applications. You can call OttoFMS from your browser, from OttoDeploy, from the Ottomatic Console, and from any other app that wants to integrate with OttoFMS using API Keys. The CORS setup makes a lot of sense for calls from a known site to a backend, but OttoFMS runs on 3000 servers that all have their own hostname and can be called from multiple places. It doesn’t make much sense for us to lock down calls that are already protected by a number of other forms of auth on the server side. If we wanted to add more specific CORS protections, OttoFMS would need to either (a) have some more solid knowledge of its own hostname, which would then immediately break when people change their server hostnames or (b) have an option to do some configuration of the allowed origins, which would have to be configurable only on the server side for security, which many users who are running OttoFMS in hosted environments do not have access to.

-Kyle

1 Like
3

Thanks for the clarification. Yes, IT team was running its own IIS instance outside of FileMaker IIS instance. They wanted to lock the security down well. I just wanted to make sure that I am not opening up the server to potential security risks by deleting those CORS, but those were the dev and staging environment so I am not too concerned about it. If I want to apply ottoFMS to the production, I may have to modify the webconfig file on that too. Do you see any potential security issue that may arise? Thanks.

4

I don’t see any specific security concerns, as long as the headers are being added once it should be fine. Since these are server applications that can accept requests from many clients it makes sense to have a somewhat open CORS policy.

-Kyle