4 ms·

This is how I prefer to do it. No CORS pre-flight requests and messing with CORS settings

by weird-eye-issue 6y ago

yitianjian 6y ago
Seconding (thirding?) this. I'm curious, are there any SPAs that aren't done this way?
- weird-eye-issue 6y ago
  Yes there are a ton. Actually it was a bit of a pain setting it up that way. I'm using Cloudflare to dynamically route to S3 or an ALB based on the path. If Cloudflare didn't have that option I would have had to roll my own solution to defeat CORS which could have added in another point of failure Edit: I meant Cloudfront. I do that a lot
- beckingz 6y ago
  app.example.com vs api.example.com ?
  - true_religion 6y ago
    Sure I've done that but only for SPAs that are totally anonymous, and deploy the api.example.com behind a CDN cache.
- slowmovintarget 6y ago
  The article is referring to all the myriad other things an SPA will bring in. Analytics, feedback components, interactive galleries, notification components, header components... you can sew a site together from SaaS components that all live in different domains. Well... you could. Harder now. From the article: > So are SPAs dead? Well – SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.
- preommr 6y ago
  I have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare. This applies not only to production but also for local testing. I used to have a reverse proxy for local development. Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.
  - weird-eye-issue 6y ago
    Yeah I used rules in Cloudfront for this. Only have one API backend so security doesn't really factor into this much. Actually I consider it slightly more secure because there was no way for me to misconfigure CORS.
    - preommr 6y ago
      > there was no way for me to misconfigure CORS. This is a pretty big issue because there are a shit tonne of bad resources that poorly explain CORS - so many places just slap a wild card in 'access-control-allow-origin', and call it a day. Even a lot of the framework middleware can be confusing and unhelpful. FWIW, once I actually got it setup, it was very simple, very easy. I highly recommend MDN's CORS page[1] as the only source someone should read, and to read the whole thing to actually learn it rather than just grabbing a library to solve the problem in 15 minutes. Even then, I had to start with a small test project and test things at different levels to understand what a library would be doing. My back end is golang, and I used gorilla/mux, so I did things step by step to really know what was working and what wasn't. I've done it other ways with something like Spring boot and libraries where it's just a goddamn mess because it tries to automate too much for you and it becomes way too confusing. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- dragonwriter 6y ago
  > I’m curious, are there any SPAs that aren’t done this way? For…enterprise reasons…the SPAs I’ve worked on in $DAYJOB use apis hosted in a separate subdomain (and, therefore, origin) than the page itself, meaning we have all the CORS headaches. But, certainly, segregating by path rather than domain is a lot more convenient if you control both the page and the APIs it consumes.

This is how I prefer to do it. No CORS pre-flight requests and messing with CORS settings

yitianjian 6y ago

Seconding (thirding?) this. I'm curious, are there any SPAs that aren't done this way?

weird-eye-issue 6y ago
Yes there are a ton. Actually it was a bit of a pain setting it up that way. I'm using Cloudflare to dynamically route to S3 or an ALB based on the path. If Cloudflare didn't have that option I would have had to roll my own solution to defeat CORS which could have added in another point of failure Edit: I meant Cloudfront. I do that a lot
beckingz 6y ago
app.example.com vs api.example.com ?
- true_religion 6y ago
  Sure I've done that but only for SPAs that are totally anonymous, and deploy the api.example.com behind a CDN cache.
slowmovintarget 6y ago
The article is referring to all the myriad other things an SPA will bring in. Analytics, feedback components, interactive galleries, notification components, header components... you can sew a site together from SaaS components that all live in different domains. Well... you could. Harder now. From the article: > So are SPAs dead? Well – SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.
preommr 6y ago
I have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare. This applies not only to production but also for local testing. I used to have a reverse proxy for local development. Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.
- weird-eye-issue 6y ago
  Yeah I used rules in Cloudfront for this. Only have one API backend so security doesn't really factor into this much. Actually I consider it slightly more secure because there was no way for me to misconfigure CORS.
  - preommr 6y ago
    > there was no way for me to misconfigure CORS. This is a pretty big issue because there are a shit tonne of bad resources that poorly explain CORS - so many places just slap a wild card in 'access-control-allow-origin', and call it a day. Even a lot of the framework middleware can be confusing and unhelpful. FWIW, once I actually got it setup, it was very simple, very easy. I highly recommend MDN's CORS page[1] as the only source someone should read, and to read the whole thing to actually learn it rather than just grabbing a library to solve the problem in 15 minutes. Even then, I had to start with a small test project and test things at different levels to understand what a library would be doing. My back end is golang, and I used gorilla/mux, so I did things step by step to really know what was working and what wasn't. I've done it other ways with something like Spring boot and libraries where it's just a goddamn mess because it tries to automate too much for you and it becomes way too confusing. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
dragonwriter 6y ago
> I’m curious, are there any SPAs that aren’t done this way? For…enterprise reasons…the SPAs I’ve worked on in $DAYJOB use apis hosted in a separate subdomain (and, therefore, origin) than the page itself, meaning we have all the CORS headaches. But, certainly, segregating by path rather than domain is a lot more convenient if you control both the page and the APIs it consumes.