Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure CORS headers globally #46

Closed
Angelmmiguel opened this issue Nov 28, 2022 · 5 comments · Fixed by #202
Closed

Configure CORS headers globally #46

Angelmmiguel opened this issue Nov 28, 2022 · 5 comments · Fixed by #202
Assignees
Labels
🚀 enhancement New feature or request 👋 good first issue Good for newcomers

Comments

@Angelmmiguel
Copy link
Contributor

Cross-Origin Resource Sharing (CORS) is a series of security policies to avoid a web browser fetching resources from a different domain. By default, CORS will block any request that a website makes to a different domain.

However, servers can set the CORS HTTP headers to indicate the browser they are fine to process the request. CORS can be configured using several headers. Some of them provides a global policy while others helps to add granularity to the requests:

  • Access-Control-Allow-Origin: http://example.com
  • Access-Control-Allow-Methods: POST, GET, OPTIONS
  • Access-Control-Allow-Headers: Content-Type
  • Access-Control-Max-Age: 10000

I recommend you to check the Cross-Origin Resource Sharing (CORS) documentation about the different headers and behaviors.

On wws, we plan to provide two different approaches to set the CORS policy:

  • With a global --cors option. This option will configure the Access-Control-Allow-Origin header. It will be applied to all requests
  • Every worker can set its own headers. In this way, we allow workers to customize the response. This approach has preference to the --cors option. If both are set, the worker value will be sent
@Angelmmiguel
Copy link
Contributor Author

I've been researching about this topic. Ideally, we should implement it using an Actix middleware. However, I will delay this implementation because this is already configurable by the workers.

@Angelmmiguel Angelmmiguel added the 👋 good first issue Good for newcomers label Apr 24, 2023
@Narayanbhat166
Copy link
Contributor

Hi @Angelmmiguel. I can work on this issue, can you please assign it to me?

@Angelmmiguel
Copy link
Contributor Author

That's amazing @Narayanbhat166. I assigned the issue to you 😄. Feel free to ask any question or suggest different approaches to complete this issue.

@Narayanbhat166
Copy link
Contributor

Hi @Angelmmiguel
I'm trying out running the workers locally in rust language. We can set the custom cors headers in workers, it would look something like this i suppose

#[worker]
fn reply(req: Request<String>) -> Result<Response<Content>> {
  Ok(http::Response::builder()
      .status(200)
      .header("Access-Control-Allow-Origin", "*")
      .header("x-generated-by", "wasm-workers-server")
      .body(String::from("Hello wasm!").into())?)
}

With a global --cors option. This option will configure the Access-Control-Allow-Origin header. It will be applied to all requests

What value would this key have, is it like a boolean flag, which would set minimum permissive headers required to enable cors?

@Angelmmiguel
Copy link
Contributor Author

Hello @Narayanbhat166!

You are totally right about adding CORS headers to the workers. This is posible in all languages and it's the current way to do it. However, there are certain apps that exposes all the endpoints and including the CORS headers in all workers could be tedious.

To simplify it, the --cors option will receive a String. It will use this string as the Access-Control-Allow-Origin value for all workers that don't include that specific CORS header. If the worker returns a response that includes this header, it will be respected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 enhancement New feature or request 👋 good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants