Embedding Session in a Webpage

Ignition
,
1

I'm creating a project that will be used for advertising purposes on our website. I've setup my project with some Perspective views and configured the views to Public security. When I navigate to the endpoint for my session directly, Perspective loads and everything is displayed as normal, but when I embed the session into a very basic HTML page, it did not initially load due to it's X-Frame-Options being set to same-origin. To resolve this, I used this article from the support website to disable all the CORS security options because they won't apply here, as the data is meant to be open and public:

# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
wrapper.java.additional.2=-Dignition.http.header.referrer_policy.enabled=false
wrapper.java.additional.3=-Dignition.http.header.x_frame_options.enabled=false
wrapper.java.additional.4=-Dignition.http.header.x_xss_protection.enabled=false
wrapper.java.additional.5=-Dignition.http.header.x_content_type_options.enabled=false

which allowed the Perspective session to at-least begin loading. After that change though, it appears that the session fails to initialize, but I'm not sure why or if i've missed another security option somewhere. Here is the browser error message, for reference:

image
image872Ɨ393 10.7 KB

and the basic HMTL file that I'm using to load the session embedded, for testing:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title
</head>
<body>
<iframe src="http://192.168.57.8:9088/data/perspective/client/Web" style="position:fixed; width: 100%; height: 100%;">
</body>
</html>

Version is 8.1.9, Ignition is running inside the official IA docker containers, on a Ubuntu bare-metal server.

2

Which URL do you use to load the web page with the above HTML source?

3

Hi Joel, Iā€™m loading it as a local file with the following in my URL bar: file:///C:/Users/swratten/AppData/Roaming/JetBrains/PyCharm2021.2/scratches/test.html

4

Thereā€™s a decent chance that your browser wonā€™t allow the cross-protocol connection to go through. Usually thereā€™s more clear errors in that case, but what if you ā€˜serveā€™ your HTML file via HTTP using a webserver? If youā€™ve got a local Python install, you can use the http server module, e.g. python -m http.server for a simple test.
Or, actually, PyCharm should even have an option to serve it directly - do you have browser icons like this in the corner? image

5

In addition to what Paul said, if the origin of your parent frame is not the same as the origin of your child frame, you may still have problems until you use https:// for both the parent and child frame URLs (which will set Ignitionā€™s session cookieā€™s Secure flag), and set Ignitionā€™s session cookieā€™s SameSite attribute to None as I believe modern web browsers will not allow third-party cookies unless those conditions are met.

-Dignition.http.session.cookie.same-site.enabled=true
-Dignition.http.session.cookie.same-site.value=None
6

Ok, so I tried to do both of these things. Neither worked on their own or together. For the webpage, I deployed nginx in my docker daemon to serve that static test html file and it was causing the same issue. (I tried the PyCharm deploy as well, but either their docs or wrong or Iā€™m doing something wrong because it only appears to deploy as a local file). As well, I modified the gateway conf file with those additional parameters and it did not appear to change anything even after a gateway restart.

7

So both the parent and child frames are pointing to https:// (secure) URLs? Are you getting the same exact errors in the console log as you originally posted?

8

So I tried a new configuration where the gateway has a configured SSL certificate (self signed), and the web page that I was trying to view provided by nginx over https as well, and once I lined up all the proper ports and proxying, it did work. But I guess my question is, if I disable the X-Frame options, I was under the impression that my browser should allow that content to load, and it does, but it seems like the request that the page makes to the gateway is refused, probably because of some security on the gateway itself, but is there any way around that? I can generally reach my session over an insecure http connection, but why can I not do it once that content is embedded, even if all the routing is the same?

9

When you say that the request is refused...how does this manifest in your web browser? What does the page look like? Are there any new errors in the browser console? How about the Gateway logs?

10

When this was happening, the perspective session begins to load and it gets to the ā€œAuthenticatingā€¦ā€ step, but pauses, and checking the browser logs shows a WebSocket connection failure:

image
image836Ɨ392 10.8 KB

so it seems like I can load the statically provided content of the page, but as soon as we try to establish the web socket to start loading resources, it fails.

11

Does the network tab in chrome dev tools give any additional information for this failed web socket connection attempt? Do you see an error in your browser console logs (in addition to the one you posted) with a message like Error trying to connect websocket to ${host} along with a detailed error message?

Is the web browser connecting directly to Gateway, or is it also going through a reverse proxy of sorts?

12

When I looked through the networking and issues sections of Chrome dev tools, I noticed that it was complaining about the same-site cookies being sent, and re-enabled them in my ignition.conf to send None, I was able to reach the session via the embed in the file. But this made it not possible for me to launch an insecure session over my http port. I then tried to launch a session via the secure port, and that worked as well. Am I just going to have to pick one protocol and use it depending on how I configure the cookie options?

