Embedding Session in a Webpage

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?

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?

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?

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:

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.

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?

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.

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

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.

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.

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…

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

1 Like

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.

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.

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

I think we’re all good to go on this, so thanks for all your help Joel! Here’s the link to the public project that we’re going to be embedding on our website: https://met.norcalcontrols.net/

Awesome - what was the root cause of the last issue? (the infinite redirect issue)

Did you simply leave all of the settings disabled (as mentioned in your second-to-last post)? (if that’s the case, I’m wondering how your cross-origin iframe is working…unless you abandoned that approach?)

This was happening when I visited the gateway directly, not through any proxy or embed. The infinite redirect was triggering anytime I went to login to the gateway through my IDP. The IDP was an ignition internal IDP. I required IDP authentication to do anything on the gw webpage, including viewing the home tab, but for some reason when those settings are enabled, I can’t even go through authentication as the page keeps redirecting to itself over and over until TOO_MANY_REDIRECTS is thrown. Disabling those settings worked, and once I disabled them I added a new certificate to the gateway and then re-enabled them. I’m not sure if that clears anything up though. If I could hazard a guess, maybe the servlet that provides that page keeps appending the Location header and returning 302 if those flags are set in ignition.conf, except since there’s no secure IDP route once you disable SSL, it defaults to using the insecure route instead?

huh, weird. were there any seemingly related exceptions in the gateway logs when this issue occurs? and is this issue still happening after installing the new cert and re-enabling (un-commenting) those settings?

if the issue was only temporary, we have seen this before when navigating to the Gateway using both http and https URLs, which causes conflicts with the session cookies, since session cookies in https requests will have a secure flag set on them, and browsers will refuse to send the cookie over http until the browser is closed / cookies and cache are cleared. A similar dynamic can happen when installing a new web server new SSL cert.

Before I disabled the settings, nothing I tried was working to let me into the gateway. I tried clearing cache and deleting cookies several times, with no resolution. I was effectively locked out because login attempts kept redirecting in a loop. If I re-enabled the settings, the issue came back, and then adding the certificate and re-enabling the settings caused it to no longer happen. This leads me to believe that it might have been related to those settings, but I can’t say for sure. I cross-referenced the time I was locked out in the logs, and I didn’t find anything relevant unfortunately.

Ok, thanks for the info / checking the logs.