New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid 'Access-Control-Allow-Origin' header value #541

Open
stormit-vn opened this Issue Sep 14, 2018 · 28 comments

Comments

Projects
None yet
@stormit-vn
Copy link

stormit-vn commented Sep 14, 2018

I'm submitting a

  • [x ] bug report
  • feature request

Background info

I am usinng this widget to sign in to Okta. We use the same Okta account for both development and testing environment. The development environment is running at http://localhost:3000 and testing is running at https://example.com.

The sigin feature is working properly in my local environment, but when we try to login to our test environment we are getting below error

implicit/callback:1 Failed to load https://oktadomain.oktapreview.com/oauth2/default/v1/keys: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:3000' that is not equal to the supplied origin. Origin 'https://example.com' is therefore not allowed access. polyfills.74f394a5c1…5769e125.chunk.js:1 Uncaught Error: Uncaught (in promise): AuthApiError Error at Object.YhKr (main.8683cd6….chunk.js:1)

If we clean all cache, then we will able to login to http://example.com, but after that we will not able to login to our http://localhost:3000

Expected behavior

We should able to signin to both environment

What went wrong?

See above description. Note, it will be no issue when we use Okta Sign-In widget 2.11.0 and Okta angular 1.0.1.

Steps to reproduce

See above description

Your environment

  • Okta Sign-In Widget Version: 2.13.0
  • @okta/okta-angular: 1.0.3
  • Browser: Chrome latest version
  • OS: Mac OS
  • Language: JavaScript
@stormit-vn

This comment has been minimized.

Copy link

stormit-vn commented Sep 14, 2018

For more details, I worked with @okta/okta-angular: 1.0.1

@jmelberg-okta

This comment has been minimized.

Copy link
Member

jmelberg-okta commented Sep 29, 2018

Hi @stormit-vn -

Thanks for the report! We're working with our API team to investigate this further. We'll keep this issue updated as information becomes available.

Thanks!

@fabiangarga

This comment has been minimized.

Copy link

fabiangarga commented Oct 1, 2018

Same issue is happening with okta-angular v1.04.
I guess this is related to the Okta API response, and not the plugins that handle the integration, and more specific with the cache of the response.

If we inspect the response headers that the API from Okta is returning it doesn't includes the 'vary' response header that indicate the browsers the responses can differ based on the value of the origin that generated the request. Also on the header the Access-Control-Allow-Origin url is set to the previous one.

Any updates on this fix?

@Wilson-Hung-DrumG

This comment has been minimized.

Copy link

Wilson-Hung-DrumG commented Oct 2, 2018

Same issue here

@awumsuri

This comment has been minimized.

Copy link

awumsuri commented Oct 2, 2018

Same issue.

@roski

This comment has been minimized.

Copy link

roski commented Oct 5, 2018

same

@ajheunis

This comment has been minimized.

Copy link

ajheunis commented Oct 10, 2018

Seemingly same issue, but with @okta/okta-react: 1.1.1.

@haishengwu-okta

This comment has been minimized.

Copy link
Contributor

haishengwu-okta commented Oct 12, 2018

Did you enable CORS for both url?

@Wilson-Hung-DrumG

This comment has been minimized.

Copy link

Wilson-Hung-DrumG commented Oct 12, 2018

There is a another similar question, where the poster pinned @okta/okta-react to 1.0.1 (we had it as ^1.0.3). This fixed our issue, i.e., setting @okta/okta-react: 1.0.1

@bartimaeus

This comment has been minimized.

Copy link

bartimaeus commented Oct 30, 2018

@stormit-vn what version of okta-auth-js are you using? I ran into a similar issue and discovered that I had to lock my okta-auth-js to 1.17.0 to work with okta-signin-widget. The later versions of okta-react and okta-angular use the newer okta-auth-js:^2.0.0 which does not work with okta-signin-widget yet.

"@okta/okta-auth-js": "^1.17.0",
"@okta/okta-react": "^1.0.2",
"@okta/okta-signin-widget": "^2.13.0",
@jmelberg-okta

This comment has been minimized.

Copy link
Member

jmelberg-okta commented Oct 30, 2018

Hi all -

Our API team is working on addressing this issue this month. We're tracking the status of the work internally, so I'll update this issue as status updates become available.

@paulux84

This comment has been minimized.

Copy link

paulux84 commented Nov 18, 2018

Hi all, any update on this bug?
I think that for an authorization service that declare to do sso this is a really critical bug.
For us this bug not allow to use sso between 2 application linked to the same organization...and, most important, not allow to use one random application....

@jmelberg-okta

This comment has been minimized.

Copy link
Member

jmelberg-okta commented Nov 19, 2018

@paulux84 & others,

Our API teams are actively working on this issue. Once the work is completed, I'll be informed when this fix hits production.

