Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cache your CORS

httptoolkit.tech

Post reply on HN
Print view View original

51–60 of 118 posts

Re: Cache your CORS

#51

Post by zmxz »

beebeepka wrote: post #42
zmxz wrote: post #35

Earlier quoted context omitted.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS.

Example: you have http://ui.localhost and you have http://api.localhost

UI speaking to API = CORS

But, instead of doing fetch('http://api.localhost/resource'), you do fetch('http://ui.localhost/api/resource')

In the nginx config for ui.localhost domain, you create a rule that says "everything that starts with /api, intercept it, remove /api at the start of the path and send the rest to http://api.localhost, ending up with http://api.localhost/resource"

I do frontend and backend development and I have this setup with docker-compose, the config for nginx is really trivial and widely available in many tutorials.

Re: Cache your CORS

#53

Post by pas »

danwee wrote: post #29
enlyth wrote: post #28

Earlier quoted context omitted.

> Offer a variant of your API format that either: 1. Moves the resource path to the request body GraphQL ducks

> GraphQL And now you have two problems

But you have a nice schema for your problem :)

GQL is a bit ugly, but works well, kind of standardized, etc.

Is there something similar for providing a batch endpoint for OpenAPI requests?

Re: Cache your CORS

#54

Post by CoolCold »

lbriner wrote: post #37
kareemsabri wrote: post #20

We just use a path prefix and a reverse proxy to save the pre-flight request altogether.

"just use"! What if the API is shared between multiple domains? Do you need to reverse proxy it everywhere? What if it is a public API for third-party sites?

I could be in some sort of bubble, but hardly can remember the case when dynamic part of request has not flown through some sort of reverse proxy or fully capable webserver (like Apache) anyways. On dev envs of course seen, but not in production.

Re: Cache your CORS

#55

Post by zmxz »

LunaSea wrote: post #41
zmxz wrote: post #35

Earlier quoted context omitted.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

If you serve your static files from a CDN it's simply not possible to do so. It's a very common case.

Can you provide an example, just so we can be on the same page? You do an XmlHttpRequest or fetch() to a static asset and it's a non-trivial request to CDN, I just wonder how it looks like and why it exists in the first place.

Re: Cache your CORS

#56

Post by moring »

zmxz wrote: post #35
Cthulhu_ wrote: post #33

Earlier quoted context omitted.

3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

I'll bite. I'm working on an application that uses Firebase, so the front-end is hosted on Firebase hosting (probably with some kind of CDN before that) and available through a firebase-supplied domain, and the back-end runs on Cloud Run behind a cloud-run-supplied domain. The domains are different, so CORS happens.

I'd like you to back up your claim that a server-side proxy or using the same domain is the easiest solution, and in particular, easier than the solutions suggested by cakoose.

Re: Cache your CORS

#57

Post by rojer_31 »

zmxz wrote: post #51
beebeepka wrote: post #42

Earlier quoted context omitted.

Well, sure. But, as a non-expert, cors kind of makes sense to me in development. What would you suggest? It's an honest question.

A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS. Example: you have http://ui.localhost and you have http://api.localhost UI speaking to API = CORS But, instead of doing fetch(' http://api.localhost/resource '), you do fetch(' http://ui.localhost/api/resource ') In the nginx config for ui.localhost domain, you create a rule that…

Scenario: In production where assuming ui.example.com is only for static resources/SSG and api.example.com is for dynamic api endpoints, we usually protect the api domain with WAF in CDN which will cost extra and typically unnecessary for the UI domain. So in this case by doing this reverse proxy, we will bypass the WAF layer or atleast feed WAF incorrect data (our server is requesting instead of the user directly). Since WAF usually has extra (significant) costs, what would you suggest in this case?

Re: Cache your CORS

#58

Post by chopin »

zmxz wrote: post #35
Cthulhu_ wrote: post #33

Earlier quoted context omitted.

3. Don't allow cross-platform requests in the first place; have your API consumers go through a server-side proxy on the same domain instead, or host it on the same domain in the first place.

This is the only valid solution and the easiest one to implement. However, for some reason unknown to me - younger devs and various organizations simply refuse to go down this route and make up reasons why it doesn't work for them, opting for more time-consuming alternatives.

Authentication with a SAML provider can make this a pain in the ass. Especially if you don't have control over the provider.

Re: Cache your CORS

#60

Post by zmxz »

rojer_31 wrote: post #57
zmxz wrote: post #51

Earlier quoted context omitted.

A web server (nginx) that can proxy your request to the other domain, but your browser sends everything to one domain, thus avoiding CORS. Example: you have http://ui.localhost and you have http://api.localhost UI speaking to API = CORS But, instead of doing fetch(' http://api.localhost/resource '), you do fetch(' http://ui.localhost/api/resource ') In the nginx config for ui.localhost domain, you create a rule that…

Scenario: In production where assuming ui.example.com is only for static resources/SSG and api.example.com is for dynamic api endpoints, we usually protect the api domain with WAF in CDN which will cost extra and typically unnecessary for the UI domain. So in this case by doing this reverse proxy, we will bypass the WAF layer or atleast feed WAF incorrect data (our server is requesting instead of the user directly).…

Forward the correct data, then it makes no difference to WAF if it's you or user requesting.

That's why we have various controls with proxies, such as including the original requester's IP etc.

It's irrelevant who actually asks for data if you pass the HTTP request info unaltered (except path parameter), the WAF can do its job. That's the beauty of HTTP and its stateless nature. You can scale infinitely and do various actions such as this one and get the expected result.

Post reply on HN