Please fill out as many of the following questions as possible so we can help you promptly! If you don’t know how to answer or it does not apply, feel free to remove it or leave it blank.
Builder content link
Builder public api key
bd9e6ed9dc9f4142b7fecad85772af5e
What are you trying to accomplish
the site i want to edit requires login via OAuth/OIDC (using Auth0 as my provider). in order to view any content on this site, you first need to login via a form hosted by Auth0. as soon as you make a request to a page you wish to edit, you first need to authenticate via the typical OAuth redirect and callback process. when i try to edit a page, i can look in the browser console and see that the editor is trying to proxy the site i want to edit, the url it tries to load looks like this:
and this is where everything breaks down completely. as a security measure, Auth0 prevents the login form from being embedded in an iframe. pretty obvious security measure, you don’t want any possibility of a bad actor wrapping the form in something that is trying to intercept clicks and keypresses. i am able to see the first part of the login challenge from Auth0 here, but i am unable to fill in the form and login as all keypresses get intercepted/swallowed. as soon as you click into a form field, the focus is immediately blurred, kicking you out of the form. so i can’t login, i can’t edit the page.
preview works just fine since that kicks out a separate window that accesses the content via a url at the site itself without going through the builder.io cdn proxy and i can just login normally.
i can’t believe that i am the first to try this. certainly there must be some sort of workaround for this>
After a bit of exploration and experimentation, it finally dawned on me what was going on here, why I was running into this issue and what needed to be done to work around it.
There is no way around this without faking out the browser via a custom browser extension that can manipulate requests. Due to browser security rules for first/third party cookies in iframes, the browser won’t send any Secure/SameSite=Lax cookies for the domain of the page embedded in the Builder UI. You need to add them to the request headers on the fly.
In the end, I wrote a Chrome extension that captures the necessary Cookie header from the preview site before a user enters the Builder.io app to edit it. Then it makes sure that the necessary Cookie header is set on any requests to the preview url view within the embedded preview iframe. Works great.
Happy to share the solution with anyone else who gets stuck on this one…
A password-protected site within the builder iframe typically requires setting up a session or cookies to authenticate therefore it doesn’t work. If the Chrome extension doesn’t help then
You might have to remove the password to work within the builder.
Thanks for the response. I eventually found the “Enable Preview iframe form submission” setting on my own, I have been using the Chrome Extension as well. I learned a lot by examining the extension.
The extension alone wasn’t sufficient. It assumes you are going to perform a login via a form in the preview iframe and then tries to capture the cookie that gets set once you authenticate and then re-writes the cookie, setting the SameSite attribute to None so it can be passed along when a page is loaded from a referrer outside of its domain. This did not work for me for some reason, perhaps I just have very strict rules around cookies in my app. This cookie rewriting also seems somewhat insecure. I wouldn’t want that cookie containing my credentials to potentially be broadcast to every other site I visit. And finally, when I want to jump into the Builder.io editor I am already on the site in question and logged in. Why should I have to login again a second time, or again each time I return to edit a different page? I just want to forward the cookie through the iframe to my app while I am in the Builder.io UI.
So that is what my extension does, it obviates having to login again at all. Once I have logged in to environment where I do my content editing, it captures the cookie that the browser sends in each request and creates a declarative net request rule that sets the cookie in the request whenever it sees a request sent to my domain with an initiator coming from an builder.io domain. A slightly lighter weight solution and I believe a more secure implementation as well. All it needs is a configuration for the domain of the app you want to wrap in the Builder UI and it could work for anyone.
