• Header provider for Allow-Credentials
• If Allow-Credentials is true; a wildcard is now used to dynamically echo the request origin in the allowed-origin header
• Unit test and documentation updates to include details of the Allow-Credentials functionality

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/graycoreio/magento2-cors/blob/master/CONTRIBUTING.md#commit
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: #65

What is the new behavior?

The layer in which we compute whether or not an incoming preflight request receives CORS headers has changed. Previously, we leveraged a plugin around the relevant native Magento 2 Controller (webapi_rest/graphql) and as a result, we incurred significant overhead from Magento code when computing CORS headers.

In the new code we no longer incur this overhead by adding a plugin around application launch and creating our own custom controller. It is very possible that we broke expectations of anything that plugs-in around this plugin or adds additional CORS headers other than our own.

For 99.99% of GraphQl/Rest API deployments, the API is used sessionlessly. As such, we can take the opportunity to improve performance for the majority at the expense of the minority. If this breaks your codebase, please submit an issue and we will see what can be done to remedy your specific use-case.

In theory, most dependents simply need to upgrade and there are no breaking changes.

However, if you were expecting to use the native GraphQl/REST controller when computing CORS headers (and everything else that entails - like having a Magento session, for example) that guarantee is no-longer provided.

Does this PR introduce a breaking change?

[x] Yes
[ ] No

Other information

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/graycoreio/magento2-cors/blob/master/CONTRIBUTING.md#commit
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

We download deps every time we build.

Fixes: N/A

What is the new behavior?

We download deps IFF the lock file changes.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Hey team; thanks for providing this - it's going to be a big help for our Headless efforts.

One problem I have though is that I use a GraphQL Chrome extension (Altair) for my testing, which sends an Origin Request header with a chrome-extension:// scheme. The Zend framework fails to validate that as part of the getHeader() call, and throws an error.

I've proposed that we catch this specific exception and treat it the same way as a request without an Origin header.

Shout out if you have any thoughts or concerns.

We should add CI to ensure consistent build quality. Preferably, we should use Azure DevOps.

Currently, while tests are written, they are not run in CI.

We need to run both the integration and unit tests, and these two processes can be done in parallel.

See https://github.com/magento/adobe-stock-integration/blob/1.1-develop/.travis.yml as an example of a working Travis sample. We would need to translate this over to Azure Devops and run against PR builds and master.

• [x] Linting (static) (#16 and #17)
• [x] Unit (#18 & #19)
• [ ] Integration
• [ ] Api-Functional

Hi, I was using the SplashLabs CORS module, but ran into a blocker with it when trying to POST to the guest-cart. I disabled it and installed your module, added the configs etc etc.

Now I can't even see the initial API GET product request work anymore. We are using Magento 2.3.3 (commerce) on Magento Cloud - working on Integration instance.

In the exception I see: [2021-03-09 05:45:50] report.CRITICAL: Request method is invalid. {"report_id":"076a55918ca8c940a9c25f3cc440482a965e1d6ed7b7e24d647dbc8906e6b43d","exception":"[object] (Magento\Framework\Exception\InputException(code: 0): Request method is invalid. at /app/vendor/magento/framework/Webapi/Rest/Request.php:180)"} []

Which closely matched an access log: 193.114.101.142 - - [09/Mar/2021:05:45:50 +0000] "OPTIONS /rest/V1/products?&searchCriteria[filter_groups][0][filters][0][field]=entity_id&searchCriteria[filter_groups][0][filters][0][value]=3019&searchCriteria[filter_groups][0][filters][0][condition_type]=eq HTTP/1.1" 500 501 "https://crv-test5.racingjd.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36"

I notice that in your module your not overriding the ->getHttpMethod() which by default does not recognise OPTIONS method (which is inherently the Magento shortcoming)

Did we miss something in the setup? The module was active, and cached were flushed after the deployment.. I even tried a few different option variations..

Thnx...

:bulb: Feature request

Add Magento 2.4 Support

The Desired Behavior

Installation of this module works with Magento 2.4.

Your Use Case

As a developer I want to use this module in Magento 2.4.

I tried to install this module in the following environment:

magento2-cors version: 1.3.0
Magento version: 2.4.0 
PHP Version version: 7.4.9

and got the following error message:

Problem 1
    - magento/framework 102.0.0 requires php ~7.1.3||~7.2.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.1 requires php ~7.1.3||~7.2.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.2 requires php ~7.1.3||~7.2.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.3 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.2-p2 requires php ~7.1.3||~7.2.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.4 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.3-p1 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.5 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.4-p2 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - magento/framework 102.0.5-p2 requires php ~7.1.3||~7.2.0||~7.3.0 -> your PHP version (7.4.9) does not satisfy that requirement.
    - graycore/magento2-cors 1.3.0 requires magento/framework ^102.0 -> satisfiable by magento/framework[102.0.5-p2, 102.0.4-p2, 102.0.5, 102.0.3-p1, 102.0.4, 102.0.2-p2, 102.0.3, 102.0.2, 102.0.1, 102.0.0].
    - Installation request for graycore/magento2-cors ^1.3 -> satisfiable by graycore/magento2-cors[1.3.0].

PHP8.1 throws a warning when $string is null, if it is any form of empty we can immediately return with an empty array.

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] The commit message follows our guidelines: https://github.com/graycoreio/magento2-cors/blob/master/CONTRIBUTING.md#commit
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

PHP8.1 throws a warning when $string is null, if it is any form of empty we can immediately return with an empty array.

Fixes: N/A

What is the new behavior?

The module short circuits with an empty array if $string is empty

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] The commit message follows our guidelines: https://github.com/graycoreio/magento2-cors/blob/master/CONTRIBUTING.md#commit
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

Bumps ini from 1.3.5 to 1.3.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps standard-version from 6.0.1 to 8.0.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.