Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presentation in infinite "Loading" state (http local, https remote) #8748

Open
ChrisNolan opened this issue Feb 24, 2025 · 4 comments
Open

Comments

@ChrisNolan
Copy link
Contributor

If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.

Describe the bug

If you have a deployed studio which is configured to use a local server as the host, but the local server is 'http' and not 'https' the presentation tool gets 'stuck' infinitely 'loading' without any message about what the problem is.

The console files with

Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘http://XXXX-staging:3033’) does not match the recipient window’s origin (‘https://XXXX-staging.sanity.studio’).

To Reproduce

Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior

Some notice about what is wrong with the configuration rather than infinitely "Loading".

Screenshots
Image

Which versions of Sanity are you using?

@sanity/cli (global) 3.74.1 (latest: 3.77.0)
@sanity/code-input 5.1.2 (up to date)
@sanity/dashboard 4.1.2 (up to date)
@sanity/eslint-config-studio 4.0.0 (latest: 5.0.1)
@sanity/image-url 1.1.0 (up to date)
@sanity/preview-url-secret 2.1.4 (up to date)
@sanity/vision 3.74.1 (latest: 3.77.0)
sanity 3.74.1 (latest: 3.77.0)

What operating system are you using?

ubuntu?

Which versions of Node.js / npm are you running?

Run npm -v && node -v in the terminal and copy-paste the result here.

9.8 something and 22. something behind an nginx thingy. Technical, eh?

Additional context

Add any other context about the problem here.

Security issue?

Any security issues should be submitted directly to [email protected]. In order to determine whether you are dealing with a security issue, ask yourself these two questions:

  • Can I access something that's not mine, or something I shouldn't have access to?
  • Can I disable something for other people? If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [[email protected]](mailto:[email protected].
@stipsan
Copy link
Member

stipsan commented Feb 24, 2025

Hi @ChrisNolan,
This is indeed an unexpected state.
You should be seeing a timeout, like this:

Image
And a single message, like this:

hook.js:608 Unable to connect to visual editing. Make sure you've setup '@sanity/visual-editing' correctly

hook.js:608 Unable to connect to visual editing. Make sure you've setup '@sanity/visual-editing' correctly

Could you share your presentationTool() configuration?
And also tell us a bit more about how you're loading these origins? For security reasons we don't support an iframe redirecting to a different origin, the postMessage connection is privileged, the comlink protocol between sanity/presentation and @sanity/visual-editing supports RPC calls that can execute GROQ queries for live preview purposes and send them back.
Presentation Tool uses the URL origin you give it in your previewUrl configuration, and sets it as the targetOrigin when calling postMessage.
A mismatch between targetOrigin and the iframe.contentWindow.origin will lead to the error messages you're seeing.

For that mismatch to happen the iframe must be redirected somehow?

@ChrisNolan
Copy link
Contributor Author

Hi @stipsan I think I have a fairly straight forward setup presentation tool wise...

import { resolve } from "./resolve";

export const presentation = {
  previewUrl: {
    origin: process.env.SANITY_STUDIO_PREVIEW_ORIGIN,
    preview: "/",
    previewMode: {
      enable: "/api/draft-mode/enable",
    },
  },
  resolve,
};

Do you want my full resolve as well?
and that is just used at

  plugins: [
    dashboardTool(dashboard),
    structureTool({ structure, defaultDocumentNode }),
    visionTool({ defaultApiVersion: apiVersion }),
    presentationTool(presentation),
    media(),
    codeInput(),
  ],

My SANITY_STUDIO_PREVIEW_ORIGIN is simply SANITY_STUDIO_PREVIEW_ORIGIN="http://librarium-staging:3033" -- so I had expected it to only work when accessed by a machine on the local network (and it does work on the hosted studio running on the same machine but on a different port).

I can't think of how it would be doing any redirecting... the site at that preview_origin is just a nextjs app with normal routing as far as I know (does it do any hidden redirects?).

I just tried going straight to the presentation tab rather than clicking through via a 'resolve' link and see this in the log instead but the infinite spinner still.
Image

If it matters I used this options when doing the deploy: sanity deploy --source-maps --no-minify

@stipsan
Copy link
Member

stipsan commented Feb 25, 2025

Thanks, this is super helpful!
I think I understand what's happening. Although your configuration is correct, and Presentation Tool itself is lax on wether you use https or http in your previewUrl.origin, it looks like the browser itself is blocking the iframe from loading.
That would explain why you end up in an infinite loading state, since a blocked iframe would mean we won't get an onLoad event. I'll look into why it doesn't time out though, we should be handling this edge case.

In any case I think the solution for you is to run next dev --experimental-https so that the iframe can run on https://librarium-staging:3033 and this no longer be blocked when loading it on a Studio that is hosted by us using sanity deploy. More info

@ChrisNolan
Copy link
Contributor Author

Thanks for the reminder about --experimental-https ; I think I had tried it and it only worked connecting to localhost and not 0.0.0.0 so getting it 'out' of the container it was in wasn't working. But it was a busy time getting that deployed the first time and I'll take another look. I was also told there is a 'registry edit' to allow the browser to go to an http from an https but was told it shouldn't be done 'just in case' there was somebody nefarious out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants