Comment by mrweasel | Hacker News Reader

Comment by mrweasel | Hacker News Reader

I've struggled with this exact problem. A client developed a SPA and an API to go with it. Because "reasons" they wanted the API to live on api.customersite.com. Fair enough, that's their problem. Except it's not, because the developers have no idea how CORS work, only that it's a thing. So their API can't send CORS headers back, they never implemented that and apparently can't figure out how to make it work.

Instead, we now have a reverse proxy (haproxy) that "fixes" the missing CORS headers, by intercepting the OPTIONS call and return a dummy response with the correct headers included. The developer basically understand NOTHING in regards to CORS, so whenever the silly SPA breaks, the logic is always the same: "CORS is broken, fix it". At not point has it been an option to fix the API service to include the correct headers.

We could just have moved the API to /api and saved days of debugging and writing work-arounds, but no, api.customersite.com looks more professional.

How you can be a web developer today and not knowing how to add two headers to all responses a API does, boggles my mind. Literally took me about 30 minutes to understand how CORS works when it first started being shipped with browsers.

You probably understand the rest of what you need to understand CORS. I've noticed that web developers today don't even understand things like HTTP in general particularly well. They're not trying to understand, they're trying to ship the next feature, and CORS is "blocking them".

Sadly true, I love to ask webdevs in intervews if they can give definitions of http, or idk, user agent, and it's impressive how much ignorance there is out there.

In my experience with CORS, my problem is it takes 30 minutes nearly every time you need to bugfix it.

It’s not that complicated but when something breaks CORS adjacent, you’re stuck reviewing the gotchas.

I've had similar experience.

I inherited both front and back-end. Their solution was "allow: *" (which is like saying, "I don't like carrying my house keys, so I removed the lock")

The system did require a "api.*" for other things, so my quick solution was a proxy_pass for /api.

I'm pretty sure this is the most upvoted answer on SO

...tap ...tap ...tap

No. Second top answer. https://stackoverflow.com/a/27280939/1507124

With the obvious WTF top comment and the natural follow-up. It solved my problem, therefore it's great.

Interestingly, your hacky workaround to client non-cooperation sounds very much like what others are suggesting as their first-choice solution anyway!

See for instance this comment: https://news.ycombinator.com/item?id=29778528 Which suggests implementing the CORS response in a reverse proxy or some other covering layer.

And of course the OP also involves a reverse-proxy, although one mapping to avoid the need for CORS headers.

Reply on news.ycombinator.com