collective / volto-hydra

A volto addon to let you edit content in realtime when you have many frontends written in any framework
0 stars 2 forks source link

Real-time data update not working in deployed demo site #85

Closed MAX-786 closed 1 week ago

MAX-786 commented 2 weeks ago

The deployed site is not recieving the realtime updates, because if you try the main branch locally it works fine but the deployed one doesn't, I think it is because iframe is not recieving postMessage correctly or maybe it is an issue from frontend side idk, nd i tried to fix it but couldnt. Still looking into it.

djay commented 2 weeks ago

It's probably some CSP header or iframe security setting.

One thing though is that if realtime updates is not enabled then the UI should not allow add and remove etc to be enabled. and probably there should be a warning to tell the user that updates are not enabled and so you won't see a change until after save. Can maybe split that out to seperate card though?

djay commented 2 weeks ago

Is it not specifying the frontend domain but using "*" here? https://github.com/collective/volto-hydra/blob/d87c10ed24bbe44d4d78fd83d078518818598bb4/packages/volto-hydra/src/components/Iframe/View.jsx#L216

Other stuff talks about timing on adding hte event listening https://medium.com/@crookse/cross-domain-communication-parent-window-and-child-iframe-aaf90fcb3e26

and Cross-Origin-Embedder-Policy

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

djay commented 2 weeks ago

@MAX-786 your frontend doesn't have CSP or Cross-Origin-Embedder-Policy so both of those probably need to include the CMS domain to allow messages to be received?

MAX-786 commented 2 weeks ago

So I hope its not an issue with Hydra Side :) I'll try fix it on the frontend.

Yeppp might be better if somehow we tell the editor if the realtime editing is enabled or not. Lets discuss the 'HOW' in separate issue ig.

MAX-786 commented 2 weeks ago

Is it not specifying the frontend domain but using "*" here? https://github.com/collective/volto-hydra/blob/d87c10ed24bbe44d4d78fd83d078518818598bb4/packages/volto-hydra/src/components/Iframe/View.jsx#L216

Yes it had the origin of iframe src as recipient's origin, but the issue was intact so i tried removing it. Guess I'll revert it back to how it was and do the CSP fixing on frontend side.

djay commented 2 weeks ago

If CSp is the fix then don't forget to document it in the readme

MAX-786 commented 2 weeks ago

Figured it out! I was already working properly with CSP as i was using origin everywhere and it is already in docs as we ask to give adminOrigin as an argument when they initiate bridge. (no extra docs needed) The problem here was postMessage type:"FORM" because in the hydra.js it was recieving type:"FORM_TYPE" which was changed in one of the prev commit ( i can't track which one) corrected it now.

djay commented 2 weeks ago

@MAX-786 getting a new problem now I think

led to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://hydra-nextjs-frontend-git-production-max786s-projects.vercel.app') does not match the recipient window's origin ('https://hydra.pretagov.com').