Flint 2 - luci cors errors

Technical Support for Routers
1

I've been running a Flint 2 router since shortly after its release (I was one of the earlybird buyers). Really like this router, and it's generally been really good.

At some point after the initial firmware, I started seeing CORS errors accessing my router's LUCI interface via https. I have a DNS name defined for the router that's in my own real DNS zone, and a static ip address for router.myzone.net defined in the router configuration. I've installed a LetsEncrypt certfiicate for nginx running on the router.

I use the material theme, but the stock theme does this as well. When I access the router, I get about 12 red banners that read "xhr request aborted by browser". If I look in the Chrome development panel, I see access requests not to https://router.myzone.net but to https://192.168.8.1 (ie, my router's IP address), with a message that says "CORS Error" in the status column.

If I connect to uhttpd directly on port 8443, I get a certificate error, because I've not set the certificate there - but I want the router interface to be accessible from inside my network on port 443, not 8443. I'm not sure why nginx is sitting in front of uhttpd (I don't know that this used to be the way it was set up previously), and I don't see any firewall configuration that actually has to do with the router's web interface. I'm guessing it's because the GL.iNet web UI runs on nginx, and Luci runs on uhttpd.

It's not a "breaking" problem, but it's annoying to have to clear 12 CORS errors on every page. :slight_smile:

Thanks for any tips. Seems like this might be a bug of sorts worth addressing.

2

I think I found a solution to this issue, but I'm interested in feedback on it.

I modified /etc/nginx/conf.d/gl.conf and changed the ipv4 listen line from:

    listen :443 ssl;

to

    listen 192.168.8.1:443 ssl;

(Replacing the 192.x.x.x address with my router's own internal address)

It seems that now I don't get the CORS errors, and I can still access both the gl.inet and luci interfaces. Since I only want the web UI accessible from inside my network (and via VPN, which also works), this change makes sense to me.

But I'm not sure why it fixed the CORS errors. I made the change while trying to resolve the other issue I asked about on Friday (Wireguard connection to web services in my LAN using external IP/DNS address) and found that this change affected this particular issue.