In T179553#3728934, @mobrovac wrote:

In your case, that can be achieved by creating an internal end point (in the /sys/ hierarchy) that calls the MW action API for manipulating lists and then declare the auth filter on that route only.

Thanks, that sounds like a good way to handle it.

In T179553#3734935, @Tgr wrote:

In T179553#3728934, @mobrovac wrote:

In your case, that can be achieved by creating an internal end point (in the /sys/ hierarchy) that calls the MW action API for manipulating lists and then declare the auth filter on that route only.

Thanks, that sounds like a good way to handle it.

I actually think this will not work. The auth filter stores the headers that need to be forwarded in the per-request context, so when we're obtaining the list the headers will be stored in the context, and then for all subsequent requests originated by this global external requests the cookies will be in the context. Since we allow the headers to be forwarded to any WMF domain, when requesting summaries cross-domain this will now start forwarding the cookies to all the domains.

For headers other then a cookie is actually a good thing - we're forwarding x-client-ip, user-agent and x-forwarded-for by default (although it might be arguable that x-client-ip is private piece of info and should not be forwarded, since we only allow forwarding to WMF domains it's fine.

If we want special treatment for the cookie header, we need a special same-domain-only cookie parameter, and change the filter to store the root request domain alongside with the cookies in the request context and then check that each of the individual subsequent request domains match it.