Fix refs with authentication being broken if the fetch for iframe.html
succeeds (but with a request to authenticate)
#18160
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue:
I discovered that when a ref is defined (could be an auto-ref) which requires authentication; storybook will (server-side) check to see if it's a public storybook.
It checks this because public storybook do not need authentication headers to be sent (which require more server/cors-setup).
The idea is that if NodeJS can make a request to the
iframe.html
resource and get a statusCode200
that means the storybook can be referenced without authentication headers at runtime in the web-app.So what happened?
The node side of storybook makes a request to the
iframe.html
and the service returns a HTML page with a login form; with statusCode 200.Arguably the service should return a non-200 statusCode, but it doesn't..
What I did
I added an additional check to re-request the resource with an accept-header, and check the absence of a loginUrl field on the JSON response.
If the response is not valid JSON this additional check is ignored, and the previously behavior is preserved.
How to test