Setting up CORS with nginx

tombh

Hi there,

Is there a way to set CORS on sites in a stack without having to go through the whole Advanced Service Configuration steps? I just need to set an Access-Control-Allow-Origin header on one of the sites in my stack.

If not, what are the steps for editing an nginx config for just 1 site?

Thanks!

Indigo

Hi Tombh 🙂

tombh without having to go through the whole Advanced Service Configuration steps

Unfortunately not, at this stage. I recognise this is frustrating for what is effectively a quick one-line addition. Custom config is definitely an area I'm keen to improve.

For now, the steps are:

in your stack, right click nginx and choose "Show Compiled in Finder"
look in conf/sites-enabled for the config for the site in question.
open up your stack's .indigostack bundle and create a path like nginx_ABC1/conf/sites-enabled/. Then copy the site config into there. Don't restart the stack in Indigo yet.
modify the config inside the bundle (add your Access-Control-Allow-Origin or whatever you need), hit save, and restart the stack in Indigo

Let me know how you go!

tombh

Thanks for getting back to me.

I've given it a go, but I'm seeing a 502 Bad Gateway error on the domain I'm editing.
I've tried a simple test case of copying the config as-is to the .indigostack bundle and restarting, but I still get the 502. I can't see anything in the nginx logs.

Do I need to change anything else?

Indigo

502 Bad Gateway is most likely a message from the "System Stack" nginx reverse proxy, saying that it can't get a response from your stack's nginx service. The first step to debugging that is to try accessing the site directly via its assigned port, rather than port 80 or 443 which go through the reverse proxy.

click on your stack's nginx and double-click on the site you're working on
take a note of the port(s) your site is being served on for http and https
try loading the site in your browser using the port eg https://mysite.test:50001, replacing 50001 with the https port noted above

Next check the nginx logs for your site.

right click nginx in your stack and choose "Show Compiled in Finder"
inside the logs folder you should see an error log for the site you're working on

It does seem likely that you've inadvertently introduced a syntax error into your nginx config override. There are some online nginx config checkers out there (eg here), and an AI (eg ChatGPT or Claude) will likely also be helpful checking over your work.

If you like, feel free to copy your config into this thread, or if it's private you're welcome to drop me an email at support@indigostack.app and I can take a look.

EDIT: hmm, sorry, I just re-read your last message and realise you got this problem even with the as-is (ie unmodified) config. That's very strange indeed. Some of my comments above might still be useful so let's see if any of them turn up anything before moving onto crazier ideas 🙂

tombh

When I try to access the site directly with the stack port (50105 or 50106 in my case) - I see ERR_CONNECTION_REFUSED.
And the nginx error log is empty for the site in both the system and stack folders.

