FoundryVTT server behind an IIS reverse proxy CORS issues

Question

I have a FoundryVTT server in a FreeNAS jail. I mostly followed these instructions to get it to work. I had a previous problem, which I solved and it works fine now for <= v0.7.9. However, >= v0.8 no longer works and I keep getting CORS related issues when I approach the server via WAN. The only thing I can see in both the logging and the webpage console (or through fiddler) is a 403 and the body text:

{"error":"Cross-origin requests are not allowed"}

I have approached the FoundryVTT Discord and they basically said that nothing CORS related should have been changed and that I should use something other than IIS manager (v10.0.19041.1).

What I have tried:

• Verified it is an actual problem with the newer version. Created a new 0.7.9. instance following the same steps and it works fine.

• Adding custom headers, like so:

  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="*" />
      <add name="Access-Control-Allow-Headers" value="Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers" />
      <add name="Access-Control-Allow-Methods" value="GET,HEAD,OPTIONS,POST,PUT" />
      <add name="Access-Control-Allow-Credentials" value="false" />
    </customHeaders>
  </httpProtocol>
  

  And with various combinations of them (like specifying www.myhost.com and allow credentials to true, * allowing headers/methods)

• Applied outbound rewrite rules:

  <rule name="Test1">
    <match serverVariable="RESPONSE_Access_Control_Allow_Origin" pattern=".*" />
    <action type="Rewrite" value="*" />
  </rule>
  <rule name="Test2">
    <match serverVariable="RESPONSE_Access_Control_Allow_Headers" pattern=".*" />
    <action type="Rewrite" value="*" />
  </rule>
  <rule name="Test3">
    <match serverVariable="RESPONSE_Access_Control_Allow_Methods" pattern=".*" />
    <action type="Rewrite" value="GET,HEAD,OPTIONS,POST,PUT,DELETE" />
  </rule>
  <rule name="Test4">
    <match serverVariable="RESPONSE_Access_Control_Allow_Credentials" pattern=".*" />
    <action type="Rewrite" value="false" />
  </rule>
  

  Also tried various combinations, as written before.

• Installed the CORS module and also tried various things with it, like so:

  <cors enabled="true" failUnlistedOrigins="false">
   <add origin="*" >
    <allowHeaders allowAllRequestedHeaders="true" />
    <allowMethods>
        <add method="GET" />
        <add method="POST" />
        <add method="PUT" />
        <add method="HEAD" />
        <add method="OPTIONS" />
        <add method="DELETE" />
    </allowMethods>
  </add>
  <add origin="https://www.myhost.com" allowCredentials="true" maxAge="120" >
    <allowHeaders allowAllRequestedHeaders="true" />
    <allowMethods>
        <add method="GET" />
        <add method="POST" />
        <add method="PUT" />
        <add method="HEAD" />
        <add method="OPTIONS" />
        <add method="DELETE" />
    </allowMethods>
   </add>
  </cors>
  

  Also specifically tried installing the x64 version of the CORS module after checking if my application in IIS was running in x86 or x64 mode (it is running in x64 mode).

• Rebooted everything.

Nothing seems to have any effect on the error I'm getting. While using fiddler I can see that the response is changing if I add/change headers. Below is a picture of my Fiddler capture when I haven't applied any CORS rules in IIS. I manage to see an admin log-in page, but as soon as I submit my password it gives me the error.

Answer 1

I Have the same problem. One thing I can tell is, that Access-Control-Allow-Origin: * will not work during login. (When credentials are transmitted) I tried changing it to my actual url and port but that does not work either.

Any updates on this?

EDIT: The discussion is now here: https://gitlab.com/foundrynet/foundryvtt/-/issues/5263

Short for IIS: system.webServer.proxy:preserveHostHeaders true Caveat: this has to be set on a server level so it might affect other applications on the same Server

Foundry might change/ improve something. Still in discussion.