When Iā€™m connecting, itā€™s directly to the gateway, and the html file that Iā€™m using also embeds via the direct URL. I can configure it to proxy through the nginx web server instead (and this is likely going to be our final architecture for security sake anyway), if you think that would help.

A final note, the Ignition gateway is running inside a docker container, and the ports are mapped to non-default ports, (9088 and 9043 instead of 8088 and 8043), if that makes any difference.

13

In this case, I think you need to disable X-Frame-Options, enable SameSite attribute on the session cookie, and set the SameSite attribute to a value of None in addition to accessing both parent and child frame over secure https in order for the web browser to allow the perspective page to operate properly in a cross-origin iframe. Sounds like you are confirming that this configuration is working out for you, right?

Which port you use shouldnā€™t matter, and whether or not you use a reverse proxy such as nginx shouldnā€™t matter either, so long as nginx is not blocking any headers that are sent back and forth between perspective client and gateway and nginx allows websockets and nginx is configured for https

14

Actually, adding the reverse proxy can cause issues if you do SSL termination at the proxy and connect proxy ā†’ ignition gateway with insecure http. In that case, the Gateway will consider the connection as insecure, and will not set the Secure attribute on the session cookie, which browsers require for pages embedded in a cross-origin context. Soā€¦when you do add a RP in front of the Gateway, you will need to do one of the following:

  1. Do not perform SSL termination at the proxy (proxy forwards TLS traffic through to the Gateway)
  2. If you do perform SSL termination at the proxy, then make sure the proxy connects to Ignition over secure https
  3. If you are on 8.1.10, you could opt-into the new ā€œUse Proxy Forwarded Headersā€ setting in Config > Networking > Webserver and then configure the proxy to send the appropriate Forwarded and/or X-Forwarded-* suite of headers so that Ignition will treat the connection as secure even if the connection between the proxy and Gateway is insecure.
15

I should be able to make that work. If I enable https on the gateway, do I need a CA provided certificate or can I get away with forcing nginx to trust the self-signed cert? Iā€™m relatively confident that this route wonā€™t be tampered with, but want to make sure that this transition wonā€™t cause Chrome to complain about a security issue.

16

Assuming you are talking about option number 2 in my last post, then you are correct: Ignition can use a self signed certificate, and nginx will need to then trust it. Nginx, however, will need a valid CA-signed certificate because that certificate will be seen by the browser, and the browser will only trust CA-signed certificates, unless you have control over your usersā€™ web browser trust storesā€¦

17

Ok perfect, yep that makes sense to me. Thank you for all your help!

1 Like
18

Hmm, I think Iā€™m running into something vaguely related to this. I removed my certificate from the gateway to add a valid CA signed cert but now every time I try to log into the gateway, it gives a TOO_MANY_REDIRECTS error. I used the dev tools again and the gateway is returning a page with a 302 and Location header that points back to the same page, which causes a redirect loop. Is there any way I can circumvent this? Iā€™m currently locked out of my (non-production) gateway.

19

Try clearing your browser cookies / cache and reload the page. If that doesnā€™t fix the problem, youā€™ll have to describe in detail the current state of your environment as it stands at this moment in order for me to have a chance to grok what might be going wrong.

20

Hey again, and thanks for helping out on this one. I tried clearing my cookies and clearing my cache, and even tried using Incognito to force a new session, but nothing like that seemed to work. I got it working again by disabling those additional settings in the ignition.conf file that were previously configured:

#wrapper.java.additional.3=-Dignition.http.header.x_frame_options.enabled=false
#wrapper.java.additional.4=-Dignition.http.header.x_xss_protection.enabled=false
#wrapper.java.additional.5=-Dignition.http.header.x_content_type_options.enabled=false
#wrapper.java.additional.6=-Dignition.http.session.cookie.same-site.enabled=true
#wrapper.java.additional.7=-Dignition.http.session.cookie.same-site.value=None

These settings were all previously enabled, and once I disabled and restarted the gateway, the redirect loop was no longer happening. Other than that, I donā€™t know much unfortunately! I just know that with these settings all enabled (uncommented), and after adding a self-signed certificate using the gateway wizard, and then deleting it, it caused that redirect error where the response contained a Location header that pointed to the same page that I was visiting. The URL and Location header looked something like this: http://192.168.57.8:9088/web/idp-log-in?8&token=eyJraWQiOiJrMSIsImFsZyI6IkhTMjU2In0.eyJyZXR1cm5UbyI6Ii93ZWIvY29uZmlnL3NlY3VyaXR5LmF1dGgifQ.fQmQrB1l9bZnkH-QitMx0sHcrQuCw4ycXKW_jLY6rmM