SITES-8366 - [wknd.site] Update CORS configuration to support multiple origins

[raducotescu]

Description

This PR moves all publish-tier CORS configuration in the dispatcher, since that's the only layer that can correctly apply Vary based caching.

How Has This Been Tested?

The dispatcher change configuration has been tested using the Dispatcher SDK.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed (there are no specific dispatcher/CORS tests)

[davidjgonzalez]

Thanks Radu!

Few quick Qs.

1. How does this impact local development (AEM SDK/6.5) .. i assume this requires local AEM Headless development to run the Dispatch Tools?
   • Could we leave in the CORS OSGi configuration for local development on Publish? Is there a clean way to do that?
2. Historically, in the OSGI configuration, we'd set allow URL path patterns for a CORS config; it appears that the dispatcher approach allows a known origin/pattern to CORS any path -- is this is security issue? We configured the OSGi config on principle of least privilege. Just want to very that this is not important (or that im missing the path restrictions somewhere)

[raducotescu]

For 1. I guess we could add a publish config that's only active on development environments - we should probably add a new dev runmode for that.

For 2. we could wrap these configs inside a Location or LocationMatch directive.

[davidjgonzalez]

@raducotescu

1. How would we distinguish between AEM SDK dev and AEM as a Cloud service dev? Would a OSGi config on AEM as a Cloud Service Dev be problematic? Or will the httpd config overrwrite any headers that might generate?
2. IMO, Less is more. If its OK not to add this extra concern, that's simpler from a user POV. If we need to add it from a security POV, then i guess we have to. I was just raising the question to make sure we didn't miss something; ill leave it to yall to determine if its best practice/required.

[davidjgonzalez]

Converting to Draft as this depends on AEM CS release (which contains updates to Dispatcher).

[jasghar]

This rewrite rule will not work in its current form/position, as conf.d/rewrites/default_rewrite.rules contains rewrite at as a last rule with flag [PT], and that implicitly implies L flag. See PT section on https://httpd.apache.org/docs/2.4/rewrite/flags.html

[raducotescu]

Jabran, have you tested the PR?

[jasghar]

Yes, tested this using a local author-publish-dispatcher setup.