Infinite query requests when Blitz app loaded inside an iframe

[divpreet]

What is the problem?

Running a blitz app inside an iFrame leads to infinitely loading queries.

The queries keep repeating themselves and error logged from onSettled method shows a CancelledError.

We have our application running in various environments eg. as a browser app, as an iframed app inside another application.
Once we upgraded the app from 0.38.2 to 0.38.3, we notice the app never finishes when loaded in an iframe.
The issue still exists in version 0.41.0.

Reverting the changes done in 0.38.3 for #117 in rpc-client.ts seemed to fix the issue but the files have since been changed and moved so I haven't even been able to find out what still causes the issue.

I have tried loading the app in codesandbox.io to test if the parent application could have caused the issue, but the issue still exists.
The issue can also be seen by creating a new app using the quick start steps, running it in dev mode and opening it in codesandbox.io

Please let me know if I can provide any more details that might be helpful.

Paste all your error logs here:

No error logs in particular apart from the CancelledError

Paste all relevant code snippets here:

What are detailed steps to reproduce this?

Create a new blitz app from scratch following the Quick start steps

1. blitz new myAppName
2. cd myAppName
3. blitz dev
   View your brand new app in an iFramed page like codesandbox.io using - http://localhost:3000

Run blitz -v and paste the output here:

% blitz -v
macOS Big Sur | darwin-x64 | Node: v14.18.0

blitz: 0.41.0 (global)
blitz: 0.41.0 (local)

  Package manager: yarn 
  System:
    OS: macOS 11.6
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 1.14 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.18.0 - ~/.nvm/versions/node/v14.18.0/bin/node
    Yarn: 1.22.5 - ~/.volta/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.18.0/bin/npm
    Watchman: Not Found
  npmPackages:
    @prisma/client: Not Found
    blitz: 0.41.0 => 0.41.0 
    prisma: Not Found
    react: 18.0.0-alpha-6ecad79cc-20211006 => 18.0.0-alpha-6ecad79cc-20211006 
    react-dom: 18.0.0-alpha-6ecad79cc-20211006 => 18.0.0-alpha-6ecad79cc-20211006 
    typescript: 4.4.3 => 4.4.3 

Please include below any other applicable logs and screenshots that show your problem:

[Jaxenormus]

I also ran into this issue when my app was ran inside of an iFrame on version v0.40.0

[flybayer]

Well that is weird... Btw here's the new code location: https://github.com/blitz-js/blitz/blob/canary/nextjs/packages/next/data-client/rpc.ts#L142-L154

[divpreet]

Ah I had found where the new location for the code was, I meant I was still seeing the issue after changing that piece of code back to how it was in 0.38.2 and couldn't find what would still be causing the issue.

[Jaxenormus]

I can confirm that 0.38.2 works and I can embed my app, but I'll wait to have 0.41.1 fixed

[Jaxenormus]

Is there any possible workaround for this @flybayer?

[flybayer]

Solution (I think)

The core issue is that the auth cookie is not being saved, resulting in a brand new session being created on each request.

Add sameSite: 'none' in your sessionMiddleware config in blitz.config.ts so that the third-party cookie can be saved.

  middleware: [
    sessionMiddleware({
      cookiePrefix: "blitz-auth-example",
      isAuthorized: simpleRolesIsAuthorized,
      sameSite: "none",
    }),
  ],

But: it will still not be saved in development with http. It will only work on the production site with https.

Assuming this works, we just need to document usage with iframes

[divpreet]

Sorry, had been pretty busy the last few days. I don't think this resolved my issue even when I run it in production mode. But I ll try out a few things and see if this is somehow related.
Interested to see if this solved it for @CalebDelbridge

[Jaxenormus]

@divpreet I haven't thoroughly investigated it, but it did solve my issue

[divpreet]

Ok I think I was able to make it work after jumping through a couple of hoops.
In addition to sameSite: "none", I also needed to add secureCookies: true

And instead of running the app on http://localhost:3000, I had to run it on https://127.0.0.1:3001 as secure is not added for localhost as the hostname, which I found out from the PR blitz-js/blitz#2361
PS. I added a proxy to forward all requests for https: 3001 to http: 3000.

@flybayer it might help people if we could document the secureCookies flag as well and the fact that it won't get applied for localhost. Also, just for my knowledge, why are we not adding it for localhost?

[flybayer]

@divpreet yes great point! Want to open a PR to the docs?

Setting secureCookies by default on localhost would degrade DX for most people in development, right? Been awhile since I looked at this so not sure.

[MrLeebo]

Right, making cookies secure in dev would cause the session cookie to not be issued on most developer's machines since dev is generally run without SSL, but it seems weird that the isLocalhost() check ignores and operates outside the purview of the secureCookies config; presumably if you're adding that option then you're also taking responsibility for defining what it should be in each environment.

If your app is running behind a load balancer/reverse proxy, another option is to configure the proxy to rewrite the Secure/SameSite flags on all cookies as they go out, that way you won't require any special configurations in your application code.

Plus, it acts as a safety net, if a new feature involving cookies gets introduced later, it'll always have the appropriate flags thanks to the proxy regardless of whether the developer who wrote the feature is aware of the cookie rules.

[divpreet]

@flybayer sorry I had been a bit busy last few days.
I will create a PR to the docs soon.
Shall I close this issue for now?

[beerose]

@divpreet I'm going to close this issue, but I created one in the docs repo to keep track of the docs change: blitz-js/blitzjs.com#614

[bmatzner]

While setting

      sameSite: 'none',
      secureCookies: true,

does work for Chrome and Firefox, it will not resolve the infinite query attempts in Safari when loading a query inside an iframe

https://stackoverflow.com/questions/59754345/reading-cookies-with-samesite-nonesecure-from-iframe-in-safari-13

I understand there is no workaround except not to load queries from within an iframe in Safari.