CORS Strangeness

Questions
1

Caveat: When I tried to post this I got a message that new users can only put five links in a post. Since my post has many http:// or https:// bits and pieces, I converted them to wtf:// and wtfs://

I have an Angular 6 app “MyApp” that uses okta (local login widget). In development mode, I run it at localhost:4201, in production mode, I run it at localhost/MyApp (served by apache from htdocs/MyApp). All good.

I created an application at Okta to authenticate. and created the appropriate login redirect URIs:
wtf://localhost:4201/implicit/callback and
wtf://localhost/MyApp/implicit callback Again, so far so good.

I need to configure CORS for my app on Okta by API=>Trusted Origins=>Add Origin for both
localhost:4201 AND localhost. This is pretty much what the documentation requires.

When I run my production version, everything works fine.
When I run my development version, things break.

The details are below but the relevant bits are as follows: the widget makes this OPTIONS request:
wtfs://dev-574317.oktapreview.com/oauth2/default/v1/keys, In the Response, Access-Control-Allow-Origin is wtf://localhost:4201 => this is fine because the request header contains Origin: wtf://localhost:4201.

Shortly thereafter we make the GET request
wtf://dev-574317.oktapreview.com/oauth2/default/v1/keys, This time, in the Response, Access-Control-Allow-Origin is wtf://localhost and this is bad because the request header contains “Origin: wtf://localhost:4201”, which does not match.

Why did the production version work? Because the Access-Control-Allow-Origin in the response is wtf://localhost which is in fact the Origin of the request, so fine.

The totally strange thing is that I cloned MyApp on to another computer, rebuilt and deployed it in exactly the same way. This time I got exactly the opposite behavior. That is, the dev version worked fine and the production version failed. As you can probably guess, in both cases on machine 2, the Access-Control-Allow-Origin in the response is wtf://localhost:4201, which is just fine for the dev version, but wrong for the production version!

I am working with Angular 6 (6.1.7) okta-angular 1.0.3 and okta-signin-widget 2.13.0 (all up to date as of 2018-09-14).

Any theories as to what I might be doing wrong?

Here is the detail from the GET request from the dev version on the first machine.

  1. Request URL: wtfs://dev-574317.oktapreview.com/oauth2/default/v1/keys

  2. Request Method:

GET

  1. Status Code:

200 OK (from disk cache)

  1. Remote Address:

35.172.155.72:443

  1. Referrer Policy:

no-referrer-when-downgrade

  1. Response Headers

  2. Access-Control-Allow-Credentials:

true

  1. Access-Control-Allow-Headers:

Content-Type

  1. Access-Control-Allow-Origin:

wtf://localhost <======= ???

  1. Cache-Control:

max-age=4708337, must-revalidate

  1. Content-Type:

application/json;charset=UTF-8

  1. Expires:

Tue, 06 Nov 2018 05:56:12 GMT

  1. Request Headers

  2. Provisional headers are shown

  3. Accept:

application/json

  1. Content-Type:

application/json

  1. DNT:

1

  1. Origin:

wtf://localhost:4201 <====== the origin of the request.

  1. Referer:

wtf://localhost:4201/implicit/callback

  1. User-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

  1. X-Okta-User-Agent-Extended:

@okta/okta-angular/1.0.3 okta-auth-js-2.0.1

  1. X-Requested-With:

XMLHttpRequest