I route everything through an nginx server. It's configured to handle deep linking by having all routes not expressly known to be API endpoints to just serve the index page. There might be a way to do it via s3/cloudfront, I wouldn't know.

Personally I'm OK with the way I have it - we serve 1000x as many endpoint calls as we do fresh loads of the UI, so serving the occasional static doc from our "api webserver" is fine.

Right - for react deep-linking (and I'm guessing any SPA routing that doesn't involve hashes) - you need a specially configured webserver. So it's not really a 100% static website. I didn't get that at first.

Like I said, the only way to serve the index page with Cloudfront is to hijack the 403 (forbidden) error response and redirect it to the index page with a 200 status code. This causes problems elsewhere when you really do want to show a 403 and not the index page.

I wonder if there's another way to handle it. Like have
www.mysite.com - this is a site that ONLY serves index.html
static.mysite.com - this is a typical cloudfront dealy that serves static content
api.mysite.com - this is your backend apis

If you can tell cloudfront "no matter what they ask for only give index.html" then you can have index.html refer to static.mysite.com for the javascript stuff and any other static assets. That might work. But again, I don't know **** about cloudfront.

Yeah looking around it looks like with cloud front you'd have to set your index.html as the error document, which might be undesirable, I dunno.

Yeah either that or statically generate your pages ahead of time and serve them. But then you wind up with /registration.html - since you can't do wildcard re-routing with cloudfront like you can with apache or nginx.

Yea deeplinking is annoying so in this case I'm taking SPA all the way and only having literally a single page with no links, etc. Just super minimal basic frontend to see some stats.

How come Apache's not cool anymore?

It’s very fast and straight forward to get running.

Apache is usually used for php, nginx is usually used for node.

I would say that "apache is for php" only in the sense that it's the "A" in LAMP, so I guess they're cemented together in some people's minds. But the truth is, Apache was just dominant for many many years, it was used for literally everything, but their market share has fallen dramatically.

nginx fills the same niche but is, to my eye, more self contained and somewhat simpler. It's been growing in popularity over the last 10 years and apache has been falling.

Nginx uses way less memory as well from most benchmarks I have seen

I have tried every possible combination of credentials, withCredentials, set_cookie parameters, hostnames, edited my host file to change localhost, session, make_response in react and flask and everything from every god damned SO answer and I see the cookies in the Network traffic response in the browser and I can't get a mother ****ing cookie to set!!!!

What's your evidence that the cookie isn't set?

(let me add: if you're trying to prove it by making another call and seeing if the new cookie is passed, there are multiple reasons why it might have been stored, but not passed to the next call - so depending on your browser you're probably better off trying to verify the cookie set another way)

It doesn't show up in the developer's console under storage->cookies. I can set a cookie from the developer's console and see it set.

Also it doesn't show up in the network traffic next request.

Are any cookies being set in that browser?

Micro, paste the whole code you're trying to use from the server side. Also are your cookie and your browser set to the same domain?

Yes.

It's very long, but maybe. (Actual cookie thing is not long, but there's a lot to excise and explain) I can't really work on it until after work. My paying gig is M-W 8-4 more or less and this is a side thing.

I think I know what it is though and is because I'm trying to set it from the wrong server - the API server - instead of the app server - the webpack(?) React development server.

Also, I'm not sure I can even set cookies on a single page app thingy in the middle of its use. That's all after headers are sent and everything. I was kind of trying to put off learning the new paradigm of session management (if it counts as that), but it's probably the thing to do at this point.

I don't know why I would have these services separated other than to figure this kind of stuff out, but that's a pretty good reason.

Sounds likely.

Although if you're using the cookie to authorize requests to the API server than that's where you want it, and my somewhat vague recollection is that the HTTP client in the browser should automatically use that cookie when communicating back to the same API server on the same port.

I guess the other thing that might matter is whether you're using a session cookie or a longer lasting cookie? If it's a session cookie I'd expect the above to be true provided that you've made at least one request to the server in that session which responded with the cookie, but it obviously won't survive to a new session.

API is on a Linode server and react development server is on my local machine. So, it was probably dumb as a bag of rocks to try to set cookies from there.

I'm not sure what you're doing with the contents of the cookie but if you need it to be available within the SPA more generally you could potentially make some API call which returns it as data, i.e. here's your API token, and then you can do whatever you want with it, including setting a second cookie on localhost.

Yeah. That's what I'll try to do tonight.

The most important thing with the cookie is the domain has to line up. So you have to set the cookie on the server that's on the same domain that you want it returned to. The browser will only automatically return the cookie to requests on the same domain that originally placed the cookie with a response.

Cookies don't work on localhost:3000 or whatever. They need a fully qualified internet domain.

It's possible to have your react webserver and api server on the same domain. But you'd either need the react webserver to proxy to the api server, or some kind of router (like nginx) in front of both that receives requests on that domain, then routes them based on rules. IE - everything at /api/* goes to the API server, and the rest goes to the react dev server. But again - you have to use server-side routing (proxy). You can't just return a 301/302 redirect to the browser, or it will know it's not on the correct domain.

I believe you might be able to set a cookie at the top-level domain and have it returned to a subdomain. IE - api.microbet.com vs. reactweb.microbet.com. But I'm not 100% sure about that.

There's also options like https only and no-javascript (meaning the client-side JS code has no access to the cookie).

I got through that part and set my hosts file to run it at dev.localhost.com which I think will work for setting cookies from react.

Cookies work on localhost for me just fine:





The next GET is including all of those cookies...

AFAIK it's only that the domain for the cookie includes both "localhost" and the port.

Ok they work but very few scenarios do you want to do that. So just don't do it is my recommendation.