Blocked loading mixed active conten

[Conando025]

The compile request has an http location header which is blocked by Firefox as it is mixed active content at least that's how I under stand it. I have the error message below Blocked loading mixed active content “http://playground-backend-iob5vy5ctq-uw.a.run.app/api/run?code=%0Ause+yew%3A%3Aprelude%3A%3A%2A%3B%0A%0A%23%5Bfunction_component%28App%29%5D%0Afn+app%28%29+-%3E+Html+%7B%0A++++html%21+%7B+%22hello+world%22+%7D%0A%7D%0A%0Afn+main%28%29+%7B%0A++++yew%3A%3Astart_app%3A%3A%3CApp%3E%28%29%3B%0A%7D%0A”

[ranile]

i have tested it with firefox and it works. Maybe there is an extension causing problem for you

[Conando025]

Strange, so i first understood it wrong. My client makes the request and gets the response header but due to the location attribute of the response containing an http instead of an https adress the response body gets blocked. But from what mdn says that seems to be default behavior so not sure what is actually causing the issue

[Conando025]

Did you test on your own Firefox instance if so can you check if you set "security.mixed_content.block_active_content" in the about:config to false? Doing so makes it usable but isn't the standard config for Firefox. It also downgrades the connection for the playground to http

[ranile]

I have it set to true. Can you post a screenshot of your network tab? The location header returns http for me too (this is controlled by firebase)

but the redirect request is sent as https

[ranile]

The API is also available at https://api.play.yew.rs so instead of doing a /api/<path> redirect, we could make a request to https://api.play.yew.rs/<path>

[Conando025]

Yeah I saw that when visiting directly it upgrades the connection to https but for me it gets blocked before following the redirect

[Conando025]

I also get an http/3 response maybe thats the issue but that just creates the new question why the the http version is different. Okay no, I checked it and neither http/3 nor ipv6 are causing the issue

[ranile]

This should've been the first question but what version of Firefox and what OS are you on?

[Conando025]

Sorry should have provided that earlier Firefox 106.0.1 on Linux (popos)

[DarylPinto]

The same Mixed Content error occurs in Chrome on macOS with no extensions. This doesn't seem to be a Linux or Firefox specific issue:

OS: MacOS 12.2.1 Chrome: 107.0.5304.87 (Official Build) (arm64)

[chrisp60]

Similar issue on Windows in Vivaldi (chrome based), tried in a private window with extensions off and the issue persists. Same thing with mostly all security features disabled.

[houseofmercy-github]

Browser: Firefox 107.0 (64-bit) OS: macOS 10.15.7 (Catalina) Seeing the same issue. Steps to reproduce:

• open https://play.yew.rs
• press Run
• observe blank white window appears
• Web Developer Tools Console shows error

Blocked loading mixed active content “http://playground-backend-iob5vy5ctq-uw.a.run.app/api/run?code=%0Ause+yew%3A%3Aprelude%3A%3A%2A%3B%0A%0A%23%5Bfunction_component%28App%29%5D%0Afn+app%28%29+-%3E+Html+%7B%0A++++html%21+%7B+%22hello+world%22+%7D%0A%7D%0A%0Afn+main%28%29+%7B%0A++++yew%3A%3Astart_app%3A%3A%3CApp%3E%28%29%3B%0A%7D%0A” play.yew.rs

[coderfin]

I'm also seeing it on Chrome/MacOS

Can someone rename the issue to something like: "Blocked loading mixed active content"?

[ranile]

I think Google is to blame here. Firebase rewrites are used for for redirect and it returns http link for the cloud run service: https://firebase.google.com/docs/hosting/cloud-run. Browsers don't like http link here, perhaps because there's WASM bytes inlined in the <script>.

If anyone knows a fix for this, I would be happy to hear it.

[chrisp60]

Dug around a bit and found a more specific blurb from the firebase docs

Cloud Run redirects all HTTP requests to HTTPS but terminates TLS before they reach your web service. If your service generates a web resources that refers to other web resources with unsecured URLs (http://), your page may be subject to mixed content warnings or errors. Use the https protocol for all reference web URIs or account for proxy directives in the HTTP Request such as the X-Forwarded-Proto HTTP header.

I am guessing there is a unsecured URL being called somewhere. Pretty sure it is not due to the WASM or firebase specifically since they should be redirecting everything to https. I can try to look around this weekend. Pretty unfamiliar with the codebase though @hamza1311

Edit: link to the docs

[ranile]

@ChristopherPerry6060 actually this redirect is from Firebase Hosting to Cloud Run, not between Cloud Run services.

The request is supposed to go as follows:

• Run button is clicked
• /api/run is called
• Firebase hosting sees the redirect and sends it off to cloud run
• Cloud run services do the computation
• response is sent is back

The third step is where the issue occurs. The communication between the cloud run services isn't exposed at all

[ranile]

I've pushed a workaround that should fix this issue. It no longer goes through any redirects to reach the server