Allowing remote access to development client.

[foloinfo]

Hi, I was trying expo/router for my new project.

I found that remoteDevtoolsSecurityHeadersMiddleware disallows access from non-localhost (like local ip address 192.168.1.2).
Is it possible to give some option to bypass this check?

@expo/dev-server/build/middleware/remoteDevtoolsSecurityHeadersMiddleware.js

function remoteDevtoolsSecurityHeadersMiddleware(req, res, next) {
	// Block any cross origin request.
	if (typeof req.headers.origin === 'string' && !req.headers.origin.match(/^https?:\/\/localhost:/) && !req.headers.origin.match(/^https:\/\/chrome-devtools-frontend\.appspot\.com/)) {
		next(new Error(`Unauthorized request from ${req.headers.origin}. ` + 'This may happen because of a conflicting browser extension to intercept HTTP requests. ' + 'Please try again without browser extensions or using incognito mode.'));
		return;
	}

	// Block MIME-type sniffing.
	res.setHeader('X-Content-Type-Options', 'nosniff');
	next();
}

[medv]

Had to use https://www.npmjs.com/package/patch-package to remove this temporarily. Feels bad to not have cors for dynamic imports, but it's acceptable. How did you bypass it @foloinfo

[foloinfo]

@medv I ended up using react-navigation for this project (I forget what, but some other feature was needed) so I didn't solve it.
It looks like a reasonable temporary solution to patch it though. Perhaps you could utilize process.env to accommodate an extra host?

[medv]

Yeah definitely can, though I ended up having to set up cloudflared tunnels for each of the apps and apis in the monorepo, all in all it's like 8 fully qualified hostnames per machine per developer. Probably ok to just leave this one remain commented out, or if you have a consistent development domain, then adding another check in the above for endsWith would fix it well and proper.

The upside is all other networking issues with development are gone, easy + free ssl, and nixos has cloudflared service support so all the tunnel setup is declarative and deterministic. Win some lose some, thanks for getting back on this!

[jsvry]

For those using PNPM, here is a drop-in patch to fix this:
patches/@expo__cli.patch:

--- a/build/src/start/server/middleware/CorsMiddleware.js
+++ b/build/src/start/server/middleware/CorsMiddleware.js
@@ -14,7 +14,9 @@ const DEFAULT_ALLOWED_CORS_HOSTNAMES = [
 function createCorsMiddleware(exp) {
     var ref, ref1, ref2, ref3;
     const allowedHostnames = [
-        ...DEFAULT_ALLOWED_CORS_HOSTNAMES
+        ...DEFAULT_ALLOWED_CORS_HOSTNAMES,
+        // allow end-user to add more host names from an environment variable
+        ...(process.env.EXPO_CORS_ALLOWED_HOSTNAMES ? process.env.EXPO_CORS_ALLOWED_HOSTNAMES.split(",") : [])
     ];
     // Support for expo-router API routes
     if ((ref = exp.extra) == null ? void 0 : (ref1 = ref.router) == null ? void 0 : ref1.headOrigin) {

Update your package.json (in a monorepo, modify the top-level package.json):

{
  ...,
  "pnpm": {
    "patchedDependencies": {
      "@expo/cli": "patches/@expo__cli.patch"
    }
  },
  ...
}

Update your .env with your desired hostnames:

EXPO_CORS_ALLOWED_HOSTNAMES=my-pc.local,192.168.1.123

Finally, run pnpm install to apply the patch, and you should be good to go. You can also provide EXPO_CORS_ALLOWED_HOSTNAMES as a prefix in your package.json start scripts if you'd prefer:

{
  "scripts": {
    "start": "EXPO_CORS_ALLOWED_HOSTNAMES=my-pc.local,192.168.1.123 expo start -c"
  }
}