[MWS] CORS support

#1

Is CORS support required? What are the use cases where code on one website might legitimately try to access an MWS wiki on behalf of a specific user?

What about the security aspect of this? Obviously we probably have to use oauth so that only code on sites the user grants access to can actually make changes.

Should admin paths ever be allowed or only wiki paths? Is there a legitimate reason for external sites to create recipes and bags? Maybe external tools could create their own bags and recipes but shouldn’t be able to access the ACL for them?

I guess we need to provide a way to add internal tools or plugins for the admin side of things, since there is no way we can allow wikis to access admin paths.

But feature requests for the Admin UI are also welcome. I’m sure there are a lot more features we can easily build into the Admin UI.

1 Like
#2

Hi @Arlen22 yes, I do think configurable CORS support is needed. Part of the picture is that deploying MWS on the public internet is only one of a range of scenarios that we need to support. Some of the others are:

  • Using MWS with a virtual network product like Tailscale where most perimeter security is handled at the network level
  • Using MWS on the same machine as other services talking to one another via localhost. For example, running MWS in the background on your laptop, and connecting to it from browsers and command line scripts
  • Using MWS on a secure corporate network behind a single sign on system that transparently authenticates users and provides a system header with the user name

The threat model in each of these scenarios is very different, and MWS needs to be able to adapt. CORS is a powerful and flexible way for us to deal with certain threats, but we must be careful that it doesn’t become an obstacle for the kind of experimental uses we want to be able to support.

1 Like
#3

Hmmm. I think CORS setting is in the responsibility of the proxy server in front of an MWS plugin.
So I personally would let Nginx or Apache handle CORS

#4

There isn’t any reason why it would have to be in the reverse proxy. It will be a lot easier to configure if it’s part of MWS. And the CORS headers are specific to each individual request, so an individual user could enable CORS requests from a single site for a single bag or recipe they have access to, which greatly helps securing the site overall since you can choose to only grant access to a specific third-party site that you trust.

1 Like