Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

Why not just configure your server or a proxy to add the necessary headers that unlock CORS restrictions.

The web server is configuring CORS policy properly, but the browser is making client-side calls to localstack. As far as I can tell, localstack has hardcoded a CORS policy that is a mismatch for the requests being sent.

The cleanest solution is to extend the dev pipeline with a proxy for localstack. It won't take me long to knock that out, but it's not something I can prioritize at the moment.

Because having code that behaves differently on development and production is never a solution, it's a workaround. Having bugs that can't be reproduced locally is the worst thing that can happen to a developer. So yeah, you can _just_ put environment settings if you have no other possible way, but you should really avoid it if there is any other one (like using chrome with CORS disabled, here).

Disabling CORS in your browser is not representative of production. Serving CORS headers is.

Mentioned this in another response. In this case, that requires the addition of another component. The app itself is serving a valid CORS policy. The stub we're using to support S3 development offline (LocalStack) ignores the configuration it's passed.

I agree with you that fixing the headers (via a proxy in this case) is the right solution. I'm just not able to prioritize right now.

Beyond that, there are always going to be occasions where developers, security analysts, and testers need to bypass default security enforcement. I'd like to see every browser provide a way to make these adjustments for a one-off session (e.g., via a command-line switch). It's an efficient solution that I can offer when I come across a nasty hack living permanently in a developer's web configuration.

By that same argument, using Chrome with CORS disabled is just as bad, if not worse. If you only test in Chrome with CORS disabled, how do you know that CORS works at all?

Because in real companies the IT department needs a real good reason, or a large number of devs that need it, to reconfigure a server that way.

If you're not a lone wolf, or working in the SV bubble, the IT and security departments are going to tell you to go pound sand.

Not really. In lots of relatively large companies there is a good relationship between infrastructure, development and security teams and they will work to find a solution that works for everybody.

This is how it works at my work.

CORS is allowed while running locally and then set while running in development and finally production.

It's 2 lines of code with most modern web frameworks with junior level knowledge required. Actually, any people with decent dev skills (any people that receives money for code should...) add a conf switch for that since the begining of the project.

I don't buy your comment at all.

Reply on news.ycombinator.com