I’d like to use the carousel component to rotate between some web based (tableau) reports, I can only do this in Chrome if I use the ‘ignore x frame options’ browser extension:
https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe?hl=en-US
I was hoping that this would be enabled by default in Workstation, but it doesn’t appear that we have this ability. Could it be added as an option?
I assume you noticed this paragraph on that extension's page:
Should be used only temporarily and only for developement, testing, or troubleshooting purposes because it disables important browser security mechanisms.
Having such a feature easily added to what is supposedly a secure end-user app strikes me as problematic. Tableau is certainly putting in those headers for a reason.
Yes, for a general purpose browser having this on all the time would expose you to ‘click-jack’ exploits. From what I understand this is essentially putting a real webpage in an inline frame, and then harvesting the users input such as usernames/passwords. Nothing is stopping anyone from making a website that attempts this; I think no one does because we all know the browser will refuse to show the webpage in the inline frame.
If I only let the end users see websites that I trust, such as my company’s internal tableau server, I don’t see the big deal. Right?
I could see this being added as something you could opt in to, but it’s pretty unlikely we’ll enable it by default.
That’s exactly what I’m looking for. 
I’m rather concerned about this in Workstation. At a minimum, the ‘opt-in’ needs to be a delivered by the gateway to a private API, not something configurable in the local install of Workstation. Even with this level of control, it seems easily exploitable with simple hosts file entries and a proxy to attack any desired site. If somebody wants to play games with an internal server, they should be modifying that internal server.
Not sure I agree, because then a 3rd party could embed our Tableau login screen in an inline frame then use a click-jack style attack to scrape off their username/password (if somehow they were able to get on our network). If it was bypassed on the ignition side, then inline frames are still not allowed for everyone else accessing Tableau from their normal web browser, this seems more secure to me. Workstation won't be used as a general purpose web browser for checking email etc.
I do agree that the mechanism to enable this feature shouldn't be easily exploitable.
In Tableau, you can set a Content Security Policy that explicitly allows your Ignition server’s domain. (I’m not that familiar with the exact format…) That would be the most secure.
I’ll agree that a CSP/putting middleware between Ignition and Tableau is the better solution, I think there’s something here. I filed an internal ticket to foster some discussion, but it’s perfectly plausible it gets shot down completely.
Thanks guys. Pturmel, your suggestion to approach it from the Tableau side was fruitful. It appears that there is indeed a way to structure the Tableau URLs so they can be embedded, which is what I needed.
On the other hand, having more flexibility in embedding all kinds of webpages would be great going forward. Especially if there is a nice secure way to do it.
I think the struggle is that a lot of users (including me) are more or less used to being able to do this inside of Vision, and it’s not an issue there because each component is it’s own Web Browser.
It’s a hard break going from a local app that can have multiple browsers within it to a single web browser that is trying to have multiple nested sites. The latter is the source of much security headaches, but is fundamental to a webby view of the world.
@PGriffith Was there any update to this as potential option? Our plant HMIs run workstation and we've run into the same issue with Rockwell's Pavilion8 web pages.