krakend / krakend-cors Goto Github PK

Because of gin-contrib/cors#37 we need to set manually AllowAllOrigins to true if the AllowOrigins is empty or has a wildcard.

I already deploy Kraken D image 0.9.0 (with Docker command) for a while, everything work as well and properly.

But when i try to upgrade Krakend D image to version 1.0.0 with the same configuration and testing. I found CORS problem occurred.

What should i do for workaround or investigate this problem ?

This is my CORS configuration

"github_com/devopsfaith/krakend-cors": {
    "allow_origins": [
        "*"
    ],
    "allow_headers": [
        "Content-Length",
        "Authorization",
        "Content-Type"
    ],
    "expose_headers": [
        "Content-Length"
    ]
}

Update the gin adapter to use rs/cors (like mux) instead of gin-contrib/cors.v1

Will fix behaviours like #3

Is this intentional, or should it refer to github.com/krakendio/krakend-cors/v2

I have a gateway in front of services and I set the gateway CORS policy as described in the documentation.

extra_config:
  github_com/devopsfaith/krakend-cors:
    allow_origins:
    - "......"
    allow_methods:
    - GET
    - POST
    - DELETE
    - OPTIONS
    - HEAD
    allow_headers:
    - Accept
    - Authorization
    - Content-Type
    - Accept-Version
    expose_headers:
    - Link
    allow_credentials: false
    max_age: 5m

Nonetheless, one of the subservices the gateway is in front of also has a CORS middleware and hence, sets the different headers. I would expect the gateway to take precedence and overwrite the headers with its own configuration instead of adding more headers, leading to the following issue: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed

I'm sorry, but this documentation is horrible..

First of all there are many mistakes here:

Configuration Example
"extra_config": {
"github_com/devopsfaith/krakend-cors": {
"allow_origins": [ "http://foobar.com" ],
"allow_methods": [ "POST", "GET"],
"max_age": "12h"
}
}
or leave the defaults (the defaults allows all origins):

"extra_config": {
github_com/devopsfaith/krakend-metrics": {
"allow_origins": []
}
}

krakend metrics?? Missing "?? And also.. this does not work.. what more do i have to do?

I saw gin tests, but it didnt even use extra config from json.. How do i use this middleware????

I tried everything nothing works..

When I use https://github.com/devopsfaith/krakend-config-migrator to migrate my configuration for v2, it changed the github_com/devopsfaith/krakend-cors namespace into security/cors , and this probably broke the CORS functionality because this line https://github.com/devopsfaith/krakend-cors/blob/9e903f85f6681d4651442372baca4c2e4aedf0b7/cors.go#L10 still refers to the old namespace.

Happy to contribute to this, but I wonder if this also happened to other Lura opensource plugins too in the wake of recent v2 release?

This is my configuration.

When using "output_encoding": "no-op", and "encoding": "no-op", it gives me an error like this, it says

but when im not using those output encoding, everything is okay.

Does the no-op encoding adds/removes additional headers?

I'm trying to get CORS to work when withCredentials is true in my XMLHttpRequest, but for any origin. If I use "allow_origins": [] or "allow_origins": ["*"] in my "github_com/devopsfaith/krakend-cors" config, CORS will only work if withCredentials is false.

I can get CORS to work when withCredentials is true only if I specifically whitelist all allowed origins.

The problem is that with "allow_origins": [] or "allow_origins": ["*"], Access-Control-Allow-Origin comes back as "*". I need to have to origin of the request echoed back in the Access-Control-Allow-Origin header instead.

Is there a way to specify that behavior?

        "github_com/devopsfaith/krakend-cors": {
            "allow_origins": ["http://localhost:8080"], // Or [] or ["*"] - which only changes the limitation or error I get
            "allow_headers": ["Origin", "Authorization", "Content-Type", "Accep\
t", "X-Auth-Token"],
            "expose_headers": ["Content-Type", "Content-Length"],
            "allow_credentials": true
        }

The middleware generates preflight responses to OPTIONS requests for any path (regardless of that path being configured).
This seems to be due to the fact that the middleware is not considering the endpoint configuration and is reacting to requests prior to the router.

This doesn't seem correct to me since it suggests to clients that they can expect responses to certain paths where they wouldn't get any.

Since krakend doesn't support other types of OPTIONS requests, this middleware could wrap the CORS handler once more and only forward OPTIONS requests for paths that are configured.
In the future, supported methods could also be identified this way and CORS settings could be made endpoint-specific.

First of all, I am not sure if this is actually an issue with krakend but even if it isn't, then this might be something that is missing from the docs.

I have an SPA that should access a microservice via krakend with the help of CORS. I followed the guide in https://www.krakend.io/docs/service-settings/cors/ and set up CORS like this:

    "github_com/devopsfaith/krakend-cors": {
        "allow_origins": [
            "http://localhost:4200/",
            "https://my-spa-app.mydomain.com/",
            "https://my-spa-app.testing.mydomain.com/",
            "https://my-spa-app.staging.mydomain.com/"
        ],
        "expose_headers": [
            "Content-Length",
            "Content-Type"
        ],
        "max_age": "5m",
        "allow_headers": [
            "Accept-Language",
            "Authorization"
        ],
        "allow_credentials": true
    }

I tried different variations and whatever I try, the gateway never responds with correct CORS response headers (Access-Control-Allow-Origin etc.). I tested this via the mentioned SPA as well as via curl.

This might be related to krakend/krakend-ce#137.