CORS policy not applied

[dimitri-correia]

Description

I attempted to use a Dioxus frontend with Loco as my backend, but the CORS policy I've configured doesn't seem to be working correctly.

When making a fetch request from my frontend at 'http://localhost:8080' to my Loco backend at 'http://localhost:5150/api/register', I receive the following error:

Access to fetch at 'http://localhost:5150/api/register' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Even though I have configured the CORS settings in my configuration file to prevent CORS issues, it appears they are not being applied:

middlewares:
  cors:
    enable: true
    allow_origins:
      - http://localhost:8080
    allow_headers:
      - Content-Type
    allow_methods:
      - POST

When I check the middleware settings with the cargo loco middleware --config command, the output indicates that the configuration should work:

cors {"allow_headers":["Content-Type"],"allow_methods":["POST"],"allow_origins":["http://localhost:8080"],"enable":true,"max_age":null,"vary":["origin","access-control-request-method","access-control-request-headers"]}

Steps to Reproduce

1. Configure the middleware with the following settings:

   middlewares:
     cors:
       enable: true
       allow_origins:
         - http://localhost:8080
       allow_headers:
         - Content-Type
       allow_methods:
         - POST

2. Attempt to make a request from another server running on http://localhost:8080.

Expected Behavior

The server should apply the CORS policy, allowing the request from the specified origin and responding appropriately.

[ndtoan96]

I got the same problem. After playing around, the issue seems to be that loco server only returns Access-Control-Allow-Origin for the POST request, but not for OPTIONS (prelight) request.

[AngelOnFira]

This is similar to #934, I'm going to see if I can make a PR to close both.

[jondot]

seems latest version does reply with correct headers on preflight check:

e553e23

is this still happening in recent version?

[jondot]

per #1009 i've moved this to 0.14.0 for now