Also fwiw, I checked the additional nginx config I was using, and there are no syntax error. This was the addition - it was inside the location ~ \.php { block:

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, HEAD, OPTIONS, POST, PUT';
add_header 'Access-Control-Allow-Headers' 'Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers';

What's next? 🙂

Indigo

Wow, this is crazy. Just to confirm, if you take the nginx config override out of the yoursite.indigostack bundle, and restart the stack, everything starts up just fine?

tombh

That's right! I just tried again to double-check and this is indeed the behaviour I'm seeing.

Indigo

Would you be happy sending me your stack config file? support@indigostack.app

tombh

Of course, do you mean the config.json from the stack package contents?

Indigo

Sorry, I should have been clearer... I mean the whole stack file eg yourstack.indigostack bundle file (but no need for your associated site or databases etc)

tombh

Sent 👍🏻

Indigo

Thanks! Sadly, I can't replicate the issue; the site for which you're overriding the nginx config loads fine for me, even after I add the config you mentioned above.

However I did notice one significant issue: your override path is slightly wrong, meaning your stack's nginx is likely attempting to set up the same site block twice, which would result in duplicate server block conflicts and could potentially cause the kind of issues you're seeing. That said, I tried it both ways and it was fine for me regardless.

Specifically, your override inside the config bundle is at nginx_84CF/conf/yoursite.localhost.conf but should be one level deeper, at nginx_84CF/conf/sites-enabled/yoursite.localhost.conf.

Let me know if that fixes it. Fingers crossed 🙂

If not, one big difference in my local attempt to replicate the problem is that I deleted all the sites from your stack bar the one in question (just to make it quicker for me to get running). So I would suggest creating a new stack with nothing but the site in question, and see if that behaves better. While I can't fathom a reason this would be related, it seems a worthwhile test nonetheless.

Finally, your username was hardcoded into the config files, so I did a find-and-replace on that to get it running on my Mac. You can actually use template variables in these config files, so replacing your username with {{user}} would allow you to use the stack on another person's Mac. Not necessary if you don't plan to do that though.

tombh

I've tried fixing the path, and I've tried creating a new stack, but still having the same problem.
I also tried stripping it right back so the stack is only using nginx, with a previously unused domain (test.test). I'll email you the stack file. Is there any other info about my system which would be useful for you to know?

Indigo

Thanks for your persistence with this, I appreciate it!

I realised there's one obvious thing to try which I should have mentioned earlier, which is to try rebuilding your stack, and the System Stack (right-click in the stack list and choose "Rebuild...".

However, I do think I am seeing a potential cause; thanks for creating the super-minimal replication example. I noticed something in the nginx config override in there, which is that it contains the port numbers chosen by Indigo for the site when you ran it last. In Indigo's UI you've left the site config's port number choice on "Auto", which is a good choice, but it means that Indigo may choose a different port on each run. That means it's entirely possible Indigo will be getting confused about which port it expects to find the site on (which it needs in order to auto-configure the reverse proxy etc) vs what the site is actually (attempting to) run on (which will be what's hardcoded in your config override).

The chances of a port conflict in this scenario is high, exacerbated by the fact you have a large number of sites in the stack, and thus a lot of ports in use. It also would explain why the same site config runs fine on my Mac (I don't have the same ports in use that you do).

As easy way to sidestep this may be to choose a port (any arbitrary unused one is fine) in the site config, rather than using "Auto". However, the correct way to avoid it when overriding a config is to use the template config as the source, not the "compiled" config:

yours came from: ~/.indigo/stacks/AF1776/nginx_8899/conf/sites-enabled/test.test/conf
correct source would be ~/.indigo/stacks/AF1776/nginx_8899/Indigo-template-src/templates/generic.php.conf

Using the latter allows Indigo free reign to apply your config from the UI etc as needed; using the former hardcodes these values which would cause problems if they change.

As a result of working this through with you I am realising more fully the extent of the UX issues around this system in Indigo, so I'm really appreciative of your patience and persistence. Your experiences will directly inform design decisions for improving the way Indigo handles config customisation.

tombh

You're welcome, I can imagine the breadth of different scenarios Indigo has to deal with, so I'm happy you're taking care of it!

Unfortunately setting the ports manually hasn't worked. These are the steps I followed:

I set the ports to 50001 and 50002 (both open and available)
Restarted the stack - page loads correctly in the browser
Copied across the config to the system stack folder (nginx_84CF/conf/sites-enabled/test.test.50001.50002.conf
Checked the file - the ports are indeed 50001 and 50002 in there, and the php server is 127.0.0.1:50003
Rebuild and restart the stack
Page shows the 502 error

I've also checked that I have are no other instances of nginx or dnsmasq running, and my hosts file only contains the default mac os entries and the Indigo entries. Is there anything else you need to know about my system?

Indigo

Hi again... a few more ideas 🙂

can you confirm you've rebuilt not just the stack itself but also the System Stack?
in 2) above, you said "Copied across the config to the system stack folder"; was that a typo? You don't want to be putting your config override into the system stack.
you mentioned dnsmasq; are you running the latest version of Indigo? Dnsmasq was deprecated a while ago so Indigo should not be starting it.

I'm starting to clutch at straws now but when you're trying your test stack, have you tried it with no other stacks running?

If none of the above works, I'm wondering if you'd be open to a direct chat to see if we can get to the bottom of this. Drop me another email if so, and we can tee it up.

tombh

Apologies - yes it was a typo, I meant that I copied the conf from the nginx compiled folder to the stack bundle.
I hadn't been rebuilding the system stack as well, but I just tried and the problem is still there.
I was just double-checking I didn't have anything on my own system that could be clashing. I don't understand enough about all this to know whether there's a risk of that!

I'd appreciate a direct chat - I'll drop you an email so we can book it in.