Killing CORS Preflight Requests on a React SPA
m.alphasights.com
Killing CORS Preflight Requests on a React SPA
1–10 of 54 posts
Re: Killing CORS Preflight Requests on a React SPA
#2super minor but unless I'm mistaken SPA stands for "Single Page Application", so the first sentence in the post is a bit jarring:
> AlphaSights’ recruitment platform evolved from a Rails application into a _classic SPA app_.
Update 20s later: is "Wepack" in the diagram supposed to be "Webpack"?
Update 60s later: Can you explain _what_ you're actually using that runs into CORS issues? Are browsers talking to the api.* address directly? The diagram seems to imply that all api.* communication is routed through app.*, in which case CORS wouldn't be an issue, right?
Re: Killing CORS Preflight Requests on a React SPA
#3"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route."
If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?
Re: Killing CORS Preflight Requests on a React SPA
#4"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route." If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?
Another symptom of how rotten the javascript ecosystem is. If I'm picking a technology stack for a business, I want to pick one that will last me 10 years.
Re: Killing CORS Preflight Requests on a React SPA
#5super minor but unless I'm mistaken SPA stands for "Single Page Application", so the first sentence in the post is a bit jarring: > AlphaSights’ recruitment platform evolved from a Rails application into a _classic SPA app_. Update 20s later: is "Wepack" in the diagram supposed to be "Webpack"? Update 60s later: Can you explain _what_ you're actually using that runs into CORS issues? Are browsers talking to the api.*…
> Wow, my first thought was “headers are messy and this is so restrictive”. As a lazy developer, I’ve shied away from dealing with headers, relying on abstractions provided by libraries and frameworks.
I'm sure this is a common thought, but oh man it hurts me to read it.
Re: Killing CORS Preflight Requests on a React SPA
#6"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route." If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?
2016 would be the rise of GraphQL or Falcor backends, where you write exactly what you are looking for on the frontend and send that request to the backend instead of REST endpoints.
Re: Killing CORS Preflight Requests on a React SPA
#7"If this feels “so 2015” to you, we did start building the app in early 2015 and went down the centralized RESTful API route." If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?
Another symptom of how rotten the javascript ecosystem is. If I'm picking a technology stack for a business, I want to pick one that will last me 10 years.
Good luck with your Java Web Start app!
Re: Killing CORS Preflight Requests on a React SPA
#8> In terms of security, all API calls should be using https and there is little difference in putting the token in headers or as part of the query string.
Mostly true. But as a heads up, you might want to shy away from this as plenty of browser extensions are actually spyware and report full URLs back to the mothership. We ran into this recently where calls to our service including API keys in the query parameters ended up being reported back -- our customers were testing our API by calling it in the browser. Some kind of extension(s) was reporting it to a service that finds popular URLs on a given domain.
Headers aren't much more secure if someone is trying to steal data, but analytics providers/url aggregators don't care about some arbitrary header.
Our solution has been to push users to use headers and offer mutual auth (client certificates). At least with mutual auth, there isn't a trivially-leakable shared secret, but it does require more sophisticated automation (or a gateway/proxy) for clients to manage.
Re: Killing CORS Preflight Requests on a React SPA
#9Maybe this is obvious, but why not just configure a reverse proxy to point different paths to different backends?
I always assumed CORS was more for connecting directly to 3rd party APIs.
Re: Killing CORS Preflight Requests on a React SPA
#10super minor but unless I'm mistaken SPA stands for "Single Page Application", so the first sentence in the post is a bit jarring: > AlphaSights’ recruitment platform evolved from a Rails application into a _classic SPA app_. Update 20s later: is "Wepack" in the diagram supposed to be "Webpack"? Update 60s later: Can you explain _what_ you're actually using that runs into CORS issues? Are browsers talking to the api.*…
The diagram is bad, the browser is running code loaded on app.* and making requests to api.*; I've used similar setups and have run into the same issues the author is describing.