0

Seen this before here, but I've seen no real resolution. The server's Node Express express-session module OR cookie-session module sends back a Session Cookie, but as I had not coded in the SameSite/Secure attributes, they are not there and do the client on a subsequent POST to the server fails as Not Logged In, with a 403. As expected.

First, my client logs in to the server successfully: enter image description here

Here is the corresponding server code, using express-session: enter image description here

enter image description here

Which produced a Session Cookie via the Set-Cookie. NOTICE the SameSite='none' and Secure=true attributes were not included, and as expected, not there. enter image description here

enter image description here

Now, I have added the sameSite and secure attributes to the session object and run the Login again.

enter image description here

Lets look at the Response Headers returned from this Login, with the attributes added to the session object. Not only do we not see the attributes on the Set-Cookie Response Header, but there is NO cookie returned! enter image description here

It appears that when these 2 attributes are added to the session object in either express-session or cookie-session that the result is no cookie is returned. The meaning being that a subsequent POST to the server will return a 403, User Not Logged In.

I'm really stumped. I've spent a LOT of time on this! Thank you for ideas and help.

Ric
  • 796
  • 12
  • 28

1 Answers1

0

You seem to be misusing the cookie-session middleware. The cookieSession function takes an JavaScript object but the documentation doesn't mention any cookie field in that object.

Anything specified in a cookie field is ignored by the middleware and has no effect on the resulting cookie; the only reason your cookie ended up being flagged HttpOnly is that it's the middleware's default behaviour.

Instead, all the cookie attributes should be specified in a "flat" object, like so:

app.use(cookieSession({
  name: 'session',
  secret: secret,
  domain: 'chicagomegashop.com',
  sameSite: 'none',
  secure: true,
  httpOnly: true
}));

However, you have another issue. If I'm interpreting your screenshots correctly, you seem to attempt to set a cookie with a Domain attribute of chicagomegashop.com in a response from https://paylivepmt.com. That cannot work; browsers will ignore such a Set-Cookie response header:

The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.

jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • I had, and again at your suggestion, tried coding the cookie attributes being specified in a flat object, but the result is that now there is NO Set-Cooking header returned in the Response Headers for the /login POST! That seems odd. ----- As to your second point, yes, the browser is executing the web pages of the Domain chicagomegashop.com. If that is not the right domain to specify, what is the solution? In other words, how does one code in a way that a browser has a session with the server, if you don't specify the brower's website Domain? That's a conundrum. – Ric Jan 06 '22 at 21:22
  • 1
    @Ric Your [4th screenshot](https://i.stack.imgur.com/tO1Z3.png) shows that the origin that attempts to set your session cookie is `https://paylivepmt.com`, not `https://chicagomegashop.com`. There's no way you can set a cookie with domain `chicagomegashop.com` on `https://paylivepmt.com`. – jub0bs Jan 06 '22 at 21:28
  • In the Request Header of that screen, I see the Origin to be chicagomegashop.com. That is where the request has originated from. – Ric Jan 06 '22 at 21:38
  • It's a mystery to me why the cookie was returned when I used the cookie:{} attribute in the cookieSession object but when I flattened the object by removing "cookie:{}" the cookie is no longer being returned. That's odd. Seems like the issue may be around that. – Ric Jan 06 '22 at 21:46
  • Le me layout the scenario here in case it helps. chicagomegashop.com is hosted on Netlify. They offer very good hosting but no dev accessable backend for svr code. I realize that if I was hosting with a cloud provider like DigitalOcean I would have the browser post to it's chicagomegashop domain, which would return back a session cookie and then that domain could login to the backend server. I'm not able to do that in this current config. So, Basic Question- can a browser (alone) EVER directly login to a remote server & establish a session? Because that browser itself will never have a domain. – Ric Jan 07 '22 at 00:33
  • @Ric The origin of the request is irrelevant, here. The fact is that the cookie's domain attribute has to be compatible with the origin where the request was sent. – jub0bs Jan 07 '22 at 09:16
  • I made the domain specification change as you said above was correct to do, but it didn't change anything. I also decided to swap cookie-session back out for express-session to see if that changed anything and it did not. If I do NOT specify the sameSite and secure attributes in the object, a Set-Cookie header is returned in the Response Headers, without those attributes (of course). If I do specify those attributes, NO Set-Cookie header is returned in the Response Headers. I'm going to redo the screen shots and update/simplify my original question for clarity. Standby. – Ric Jan 08 '22 at 02:18
  • problem description simplified/updated. – Ric Jan 08 '22 at 18:51
  • @Ric Please provide code as Markdown code blocks rather than screenshots; the latter really make things harder for answerers. – jub0bs Jan 08 '22 at 20:02
  • Will do in subsequent contributions or updates. Just curious, how do visually clear screenshots make it harder for answerers? – Ric Jan 09 '22 at 23:55
  • @Ric If answerers want to show you what to change in your code by amending it, they simply cannot copy it. For my answer, I had to type the CORS configuration from scratch. – jub0bs Jan 10 '22 at 08:52
  • 1
    Further study, comprehensive study, seems to indicate that a browser displaying html from one domain, in my case chicagomegashop.com, for security reasons, cannot ever receive a first-party session cookie from a different unrelated 3rd-party domain. Example: I can be looking at a Bank of America page from their site, login, and receive a session cookie from them. I cannot be looking at a chicagomegashop.com page, log into Bank of America, and receive a session cookie from Bof A servers. I think this question is closed. Thanks to @jub0bs for his continuing help. – Ric Jan 11 '22 at 04:40