Thanks for your patience!

@jmelberg-okta jmelberg-okta added In Progress and removed Triaged labels Nov 19, 2018

@johnnathaniel

This comment has been minimized.

Copy link

johnnathaniel commented Dec 5, 2018

Thank you @jmelberg-okta for the response on the issue. There is another issue, okta/okta-oidc-js#337 that I suspect is related. I wanted to call it out here, in case that is helpful.

@jmelberg-okta

This comment has been minimized.

Copy link
Member

jmelberg-okta commented Dec 12, 2018

Hi all,

Wanted to quickly chime in with an update.

Our API teams have merged a fix for this issue, and have rolled it out to preview organizations (*.oktapreview.com) this week. Next week, it'll be available for all Okta orgs.

Thanks for your patience - and please keep us updated if issues persist.

Edit (12/14)

Unfortunately, there was an issue related to this fix for preview organizations. More details on the issue are available in this Trust post.

We're working with our API teams this afternoon to resolve this bug ASAP.

@dotnetcoder01

This comment has been minimized.

Copy link

dotnetcoder01 commented Dec 14, 2018

I am in an oktapreview domain and I am still getting this issue. I have multiple apps in my okta instance each with their own client ID. I modified the names of the urls for this post.

Access to XMLHttpRequest at 'https://dev-XXXXXX.oktapreview.com/oauth2/default/v1/keys' from origin 'https://project-val.XXXXXX.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://project-dev.XXXXXX.com' that is not equal to the supplied origin.

@paulux84

This comment has been minimized.

Copy link

paulux84 commented Dec 14, 2018

same for me

@Saithorat

This comment has been minimized.

Copy link

Saithorat commented Dec 18, 2018

still an issue, any updates ?

@owenmecham

This comment has been minimized.

Copy link

owenmecham commented Dec 18, 2018

The trust incident is listed as resolved. Since this issue is still open, are you still working on finding a solution?

@owenmecham

This comment has been minimized.

Copy link

owenmecham commented Dec 19, 2018

Currently, the impact to developers or production users that access both our beta and prod environments is that in order to switch from one site to another, the user has to manually clear their browsing data. This is a big deal for us. Any eta on a fix or a status update would be greatly appreciated.

@reste85

This comment has been minimized.

Copy link

reste85 commented Dec 28, 2018

Same issue here. We have 2 SPA and we're using the same authorization server for both. In particular we have 3 authorization servers, one for each environment. When i log into an SPA, i can't login into the second one. I've already opened cases on okta forum, i think this issue is completely related to the api part (seems like the browser is caching the "keys" request with the Allow-Control-Origin header value).
The only workaround that works is to use separate authorization servers for each SPA and for each environment, so if you have 3 environments and 2 SPA --> 6 authorization servers (that's really annoying).

Any news on that?
Thank you!

@AmihaySchwarz

This comment has been minimized.

Copy link

AmihaySchwarz commented Jan 2, 2019

@jmelberg-okta , according to this the matter should have resolved but we still have this issue, I see that others also have this issue.

Can u please update us?

@nbarbettini

This comment has been minimized.

Copy link
Contributor

nbarbettini commented Jan 3, 2019

Sorry for the delayed response, and thanks for all your patience.

Since this issue is still open, are you still working on finding a solution?

Yes, we are close to a fix for this problem ("The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin"). We'll update and close this issue when it is fully resolved.

@chrisipeters

This comment has been minimized.

Copy link

chrisipeters commented Jan 4, 2019

I'm on a preview account, seeing the CORS issue as reported at:
https://devforum.okta.com/t/cors-blocked-access-control-allow-origin/3807

is this the same issue being worked on here?

@nbarbettini

This comment has been minimized.

Copy link
Contributor

nbarbettini commented Jan 7, 2019

@chrisipeters Yes, looks like the same issue. We are releasing a fix soon.

@jeremypepper

This comment has been minimized.

Copy link

jeremypepper commented Jan 9, 2019

@nbarbettini Do you have a specific date on when we can expect a fix?
Any idea why opening your chrome debugger and hitting "Disable cache" is a workaround for this issue (at least for devs)?
Is there any workaround we can do until this is fixed for real?

@jeremypepper

This comment has been minimized.

Copy link

jeremypepper commented Jan 9, 2019

Oh i see. It's the /oauth2/v1/keys endpoint that gets cached on disk with the old origin. Unfortunately it's response header has:
Cache-Control: max-age=2178861, must-revalidate

Which comes out to 25 days. So even after this fix is done on your side, there may be a gap of 25 days for this to fully be resolved on all clients right?

@jeremypepper

This comment has been minimized.

Copy link

jeremypepper commented Jan 10, 2019

I added a pull request for a workaround I made that seems to work if anyone wants it:
okta/okta-auth-js#186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment