Enable CORS headers for resolver

[datadavev]

CORS headers in a resolver introspection (infection) response can allow browser clients to load the response in a page hosted elsewhere.

A new feature of the ARKs environment is the ability to chain inflection responses to present information about the resolution chain to web browser users.

Since EZID acts as an intermediary resolver (e.g. between arks.org and a resource provider), it is expected that the EZID service should be able to provide the expected resolver response.

CORS headers can be added using the django-cors-headers middleware.

The configuration should be something like:

INSTALLED_APPS = [
    ...,
    "corsheaders",
    ...,
]

# important - CORS should be before CommonMiddleware
MIDDLEWARE = [
    "corsheaders.middleware.CorsMiddleware",
    "django.middleware.common.CommonMiddleware",
    ...,
]

CORS_ALLOWED_ORIGINS = ['*', ]

# Optional - restrict CORS to only the inflection requests
CORS_URLS_REGEX = r"^(\/.info/ark:.*)|(/ark:.*\?(info)?)$"

CORS_ALLOW_METHODS = (
    "GET",
    "OPTIONS",
    "POST",
]

[adambuttrick]

Couple comments on initial review:

• Need to understand to what extent this broadens our attack surface if misconfigured. EZID already has a fairly complicated config, issues with malicious traffic, and CDL apps have come under attack this year, so I'm not super keen to open up another avenue for this that we have to constantly have to account for.
• What are the potential overall impacts on server load (vs. existing resolution) and how do we adequately estimate, monitor and manage?
• Is the overall added complexity worth the value? From my perspective, I think it's fine if we support a basic subset of ARK functionality vs. every aspect.

[datadavev]

• With the provided configuration, the CORS headers would only be provided for inflection responses. In the worst case scenario of completely open CORS, web browser client could fetch content programmatically and use that content in a page. It's not clear what resources served by EZID may allow unauthorized access or inappropriate reuse of content on another site. A couple remedies:

  • Incorrect configuration is fairly straightforward to test (which could be added to deployment).
  • POST can be dropped from the allowed methods
  • Alternatively, instead of using the middleware, add the CORS headers directly to the response for the introspection method. This would limit support to specifically this method with no possibility of misconfiguration, though is generally not the preferred path for support in Django apps (since it bypasses central configuration).

• Impact on server load would be minimal. There should be no measurable impact beyond the existing identifier resolution support.

• Technically, the added complexity is providing a couple of headers in a response that already exists, increasing the value to a community of users.

[jsjiang]

Develop a test plan