`chrome://flags/#allow-insecure-localhost` no longer supported from Chrome 119

[domdomegg]

See https://support.google.com/chrome/thread/241869686/allow-insecure-localhost-has-been-removed-as-of-chrome-119?hl=en#:~:text=Yes%2C%20the%20allow%2Dinsecure%2D,to%20improve%20security%20and%20privacy.

This is currently required by the blocks cli for testing Airtable extensions locally.

[kevee]

You can re-enable that flag by enabling #temporary-unexpire-flags-m118

[reelmatt]

Update in November 2024: the #temporary-unexpire-flags-m118 is no longer available as of the latest Chrome version (v131). There is a promising-sounding #unsafely-treat-insecure-origin-as-secure flag, but thus far I have not been able to find an appropriate origin that allows the extension to run. I have tried:

• https://localhost:9000
• https://airtable.com
• https://blocks.airtable.com
• https://airtableblocks.com
• https://block*.alt.airtableblocks.com (looking at local storage, this origin is listed)

In Safari, I am able to proceed past the "Start editing extension" step, but am immediately greeted with the error: "Connection error. Please check if your local block is running.".

The instructions Airtable provides in Firefox do seem to work—at least as of this writing/version (v132), so I am able to continue development for now.

Any suggestions from folks on how to re-enable development support for Chrome and/or Safari?

[honcharov-viktor]

I encountered this issue as well. The root cause is that the keys stored in node_modules/@airtable/blocks-cli/keys are invalid. To resolve this, the developers need to implement an option to pass valid keys directly to the blocks-cli server. In the meantime, we can use a custom proxy configured with valid keys as a workaround.

I use this workaround:

Create ssl for local host

1. brew install easy-rsa
2. easyrsa init-pki
3. easyrsa build-ca nopass
4. easyrsa --days=3650 "--subject-alt-name=IP:127.0.0.1,DNS:localhost,DNS:*.localhost" build-server-full localhost nopass
5. sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /opt/homebrew/etc/pki/ca.crt
6. mkdir keys
7. echo "keys" >> .gitignore
8. cp /opt/homebrew/etc/pki/issued/localhost.crt ./keys/localhost.crt
9. cp /opt/homebrew/etc/pki/private/localhost.key ./keys/localhost.key

Implement proxy

// proxy.mjs
import express from "express";
import cors from "cors";
import { createProxyMiddleware } from "http-proxy-middleware";
import { readFileSync } from "node:fs";
import https from "node:https";

const port = 3002;
const sslOptions = {
  key: readFileSync('./keys/localhost.key'),
  cert: readFileSync('./keys/localhost.crt'),
};

const app = express();

app.use(cors());
app.use('/', createProxyMiddleware({
  secure: false,
  logger: console,
  target: "https://localhost:9000",
  changeOrigin: true,
}));

const httpsServer = https.createServer(sslOptions, app);

httpsServer.listen(port, () => console.log("server starting on port : " + port));

run node proxy.mjs
Extension URL: https://localhost:3002
this works good enough for me.

[kevee]

I tried this and it worked, but this is still very temporary:

• Go to chrome://flags/
• Enable "Temporarily unexpire M130 flags"
• Re-enable "Allow invalid certificates for resources loaded from localhost."

[kevee]

Note here that the latest build of Chrome has dropped the M130 flags setting.

[rmx90210]

Is there a reason the dev server uses HTTPS? Asking in earnest as it's not something I've encountered before in the JavaScript dev world 😄

[kevee]

Browsers consider non-https iframes within an https page blockable mixed content.