Hey @backbeatjohn ,
Sorry for the delayed response. In general there is not an issue with OpenTicket’s itself that prevents it from working in an iframe. That being said, you are running into a browser security problem, unrelated to OpenTicket’s itself, which is specifically centered around the HTTPS sections of your site, like checkout. Let me explain.
It is a well known web development fact, that the parent page to an iframe, in most browsers, can edit the content of the iframe itself, in some scenarios. Some people would have you believe that this is not allowed, but I assure you it is allowed between any two domains that allow cross origin communication (for instance your site and twitter, when you have an authenticated session).
This causes a unique situation where the content of the iframe can be viewed, and even edited, by a page that is not HTTPS. This, in effect, completely circumvents the use of HTTPS, because now, an attacker does not need to overcome the SSL security (a very non-trivial task), but simply needs to exploit the page that includes the iframe, which is non-https. This is an obvious security problem, and has been classified as a ‘Man in the Middle Attack’ (there is lots of information available about these types of attacks in general, and if you dig, you can find this specific type of attack too).
Thankfully, most browsers prevent this type of situation now-a-days, because of two reasons. First, the one I already describe above, being able to circumvent SSL. Secondly though, is an equally important problem that most people don’t think about. The end user has no idea what site this iframe even shows, and in some cases, that it is even an iframe at all. This is obviously another issue, because the end user could be being told that they are going to your ticket sales website in the iframe, but they have no real way of verifying that. Thus if an attacker was to spoof your site, and then spoof the PayPal site for instance, and then attack your http page, replace the iframe with one pointing to their spoofed version of your site, they could in turn be stealing people’s credit card informations, because the end user has no way of knowing that they are not on actual PayPal.
Now that we know the problem, we can probably come up with a solution. One solution does come to mind. On your ticket sales website, you could have a small piece of javascript (on the ssl only pages) which detects if it is in an iframe. If it is in an iframe, it could open itself outside of the iframe, preventing this whole scenario from happening. You can find a very clear example of the javascript component of this idea on this page. All you would need to do now, is wrap that javascript in php, that only prints it on the SSL pages, something like this in WP:
function bbj_maybe_breakout_js() {
if ( ! is_ssl() )
return;
?><script> /* fancy breakout js here */ </script><?php
}
add_action( 'wp_head', 'bbj_maybe_breakout_js', 10 );
With this implemented, basically 90% of the entire ticket selection and verification experience would be in the iframe; however, once they finally get to the point in WooCommerce where they pay for their order, in other words they hit the checkout page, they will be thrown out of the iframe, so that the https page is in it’s own browser window/tab, meaning that they can actually complete the checkout now.
Another solution would be to simply have them go directly to the ticket sales website to purchase their tickets, instead of iframing it in. Obviously, your client may not like this solution, which is why I put it second, not first, even though it is in fact the easiest solution. If you could convince them to do this, perhaps their could be a branded part of the theater website, which has all their branding, making it look like it is basically their main site. Maybe that may help them choose this solution.
In any event, I am sure there are other solutions that could resolve the problem out there, but these are the two that come to mind. Understanding that the basic problem is not a software problem, but rather a browser security problem though, is paramount in finding a proper solution, and I think we have covered that.
Hope this helps,
Loushou
