Killing CORS Preflight Requests on a React SPA • Hacker News Board

Re: Killing CORS Preflight Requests on a React SPA

#11

Post by abritinthebay » Mon, Apr 04, 2016, 9:39 PM UTC

Everyone here is focusing on their strange app choices (which is fine) but the meat of the article is useful:

* Avoid content-type for GET requests

* if you're using HTTPS exclusively then custom headers for session auth is not generally needed so you can avoid those headers in GETs and POSTs as well.

* if you can get away with POSTing form-style vars rather than JSON then you'll avoid CORS issues too.

The rest of the article is honestly a bit pointless showboating of their app for no reason (and shows some rather poor practice not to mention the author being surprised by how CORS works in 2016...) but those are the takeaways.

Re: Killing CORS Preflight Requests on a React SPA

#12

Post by jdmichal » Mon, Apr 04, 2016, 10:01 PM UTC

I personally always thought that the CORS domain checking was needlessly and overly restrictive.

I can understand entirely different top-level domains; definitely 100% necessary.

You start to lose me at different sub-domains for the same top-level domain. Do we really need to check api.example.com from app.example.com? Chances are good that they're both controlled by the same entity, so what's the problem?

I'm out the door and around the corner when it gets down to the port number of the host. So now two requests that should resolve to the same machine need a CORS check? I think MS did right in having IE ignore the port in CORS domain checks. Not sure whether Edge does.

Re: Killing CORS Preflight Requests on a React SPA

#13

Post by abrkn » Mon, Apr 04, 2016, 10:03 PM UTC

I'd still recommend setting up a proxy that serves the api as app.your.co/api/. Dealing with CORS is just very troublesome and a complete waste of time.

Re: Killing CORS Preflight Requests on a React SPA

#14

Post by Manishearth » Mon, Apr 04, 2016, 10:16 PM UTC

jdmichal wrote: post #12

I personally always thought that the CORS domain checking was needlessly and overly restrictive. I can understand entirely different top-level domains; definitely 100% necessary. You start to lose me at different sub-domains for the same top-level domain. Do we really need to check api.example.com from app.example.com ? Chances are good that they're both controlled by the same entity, so what's the problem? I'm out t…

> Do we really need to check api.example.com from app.example.com?

Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.

Re: Killing CORS Preflight Requests on a React SPA

#15

Post by betenoire » Mon, Apr 04, 2016, 10:32 PM UTC

Xorlev wrote: post #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 en…

I agree, urls are likely to be logged everywhere as well

Re: Killing CORS Preflight Requests on a React SPA

#16

Post by lmm » Mon, Apr 04, 2016, 10:33 PM UTC

civilian wrote: post #7

treve wrote: post #4

Earlier quoted context omitted.

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!

Java Web Start is much nicer technically, and JavaFX UIs can be pretty nice. I honestly wish a lot of webapps were shipped that way.

Re: Killing CORS Preflight Requests on a React SPA

#17

Post by lmm » Mon, Apr 04, 2016, 10:34 PM UTC

Xorlev wrote: post #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 en…

I wish browser vendors would put work into making the browser-managed client certificate UX much nicer. That would make it possible to offer a real step change in security.

Re: Killing CORS Preflight Requests on a React SPA

#18

Post by steven777400 » Mon, Apr 04, 2016, 10:56 PM UTC

sync wrote: post #6

Confiks wrote: post #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?

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. http://graphql.org/ http://netflix.github.io/falcor/

This is a pretty neat idea. It seems like it would be a lot harder to reason about than REST endpoints.

I'm particularly thinking about validation (beyond the type-level, like when other data could conflict with a change) and security issues. What kinds of techniques are used to approach these concerns?

Both examples seem to be completely JavaScript-centric on the server side, but it seems like there's no reason it shouldn't work with different backend languages.

Re: Killing CORS Preflight Requests on a React SPA

#19

Post by gedy » Mon, Apr 04, 2016, 11:15 PM UTC

abrkn wrote: post #13

I'd still recommend setting up a proxy that serves the api as app.your.co/api/. Dealing with CORS is just very troublesome and a complete waste of time.

This 1000x. While for some specific use cases it's important, trying to leverage CORS to for multiple backend systems that are under your control is not worth the hassle.

Re: Killing CORS Preflight Requests on a React SPA

#20

Post by [deleted] » Mon, Apr 04, 2016, 11:20 PM UTC

Xorlev wrote: post #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 en…

[deleted]