8

I'm sorry if this is a very ignorant question but is it possible for Ambassador to truly handle CORS headers and pre-flight OPTION responses?

The docs (https://www.getambassador.io/reference/cors) seem kind of ambiguous to me, if there are just hooks to prevent requests, or if it can truly respond on behalf of the services.

Here's my situation: I've got Ambassador in front of all the http requests to some microservices. For [reasons] we now need a separate domain to make requests into the same Ambassador.

I have an AuthService configured, and according to the docs "When you use external authorization, each incoming request is authenticated before routing to its destination, including pre-flight OPTIONS requests." Which makes perfect sense, and that's what I'm seeing. My AuthService is configured to allow things correctly and that seems to be working. The AuthService responds with the appropriate headers, but Ambassador seems to just ignore that and only cares if the AuthService responds with a 200 or not. (Which seems totally reasonable.)

I have this annotated on my ambassador module:

getambassador.io/config: |
  --- 
  apiVersion: ambassador/v1
  kind:  Module
  name:  ambassador
  config:
    service_port: 8080
    cors:
      origins: [my domain here]
      credentials: true

And that doesn't seem to do what I'd expect, which is handle the CORS headers and pre-flight... instead it forwards it on to the service to handle all the CORS stuff.

xbakesx
  • 13,202
  • 6
  • 48
  • 76

1 Answers1

3

Turns out, by specifying headers: "Content-Type" in the cors configuration, things just started to work. Apparently that's not as optional as I thought.

So this is now my module:

getambassador.io/config: |
--- 
apiVersion: ambassador/v1
kind:  Module
name:  ambassador
config:
  service_port: 8080
  cors:
    origins: [my domain here]
    headers: "Content-Type"
    credentials: true
xbakesx
  • 13,202
  • 6
  • 48
  • 76
  • As an aside, another important bit to get the whole thing working: we needed to add a `allow_authorization_header` in our AuthService annotation to allow us to pass through headers to the service handling the request. That won't be necessary for everyone, but if you are expecting your AuthService to add on additional headers, you'll need this. – xbakesx Jun 04 '19 at 21:08
  • I'm currently also trying to get this working. Can you briefly explain the process you currently implemented? So what I am doing is the following: In my Auth Service, I responde with the CORS headers and when I test CORS against the authentication all works. I have also defined the form attributes in the ambassador module but all request to my micro services will not include the allow origin header in the response to the OPTIONS request. I don't want my upstream micro services to handle any cors if possible – Maurice Dec 24 '19 at 13:48
  • I'm not 100% sure I'm following you, but you _should_ definitely be able to have your microservices be oblivious to the CORS that are happening. Your auth service does have to handle CORS, in that it has to return a 200 but its response headers don't matter. You need an Ambassador annotation on it that specifies the allowed origins, methods and a header of content type. The example in the answer is all (I think) you need. – xbakesx Dec 24 '19 at 19:43
  • Thanks for taking the time! So you are saying I need to answer all OPTIONS requests with a 200 response in my Auth Service? Because currently I'm answering them with a 204.. – Maurice Dec 25 '19 at 11:25
  • I think a 204 should be fine... You could try switching it and see what happens but I think anything 2XX is good enough for Ambassador to think it passed the AuthService check. What does the client get back from the OPTIONS request? – xbakesx Dec 26 '19 at 23:54