Problem with iFrame

Questions
1

Hi,

Running Servoy 2023.03-LTS on Tomcat 9.0.95

We want to expose part of our application to a third party partner, where they will display the application in an iFrame within their application, which is running on https.

Following along with Running in an iFrame | Docs

Our application (demo2.com from the Servoy doc) is running in our Test environment, with https.

From my localhost running through Servoy Developer, I can utilize an iFrame within an html page, and access our application running in the Test environment.

Our partner is working toward achieving the same result, but it isn’t working quite yet, as we’re having some troubles (see below).

I believe servoy.ngclient.contentSecurityPolicy.frame-ancestors is configured properly (though I’ve asked them about their port #), pointing to their domain (demo1.com from the Servoy doc).

They’ve set 3rd party cookies in their browser, to allow our Test environment domain (demo2.com). All signs from their side indicate everything is ok, other than the SameSiteCookies configuration:

As per instructions, I am adding a context.xml file to META-INF (during the export of our .war file). The context.xml file contains:

<Context>
   <CookieProcessor sameSiteCookies="none" />
</Context>

I have adjusted our /opt/tomcat9/conf/server.xml file to include secure=“true”, like this:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
					 maxThreads="150" SSLEnabled="true" secure="true"
					 maxParameterCount="1000" >
		<SSLHostConfig>
				<Certificate certificateKeystoreFile="conf/xxx.xxx.com.jks" 
										 certificateKeystorePassword="xxx"
										 type="RSA" />
		</SSLHostConfig>
</Connector>

Not sure if that is correct, so as a second attempt, I’ve tried adding this:

  <cookie-config>
      <http-only>true</http-only>
      <secure>true</secure>
  </cookie-config>

to /opt/tomcat9/webapps/qfi/WEB-INF/web.xml

When I deploy the .war file, containing the new META-INF/context.xml file setting the sameSiteCookies=“none”, our application becomes inaccessible, with this result in the browser:

“Disconnected from server. Reconnecting…”

and in the log file:

2025-05-29 01:37:50,348 WARN [https-jsse-nio-8443-exec-7] org.sablo.websocket.WebsocketEndpoint - Cannot find httpsession for websocket session, server restarted or client was suspended by the browser/os and did a websocket reconnect after the client was already destroyed at the server? clientnr=11, winnr=1, winname=null, connectnr: [8623153446088] [ ]
2025-05-29 01:37:51,047 WARN [https-jsse-nio-8443-exec-3] org.sablo.websocket.WebsocketEndpoint - Cannot find httpsession for websocket session, server restarted or client was suspended by the browser/os and did a websocket reconnect after the client was already destroyed at the server? clientnr=11, winnr=1, winname=null, connectnr: [2156528088158] [ ]
2025-05-29 01:37:51,755 WARN [https-jsse-nio-8443-exec-5] org.sablo.websocket.WebsocketEndpoint - Cannot find httpsession for websocket session, server restarted or client was suspended by the browser/os and did a websocket reconnect after the client was already destroyed at the server? clientnr=11, winnr=1, winname=null, connectnr: [6066023230337] [ ]
2025-05-29 01:37:52,493 WARN [https-jsse-nio-8443-exec-6] org.sablo.websocket.WebsocketEndpoint - Cannot find httpsession for websocket session, server restarted or client was suspended by the browser/os and did a websocket reconnect after the client was already destroyed at the server? clientnr=11, winnr=1, winname=null, connectnr: [6557163519540] [ ]
.
.
.

In Apache Tomcat 9 Configuration Reference (9.0.105) - The Context Container I see a note regarding ‘naming’ that if autoDeploy or deployOnStartup are performed, then the context.xml file ‘may not’ be defined in META-INF/context.xml. So in case that was the problem (as we have autoDeploy=“true”), I have tried two other options to add the sameSiteCookies config:

  1. adjusting /opt/tomcat9/conf/context.xml
  2. adding /opt/tomcat9/conf/Catalina/localhost/[warFileName].xml

For both options, the same websocket problem occurs as above, with the application becoming inaccessible. Removal of

<Context>
   <CookieProcessor sameSiteCookies="none" />
</Context>

immediately fixes the application for browser accessibility.

Perhaps obviously, we need to be able to access our application normally through a browser in addition to the iFrame access, so we have not yet tested the iFrame functionality when setting sameSiteCookies.

Any thoughts are appreciated.