Reponding CORS info to OPTIONS request

[spectroman]

When trying to rebuild a backend from ruby to golang, we have built a new server using Echo.

Surprisingly, now that I have built a lot of code and am able to receive requests from the frontend, which is a Angular application, nothing works, mostly because I could not find a way to respond OPTIONS request with CORS headers.

Angular will use as pre-flight for any request a OPTIONS call beforehand to check CORS config... it is not something that we can change because it comes from the inner workings of Angular.

What am I missing? How can I make Echo reply to OPTIONS with CORS headers?

[aldas]

Maybe https://echo.labstack.com/middleware/cors/ This is how CORS middleware handles OPTIONS requests

echo/middleware/cors.go

Line 120 in 6df1c35

// Preflight request is an OPTIONS request, using three HTTP request headers: Access-Control-Request-Method,

[spectroman]

I just did a test here and for angular to work, I must have all of those:

< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE

Otherwise he doesn't even talk to the back end. Obviously in place of wildcards I could have proper domain names, but its irrelevant for this discussion.

The question is, how can I make Echo reply this when OPTIONS is requested?

[aldas]

It is not irrelevant. Origin is important part of preflight request (options).

func main() {
	e := echo.New()
	
	e.Use(middleware.Logger())
	e.Use(middleware.Recover())
	e.Use(middleware.CORS())

	e.GET("/", func(c echo.Context) error {
		return c.JSON(http.StatusOK, map[string]string{"msg": "OK"})
	})

	if err := e.Start(":8080"); err != http.ErrServerClosed {
		log.Fatal(err)
	}
}

When your browser sees that (for example POST) request goes to server that is not origin of your Angular app it will do the OPTIONS request with these headers. As that request is OPTIONS + other CORS headers the CORS middleware will be triggered and you will see response like that.

x@x:~/code$ curl -v -X OPTIONS localhost:8080/ -H 'Access-Control-Request-Method: GET' -H 'Access-Control-Request-Headers: Content-Type, Accept' -H 'Origin: http://localhost:8080'
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> OPTIONS / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.74.0
> Accept: */*
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: Content-Type, Accept
> Origin: http://localhost:8080
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 204 No Content
< Access-Control-Allow-Headers: Content-Type, Accept
< Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
< Access-Control-Allow-Origin: *
< Allow: OPTIONS, GET
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Date: Thu, 12 May 2022 17:44:54 GMT
< 
* Connection #0 to host localhost left intact

I really do no understand your problem (I'm literally running Angular app here and see how it behaves with Echo). Please open your browser network tab and copy OPTIONS request/response from there.

Are you (your browser) doing OPTIONS request from the same domain/origin?

[spectroman]

hummm your curl test have worked here as well...

> OPTIONS / HTTP/2
> Host: localhost:2207
> user-agent: curl/7.83.1
> accept: */*
> access-control-request-method: GET
> access-control-request-headers: Content-Type, Accept
> origin: https://localhost:2207
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 204 
< access-control-allow-headers: *
< access-control-allow-methods: GET,OPTIONS,POST,DELETE
< access-control-allow-origin: *
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< date: Thu, 12 May 2022 19:02:14 GMT
< 
* Connection #0 to host localhost left intact

Then I double checked and on the developer tools, he also started providing the proper response...
For some awkward reason, which I still need to identify, there is some piece of information, looks like the JWT token, when he is in a "wrong state" the application evokes a CORS error:

Access to XMLHttpRequest at 'https://localhost:2207/' from origin 'http://localhost:4200' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

So if I just go and clear all the cookies and storage, the CORS goes away... and he is able to function normally.. that one is a real thinker :-/

I think I will be able to figure it out from here on... thanks for your time man, it helped a lot , it was really appreciated!

[saheljalal]

I don't know if related but I'm running into similar CORS issues from a React app using fetch and Chrome shows:

Access to fetch at '<domain1>' from origin '<domain2>' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

My configuration is set with the following and have no clue how to fix:

app.Use(middleware.CORSWithConfig(middleware.CORSConfig{
		AllowOrigins:     []string{"<domain2>", ...},
		AllowHeaders:     []string{"*"},
		AllowMethods:     []string{"GET", "HEAD", "PUT", "PATCH", "POST", "DELETE", "OPTIONS"},
		AllowCredentials: true,
	}))

Works fine locally when using "*" for origins in development but not with actual domains.

[saheljalal]

💀 Crap, I think my problem is coming from Nginx: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors