Skip to content
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

Add CORS handling for web-components #2006

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

danpat
Copy link

@danpat danpat commented Jan 28, 2022

I found myself using elements to create an online schema viewer that lives behind an authenticated proxy. Things mostly worked, except for parts of our schema that were remote $ref references in the primary schema document. When elements attempted to resolve them in our environment, the browser console log exploded with CORS-related errors.

After a bunch of digging, it turned out that by default, elements was leaving @stoplight/json-schema-ref-parser use it's default HTTP resolver settings, which has has credentials: 'omit' in the options passed to fetch(). This fails when CORS headers are required.

This PR doesn't change the default, but exposes a new option to the elements-api tag called withCredentials that is passed through to @stoplight/json-schema-ref-parser, allowing user control over whether CORS handling is enabled or not.

I'm not a front-end person by default, so apologies if the style of this PR is out of line, or if I've missed something fundamental. These changes appear to be functioning as intendent in the environment where I have them deployed.

@danpat danpat requested review from a team and mmiask January 28, 2022 17:02
@@ -1,2 +1,2 @@
// auto-updated during build
export const appVersion = '1.6.7';
export const appVersion = '1.6.9';
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this isn't a change I made....

Copy link

@gagarwa gagarwa Mar 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be automated...

const commonBundleOptions: $RefParser.Options = {
continueOnError: true,
resolve: {
http: <$RefParser.HTTPResolverOptions>{ withCredentials },
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the key needed change to modify how json-schema-ref-parser fetches remote refs.

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements ready!

🔨 Explore the source changes: 2eead18

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements/deploys/61f42191205c000008081f10

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements.netlify.app

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements-demo ready!

🔨 Explore the source changes: 2eead18

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements-demo/deploys/61f42191ec359b000839f5ba

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements-demo.netlify.app/

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements-dev-portal-storybook ready!

🔨 Explore the source changes: 2eead18

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements-dev-portal-storybook/deploys/61f42191a08c73000781cb0e

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements-dev-portal-storybook.netlify.app

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements ready!

🔨 Explore the source changes: f76c429

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements/deploys/622a339bfc4f18000be29d62

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements.netlify.app

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements-demo ready!

🔨 Explore the source changes: f76c429

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements-demo/deploys/622a339bdc55b00009ae93b9

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements-demo.netlify.app/

@netlify
Copy link

netlify bot commented Jan 28, 2022

✔️ Deploy Preview for stoplight-elements-dev-portal-storybook ready!

🔨 Explore the source changes: f76c429

🔍 Inspect the deploy log: https://app.netlify.com/sites/stoplight-elements-dev-portal-storybook/deploys/622a339bdfaa3b0008f84f23

😎 Browse the preview: https://deploy-preview-2006--stoplight-elements-dev-portal-storybook.netlify.app

@smoores-dev
Copy link

We just ran into this today, amazing that this PR was already open. Thanks so much @danpat!

@smoores-dev
Copy link

Does @mmiask or @mnaumanali94 (or anyone else!) have any time to take a look at this? It would be really awesome to have this functionality!

@tilgovi
Copy link

tilgovi commented Feb 25, 2022

In the case @smores and I are hitting it's actually not even a cross-origin request, but it looks like this project is using a fork of json-schema-ref-parser that a resolver that uses isomorphic-fetch and excludes credentials by default by passing 'omit'. If it just passed 'same-origin' as the default that would resolve our issue.

@tilgovi
Copy link

tilgovi commented Feb 25, 2022

I think withCredentials is a bit coarse for this use case because schemas might have references that span multiple domains. In practice, most folks are probably resolving from a single domain, but we can't assume that. I would bet the most common need for credentials is same-origin, though. If people want to set it to always send credentials, that's okay, but I can imagine wanting the 'same-origin' default, instead, so that I could have private schemas that reference public schemas and only send credentials for the private ones.

@Nezteb
Copy link
Contributor

Nezteb commented Mar 10, 2022

@marbemac @lottamus How do y'all feel about this?

@Nezteb
Copy link
Contributor

Nezteb commented Mar 10, 2022

Hi @danpat! Thanks for contributing to our OSS project! We'll work on getting this reviewed within the next couple weeks. I just wanted to keep you updated.

@tilgovi
Copy link

tilgovi commented Mar 10, 2022

@danpat is your need for actual cross-origin requests, or just same-origin requests with credentials?

When I dug into this, I determined that if the build were not using a fork of json-schema-ref-parser, but instead used webpack to provide Node.js polyfills for the browser via node-libs-browser, we'd be hitting code in stream-http that looks a lot like the resolver in the json-schema-ref-parser fork but defaults to same-origin rather than omit.

https://github.com/jhiesey/stream-http/blob/master/lib/request.js#L148

Since none of this withCredentials related stuff makes sense in a Node.js server environment, I imagine the webpack scenario is what json-schema-ref-parser might be expecting. But, I can't say for sure that someone else doesn't have a requirement to explicitly disable all credentials.

@danpat
Copy link
Author

danpat commented Mar 10, 2022

@tilgovi Mine is a same-origin situation. Our setup is:

  1. I have elements being served from index.html at https://example.com/myschema/ <- all fetches to this require cookies to get through authentication logic
  2. I have mainschema.yaml at https://example.com/myschema/mainschema.yaml <- elements fetches this fine, cookies are included
  3. I have subschema.yaml at https://example.com/myschema/subschema.yaml <- this file is being referred to by mainschema.yaml like this:
components:
  schemas:
    SubSchema:
      $ref: "./subschema.yaml"

The core issue is that when the remote fetch for https://example.com/myschema/subschema.yaml happens, no cookies are included, so our authentication gateway intercepts the request and returns a 304 redirect to an authentication page.

@emanb29
Copy link

emanb29 commented May 25, 2022

My team is having exactly the same problem as @danpat described -- we have an authentication proxy in a same-origin setup with an application that embeds Stoplight Elements. Requests issued by Stoplight lack the credentials: same-origin or credentials: include parameter, causing the authentication proxy to reject the request (redirecting to an authentication endpoint).

Any mechanism that adds pass a parameter to the Stoplight Elements React component letting us specify to use same-origin or include would resolve our problem.

By the principle of least privilege, we would prefer the ability to set same-origin (since we have a same-origin usecase) but include would work too.

As an aside, thanks for the fantastic PR @danpat -- this is exactly the kind of change I was looking for!

@aleskovets
Copy link

Looks like I am facing the same issue when serving apidocs via "Internal" github pages. With sub-schema reference it tries to hit github auth endpoint and fails with CORS access error.

@mmiask mmiask removed their request for review August 22, 2022 09:48
@matty-v matty-v requested a review from a team August 24, 2022 14:29
@matty-v matty-v removed the request for review from a team August 24, 2022 14:29
ellyxc pushed a commit to dgitsystems/stoplightio-elements that referenced this pull request Sep 16, 2022
ellyxc pushed a commit to dgitsystems/stoplightio-elements that referenced this pull request Apr 17, 2023
@marc-ste
Copy link

Is there any update on this?

@tilgovi
Copy link

tilgovi commented Sep 7, 2023

I still think this could be solved for most users by fixing the fork of json-schema-ref-parser. The fork being used here uses isomorphic-fetch and specifies omit as the default if credentials aren't requested.1. The default should be same-origin, which is what browsers do by default and what the webpack polyfill for the Node.js http module does.2

ellyxc pushed a commit to dgitsystems/stoplightio-elements that referenced this pull request Nov 1, 2023
@chohmann chohmann added the jira label Feb 16, 2024
laurie-dgit pushed a commit to dgitsystems/stoplightio-elements that referenced this pull request May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants