Loopback-next: API Explorer does not work in Safari (mixed HTTP/HTTPS content problem)

[bajtos]

Description / Steps to reproduce / Feature proposal

1. Start our todo example application
2. Open http://127.0.0.1:3000/swagger-ui in Safari (MacOS)

Current Behavior

Failed to load API definition.

• Fetch errorNot allowed to request resource http://127.0.0.1:3000/openapi.json
• Fetch errorPossible mixed-content issue? The page was loaded over https:// but a http:// URL was specified. Check that you are not attempting to load mixed content.

Expected Behavior

API Explorer (swagger UI) is correctly loaded for the explored application.

Please note that both Chrome and Firefox work well.

Acceptance Criteria

Verify issue has been resolved once we offer a self-hosted API Explorer #559. If not, re-review this issue with the team. Otherwise close it.~

• [ ] Create a new subdomain to host swagger-ui, e.g. explorer.loopback.io.
• [ ] Move the hosted swagger-ui website from loopback.io repo to a new GH repository
• [ ] Configure this new repo to be hosted on explorer.loopback.io (via GH pages)
• [ ] Make sure both HTTP and HTTPS schemas are allowed for this new domain
• [ ] The current URL https://loopback.io/api-explorer should redirect to the new domain
• [ ] Check and possibly fix LB4 code creating the explorer URL to use the same scheme (HTTP/HTTPS) as is the API application using.

_See Reporting Issues for more tips on writing good issues_

[bajtos]

Related reading:

https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

Note: Since Firefox 55, the loading of mixed content is allowed on http://127.0.0.1/ (see bug 903966). Chrome allows mixed content on http://127.0.0.1/ and http://localhost/. Safari does not allow any mixed content.

https://stackoverflow.com/questions/32883306/safari-9-disallowed-running-of-insecure-content

According to the Apple support forums Safari does not allow you to disable the block on mixed content.
Though this is frustrating for usability in legitimate cases like yours, it seems to be part of their effort to force secure content serving / content serving best practices.

I am not sure how to actually fix this problem if Safari does not allow mixed content even on localhost. Perhaps we need to support both http and https protocols for our hosted API Explorer, so that HTTP applications can access API Explorer via HTTP? Or maybe it's enough to describe this problem in our documentation, advise users to use Firefox or Chrome, and wait until we implement self-hosted explorer (see https://github.com/strongloop/loopback-next/issues/559).

[hacksparrow]

Does not work on the latest version of Chrome either.

[dhmlau]

@virkt25 , do we need to estimate this or should put to backlog directly?

[virkt25]

I think @raymondfeng already has a fix for this in https://github.com/strongloop/loopback-next/pull/1608

[raymondfeng]

@virkt25 Unfortunately I don't think #1608 will resolve this issue. The root cause of this one is that our hosted API explorer is served using https but the openapi spec is exposed over http by default unless the target app is secured using https.

[virkt25]

Ah right, forgot the issue goes beyond just not setting the right protocol for the openapi spec file.

@dhmlau we should estimate this but for that to happen we need to decide upon a fix. I can think of two options:

• Host a non-https version of the API Explorer ourselves (maybe a new domain like explorer.loopback.io that has both http and https support? We can get @rmg to help with the setup.

• Create a self-hosted / built-in API Explorer component as planned in https://github.com/strongloop/loopback-next/issues/559

EDIT assigned to everyone for further discussion.

[raymondfeng]

To self-host API explorer UI, I created a PR to enable it: https://github.com/strongloop/loopback-next/pull/1611

[dhmlau]

Discussing with @virkt25, after #1611 is done, this issue can be resolved by addressing #559.

[bajtos]

Earlier this week, we discussed this issue with @raymondfeng and @virkt25 and found a solution that should be relatively quick to implement and does not require self-hosted explorer.

See the updated acceptance criteria:

• [ ] Create a new subdomain to host swagger-ui, e.g. explorer.loopback.io.
• [ ] Move the hosted swagger-ui website from loopback.io repo to a new GH repository
• [ ] Configure this new repo to be hosted on explorer.loopback.io (via GH pages)
• [ ] Make sure both HTTP and HTTPS schemas are allowed for this new domain
• [ ] The current URL https://loopback.io/api-explorer should redirect to the new domain
• [ ] Check and possibly fix LB4 code creating the explorer URL to use the same scheme (HTTP/HTTPS) as is the API application using.

[hacksparrow]

If you remember my demo, the app which was hosted on a https server had its s stripped and swagger-ui tried to load the http version and failed.

Is this covered by one of the criteria?

[bajtos]

@hacksparrow thanks for raising this concern. I believe the correct handling of protocols is part of the last criteria:

Check and possibly fix LB4 code creating the explorer URL to use the same scheme (HTTP/HTTPS) as is the API application using.

When the app is running on HTTP, then the explorer should redirect to http://explorer.loopback.io. When the app is on HTTPS, then the explorer should redirect to https://explorer.loopback.io.

[raymondfeng]

Fixed. Now we have API explorer served from:

• https://explorer.loopback.io (for https)
• http://explorer.loopback.io (for http)