Issue with sessions in iframes

[malexdev]

Hello!

My website has a main application, and sets of content loaded in an iframe.
The content of the iframe comes from a specific route in the application, so coming from the same domain/host.

However, when I set an express session, inside the iframe is a different session ID- something is making it set a new cookie.

I know there are issues setting "third party" cookies in an iframe, but this iframe is loading content from the same host. Does anyone have any idea what I could do to resolve this?

Thanks!

[joewagner]

Is it a different subdomain? Is everything/nothing https?

[malexdev]

It is the same subdomain, and nothing is HTTPS yet. The only differences are:

• The main application is a React app that is on http://localhost:3000/. After logging in, the server sets an Express session cookie.
• Users are able to choose from one of several different content areas, but they are all accessed via a route called /content in Express. All pages under /content are accessed via iframe.
• Middleware placed on /content is supposed to verify that users are logged in, however when said middleware accesses the express session object, it is a brand new session.

All pages under /content are plain HTML, nothing fancy. In fact, /content is actually just a statically served directory. It's served in an iframe because unfortunately when we took over this project all the HTML under content had been made with that in mind, and at this point that's 100,000+ files, so we plan to rewrite them over time to no longer need the iframe but for now we are trying to make it work like this if possible.

The middleware for authentication is really simple:

function handleLogin(req, res) {
  const username = req.body.username, password = req.body.password;
  db.verifyLogin(username, password)
  .then(authorized => {
    req.session.loggedIn = authorized;
    return authorized;
  })
  .then(authorized => res.status(authorized ? 200 : 400).send())
  .catch(err => res.status(500).send(err.message))
}

The middleware to check if they are logged in is similarly simple:

function isUserLoggedIn(req, res, next) {
  if (req.session.loggedIn) { return next(); }
  console.log('Redirecting session %s to /, not logged in', req.sessionID);
  return res.redirect('/');
}

Yet, if I log the session ID in both places, then I get two different session IDs:

function logRequests(req, res, next) {
  console.log('HTTP %s %s | Session %s', req.method, req.originalUrl, req.sessionID);
  next();
}

Returns something like (I'm not at work so I don't have the exact log, but it's similar to this):
HTTP GET / | Session abcd
HTTP GET /api/login | Session abcd
HTTP GET /content/about | Session zxcv
Redirecting session zxcv to /, not logged in

[shaunwarman]

What browser is this?
This happen's on the same domain? (e.g. requests from abc.com and abc.com/content?)
Do you see an obvious difference in the request headers cookie attribute?

I don't think you will need to ask the parent window for cookie information. The browser should see a request for a certain domain and append the cookie for you if the domain/path abide to the initial responses Set-Cookie header.

[shaunwarman]

I setup a quick and dirty express setup with express-session and iframe render.

It looks like, since the domain was the same, there were no issues picking up the cookie.

$ DEBUG=express-session node .

// initial request - no session
express-session no SID sent, generating session +1m
express-session saving jg3HJKTB_S4fkKMhvkJy49tCl1WyoGMr +0ms
express-session split response +0ms
express-session set-cookie connect.sid=s%3Ajg3HJKTB_S4fkKMhvkJy49tCl1WyoGMr.sRWls9WmUiV%2BdXJt%2FSWcnJ%2BkN%2FLg2bNM9woshkpZ8%2BE; Path=/; HttpOnly +1ms

// render iframe and hit /content of express app
express-session fetching jg3HJKTB_S4fkKMhvkJy49tCl1WyoGMr +24ms
express-session session found +0ms
express-session touching +1ms
express-session split response +0ms
express-session touched +0ms

[malexdev]

Wow, @shaunwarman, thanks for going to all this trouble.

With your help I've been able to track down the issue: our route that controls authorization was a little different than I remembered (when I provided the example code I was going from memory as I was not at work), and was forcing a session resave. However there was a bug in our session store implementation that was causing this to regenerate a new (blank) session.

We have not yet implemented anything else that will depend on the logged in session, so it looked like the issue was the iframes where in reality it was our log in process.

Sorry for taking everyone's time, and thanks for the assist!

[shaunwarman]

No problem at all! Glad you found the issue.