Embedding a Q&A in an iframe on a https page

James · March 25, 2025, 12:07pm

I have created a link to a Q&A and clicked “Allow to show in an iframe”.

When I include the iframe on a page served over https then the browser gives an error:

Mixed Content: The page was loaded over HTTPS, but requested an insecure frame ‘Clause9’. This request has been blocked; the content must be served over HTTPS.

The magic link that was created was a https url, however when I request the url via curl I can see that the https redirects to a http url:

* Request completely sent off
< HTTP/2 302
< alt-svc: h3=":443"; ma=2592000
< cache-control: no-cache, must-revalidate
< content-type: application/octet-stream
< date: Tue, 25 Mar 2025 12:00:32 GMT
< location: http://sandbox.clausebase.com/app/qna

I think it is this https → http redirect that is preventing the iframe from being embedded.
If I embed the iframe in a page that is served over http then the embedded iframe loads and works as expected.

mtruyens · March 25, 2025, 10:28pm

That’s odd.

My initial hunch was that it was perhaps related to the fact that you’re using the Sandbox, but when I did a quick test, everything seemed to work.

Do I understand correctly that you’re trying to directly refer to /app/qna ? Because that will not work; instead, you need to generate an URL at /ml/... using the /document_login_url endpoint of the REST API.

For security reasons, I’ll send you a small sample file over email to test whether some sample URL is working.

Maarten

James · March 26, 2025, 10:03am

Thanks Maarten.

I can confirm I’m using the URL returned by the /document_login_url as the src of the iframe.

I can replicate the issue with the html file you sent via email. Eg.

Serve the html file over http:

python -m http.server 8300

Visiting http://localhost:8300/test.html works as expected.

(I can’t include the screenshot as it only lets me include 1 media item)

Serving the file over https, in my case I opened a Tailscale funnel to port 8300:

tailscale funnel 8300
Available on the internet:

https://xxxxx.tail36379.ts.net/
|-- proxy http://127.0.0.1:8300

Visiting the page:

I believe this is because of the redirect that happens to http when using a URL that is returned from /document_login_url:

curl -v https://<url from document_login_url>

....
< HTTP/2 302
< alt-svc: h3=":443"; ma=2592000
< cache-control: no-cache, must-revalidate
< content-type: application/octet-stream
< date: Wed, 26 Mar 2025 10:00:34 GMT
< location: http://sandbox.clausebase.com/app/qna

mtruyens · March 27, 2025, 7:59am

Apologies, you were completely right: at some point an HTTP request intervened. This is now corrected.

James · April 2, 2025, 6:26pm

Hi Maarten,
After the changes which fixed the https → http problem I’m still unable to get the embedded iframes working correctly. The issue is somewhat obscured by me observing different behaviour in different browsers which I don’t fully understand the root cause of at the moment.

I am using the UI to create a link to a Q&A, making sure “Allow to show in a iframe” is ticked, and I use this as the src of an iframe. These links have the form https://sandbox.clausebase.com/ml/___________.

If you use curl to make a request to one of these links you will see:

< HTTP/2 302
< alt-svc: h3=":443"; ma=2592000
< cache-control: no-cache, must-revalidate
< content-type: application/octet-stream
< date: Wed, 02 Apr 2025 13:07:42 GMT
< location: https://sandbox.clausebase.com/app/qna
< set-cookie: <redacted>
< strict-transport-security: max-age=31536000; includeSubDomains
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-xss-protection: 0; mode=block
< content-length: 0
<
* Connection #0 to host sandbox.clausebase.com left intact

Notice that the response has the header x-frame-options: SAMEORIGIN. I think this is incorrect and is the issue that is preventing the iframe content from displaying.

You sent me a test html file via email that contains an iframe with the src set to one of these https://sandbox.clausebase.com/ml/___________ urls.

The bit I don’t understand is that if I open this html file in Chrome then it works, I can see the content from the embedded iframe.

However, if I open the html file in Safari then the embedded content doesn’t load and I see the following in the JS console:

Refused to display 'https://sandbox.clausebase.com/app/qna' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

Moving away from the example html file that you sent. If I try and embed a Q&A in an iframe in my web application and load it in Chrome then I also see the error:

Refused to display 'https://sandbox.clausebase.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

So I’m unsure why Chrome is happy to load the iframe in the example html file that you sent, but not in my application. I was exploring whether there were some content security policies coming into play, but I haven’t been able to get to the bottom of it.

Regardless, I am pretty confident that the https://sandbox.clausebase.com/ml/___________ urls should not be returning the header x-frame-options: SAMEORIGIN and the issue of the iframe content refusing to display is always present in Safari, even in the example html file that you provided.

mtruyens · April 2, 2025, 8:13pm

You’re right that Safari apparently stumbles over the x-frame-options, while Chromium-browsers & Firefox apparently don’t have a problem with this.

This can be easily solved, but the standard “Prevent cross-site tracking” option of Safari is a thornier issue, as it prevents some cookies from being stored, because the domain they originate from is not directly being interacted with by the user. We’re figuring out a solution.

James · April 3, 2025, 9:48am

After some further testing I now understand why I was seeing different behaviour in Chrome. It’s because I was loading some pages in an Incognito version of Chrome and some in a non-incognito instance. The behaviour of the browser changes depending on whether it is incognito or not.

If I load the example html file that you sent me in an incognito instance of Chrome then the embedded iframe does not work. If I load the same file in a regular instance of Chrome the embedded iframe works. In Safari the embedded iframe doesn’t work at all.

I know you probably know this already, but I am just clearing up my confusion from yesterday where I was seeing it sometimes work in Chrome and sometimes not - it was down to the incognito instance.

mtruyens · April 3, 2025, 10:06am

The problem is related to the complex interactions between cookies and iframes, where it seems some additional restrictions have been applied in recent years (other than your attempts, none of our customers use Q&As inside of an iframe).

To resolve this issue — on Safari it’s really non-obvious, due to the advanced privacy-preserving techniques that Apple introduced — we’re currently investigating a cookieless-approach for the magic links. We can hopefully provide you with a new version somewhere today.

mtruyens · April 4, 2025, 1:14pm

This should now be resolved.

We have now created a special URL at https://xxx.clausebase.com/tl/… (instead of the …/ml/…) that allows for cookieless-logins when inside iframes. When you create an iframed magic link using the /document_login_url , it will automatically use that …/tl/… URL.

This cookieless approach seemed like the only viable solution to make sure that Safari didn’t incorrectly qualify our harmless cookies as third-party advertising cookies when used inside of iframes.