Making CORS work

[allavena]

Adding handling of browser "OPTIONS" web call (which is a call made by browsers prior to issuing a POST or DELETE in CORS cases)

[bethesque]

I find these lines a bit hard to reason about. Could we pull the two scenarios out into a separate methods with meaningful names?

[bethesque]

A test can be written in this way: https://github.com/bethesque/pact-mock_service/blob/master/spec/features/mock_one_response_spec.rb

To make it configurable how about:

• add a --cors-enabled option to the mock service command line
• boolean gets passed in as MockService option, and then passed to the handlers
• administration handlers have a cors_enabled method which determines whether or not the handler is a "match"

[allavena]

Leave it with me, I see an easy way to get it all to work.

André Allavena, PhD
CTO
Interactive Gaming Entertainment Pty Ltd

Suite 22, 20 Park Rd
Milton Qld 4064

[allavena]

I've updated my code and the PR.

Functionality is now

• for the systems interactions, CORS headers (and OPTIONS request) are
  always added.
• for user interactions, CORS can be added via a --cors-enabled param
  when starting the mock-service
• existing possibility for users to setup the whole CORS stuff
  themselves is still feasible (but why bother).

Testing needs to happen via browsers and different setup, to make sure I
covered all the cases that need handling. Any takers?

Assuming this works and pending code review, there is now no need to
configure PhantomJS to use a browser with the no-security option.

Thanks
André

André Allavena, PhD
CTO
Interactive Gaming Entertainment Pty Ltd

Suite 22, 20 Park Rd
Milton Qld 4064

[bethesque]

I'm trying to get my head around this scenario.

When the real life code has needed CORS in the past, we have just set up a CORS interaction in the same way that we set up any other interaction. The CORS headers are then written to the pact, and are verified against the provider.

The code you have written is to support the use case where the real life code does not need CORS, but tests need CORS because the testing framework considers the mock service to be on a different "domain", so the tests automatically perform the extra OPTIONS/CORS requests. The CORS headers are NOT written to the pact because there were no expectations set up for them, and are therefore not verified against the provider.

Is this correct?

[bethesque]

Is this needed?

[allavena]

Yes, you are absolutely correct.

Beth wrote on 02/01/15 12:59:

I'm trying to get my head around this scenario.

When the real life code has needed CORS in the past, we have just set
up a CORS interaction in the same way that we set up any other
interaction. The CORS headers are then written to the pact, and are
verified against the provider.

The code you have written is to support the use case where the real
life code does not need CORS, but tests need CORS because the testing
framework considers the mock service to be on a different "domain", so
the tests automatically perform the extra OPTIONS/CORS requests. The
CORS headers are NOT written to the pact because there were no
expectations set up for them, and are therefore not verified against
the provider.

Is this correct?

—
Reply to this email directly or view it on GitHub
#2 (comment).

André Allavena, PhD
CTO
Interactive Gaming Entertainment Pty Ltd

Suite 22, 20 Park Rd
Milton Qld 4064

[bethesque]

Have merged and released v0.2.3.pre.rc2. Will be changing the CLI --cors-enabled to something else, so not doing a proper release yet.