Search

Hi All,

Since upgrading to 2.5beta it seems that my site isn't letting my other site load a bit of it's page in an iFrame.

I know iFrame, but it's just google map with markers. Having checked I can't seem to load anything into the iFrame.

Is it a security change and how do I fix it? Something like JIT Trusted Sites?

Cheers

The XSRF work in the Symphony backend is in play so Cross site origin requests will potentially be refused access to the Symphony backend or is this front end content?

It's just a simple straightforward iFrame in the frontend of a site, but only the upgraded 2.5 version. The 2.3.x behaves as normal.

So, to be clear I'm saying the 2.5 site won't appear in an iFrame on another site or in a simple otherwise blank html file in localhost. I just get this appearing.

<head>
</head>
<body>
</body>

If I inspect in firebug.

Maybe something to do with htaccess, haven't looked in there but it should be the default.

Not sure what's up.

In addition, if an Access-Control-Allow-Origin or X-Frame-Options header has not been set on the frontend or backend, Symphony will automatically set this for you.

(From the Symphony 2.4 migration guide)

So it has nothing to do with XSRF protection; it is an additional security feature (rather related to clickjacking). Without doubt this is very good for the Symphony backend. One might argue, however, if adding these headers to the frontend by default is actually valuable. (Developers who really need this would probably know how to set these headers. Others, however, won't know how to unset them.)

To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.

Who ordered that?

Others, however, won't know how to unset them.

Erm?

It's a hack, but for me commenting out these lines worked:
https://github.com/symphonycms/symphony-2/blob/master/symphony/lib/toolkit/class.frontendpage.php#L238-L240

Maybe someone's got a more elegant solution?

Yep that'd work as it'd disable the header being set. I think you're meant to do it in an extension if you don't want to edit the core.

It turns out things are a bit messy at the moment because if you don't want to disable it altogether you can put ALLOW-FROM http://whatever.com or chain a bunch of comma-separated URIs there.

What I found is that ALLOW-FROM isn't working in all browsers, and if you put more than one URI in there, it works even less.

And, you do need to chain a bunch of URIs because once you take SAMEORIGIN away you'll have to put the address of the site itself as well as the site where you want to host the iFrame.

The truly elegant solution is to send just the data across and assemble it locally to create what you would have put in the Iframe. That would mean that you controlled and formatted the data so it could be "safe".

It's good, but browsers need to catch up, and we need to not like iframes anymore in the front-end. We have to consume>sanitize>output data where possible.

I think you're meant to do it in an extension if you don't want to edit the core.

Yes, that would be better.
I rarely make use of i-frames, this was kind of an exeption and no other way to do it, so not a big deal this little hack...

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details