Enterprise Client Community

...is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog

Stupid bug detected....:

Hi, unfortunately there is a bug in 20231127. The text "1" and text "true" are not correctly rendered in buttons and in labels wihtout width definition. You only see some 1px wide text...

The bug only occurs with these two strings. THere is no problem with strings containing "1" (e.g. "213") or containing "true" as a part of of the string.

There is a Maven version available fixing this issue: 20231130_INT - Of course this fix also is available with next Monday's update.

King regards! Björn

...is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog

"got it!"...

Way out:

1. Leave currentSessionTimeOut at "-1" and do not reset! ;-)

or

2. Initiate resetting of the timeout to its old value with an explicit request;

In other words, trigger the method via the client and then reset the timer in the ActionListener of this method. Triggering a method through the client is done by component CALLSERVERONTRIGGER:

Code:

 Page...:
 
 <t:beanprocessing ...>
     <t:callserverontrigger trigger="#{d.Xxx.longActionEndedTrigger}" actionListener="#{d.Xxxx.onResetTimeoutAction}"/>
 </t:beanprocessing>
 ...
 <t:button actionListener="d.Xxx.onStartLonnnnngAction" .../>
 
 
 Code:
 
 
 int m_currentSessionTimeOut;
 Trigger m_longActionEndedTrigger = new Trigger();
 public Trigger getLongActionEndedTrigger() { return m_longActionEndedTrigger; }
 
 public void onStartLonnnnngAction(ActionEvent event)
  {
      m_currentSessionTimeOut = HttpSessionAccess.getCurrentHttpSession().getMaxInactiveInterval();
      try
      {
          HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(-1);
          ...
          ... the lonnnnng processing
          ...
      }
      finally
      {
         m_longActionEndedTrigger.trigger();
      }
  }
 
 public void onResetTimeoutAction(ActionEvent event)
 {
     HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(m_currentSessionTimeout);
 }

Kind regards! Björn

...received following message on this topic...:

Unfortunately that didn't quite work for me yet.

I believe the problem is the following flow:

1. Initially set: currentSessionTimeOut := X sec.

2. At startup: setMaxInactiveInterval = -1

3. the long-running process runs through unmolested in > X seconds

4. then set again: setMaxInactiveInterval(currentSessionTimeOut) i.e. X sec.

5. but the “last access time” was not updated, so the time has now expired: remainingTime < 0 s

6. And so the session is apparently considered “invalid” the next time it is accessed. Error: a complete restart occurs

...we found the reason.

We changed the calculation of the device pixel ratio for Chrome with 20230612. (Thanks for your perfect analysis on the versions!)

Before we used "window.devicePixelRatio" which does not take into consideration the scaling that is applied by the operating system. So we changed to a way to acutally measure the screen size by measuring the outer width of the window against the inner width of the browser content (https://stackoverflow.com/questions/1713771/how-to-detect-page-zoom-level-in-all-modern-browsers).

In case of tabs which are "prepared" in the background (due to opening the browser with last opened pages) the width of the browser is passed back as "0"... So some calculations are wrongly executed with a wrong pixel ratio.

We will fix - for next update! (next Monday)

...we can reproduce on our side as well: activating Chrome's function "Start > Show last displayed pages" and having a grid in one of the pages will not show the scrollar of the grid...

Björn

(sent by mail > cont. processing in forum)

Some users have reported a problem with the display, that the height of the grid's rows are different than normal, and that the vertical scroll bar is missing.

I was able to reproduce the problem when I start our Captaincasa app in a browser tab without focus. Some of our users seem to load the last open tabs when starting the browser, then several instances of our MES application can be started at the same time without the TAB being in focus.

Browser is Edge (but should behave like Chrome)

The problem does not exist with version 20230605, but the problem occurs with version 20230612.

...just finished a Screensharsession in which the following problem was discussed...

1. A button in a dialog starts a processing on server side which takes long time (1 to 2 hours...)

2. The session timeout in web.xml is configured to 60 minutes.

PROBLEM The servlet engine ends the session after 60 minutes... The whole scenario is moved into some "confusing situation" as result.

WHAT ARE THE WAYS OUT?

The normal advice is: separate the long lasting operation into some own thread. And use control LONGPOLLING with websocket communication to observe this thread until it's finished. By observing the thread, regularly new http-requests are sent from the client to the server, which keep the session awake. (And of course: the user likes to continue to work or to at least be informed about updates on server side...)

In the concrete scenario this was not possible: the long lasting processing requires access to the http session. (You may discuss, if this is a really good idea... but the effort to change this, is not adequate.) So moving into another thread is not an option.

...the first idea, was to use the BlockerInfo messaging: by API BlockerInfo you can send a text and a progress message to the client which is shown in an info window. This is of course some "dramatic" increase of useability - but: it does not have any consequences for the session timeout. The BlockerInfo internally uses a WebSocket connection - and using a WebSocket is not considered as an activity to keep the session alive. Only receiving new http-requests are the ones to update the timeout management of servlet engines.

Finally the way to go for this scenario: use the HttpSession-APIs...

Code:

 public void onStartLonnnnngAction(ActionEvent event)
 {
     int currentSessionTimeOut = HttpSessionAccess.getCurrentHttpSession().getMaxInactiveInterval();
     try
     {
         HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(-1);
         ...
         ... the lonnnnng processing
         ...
     }
     finally
     {
         HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(currentSessionTimeOut);
     }
 }

So for the duration of the long processing you switch the session timeout to "inifinite" (-1) - and you reset it to the previous value afterwards.

Remark for super-experts: in case of session management by Cookies, it can happen that several requests are running in parallel! The "HttpSessionAccess.getCurrentHttpSession().setMaxInactiveInterval(...);" is used across these threads, so there is a multi-threading issue as consequence. In order to solve this, you just need to shift corresponding data to the HttpSession level - because that's the one which is the common object seen by all parallel threads. - The principle stays the same: deactivate the session timeout for the duration of the long operation.

For next update we added:

1. embedded pages inside CaptainCasa do not come with default "sameorigin" for "x-frame-options" - but with no seteting of this parameters (so they can be embedded in any scenario)

2. By system.xml you can explicitly override this. There are three catergories:
a. internal bridge pages (e.g. to chart.js, quill-editor, OSM, ...)
b. BufferedContent pages
c. TempFile pages
So if you (or some auditor) explicitly wants to see certain parameters then you can do so.

So the problem you raised should not occur anymore - while keeping the explicit configure-ability.

Kind regards! Björn

...goood question! ;-)

By default pages rendered by DefaultBufferedContent are returned with "sameorigin" as "x-frame-options" header parameter.

In your constellation I believe there is...
Code:

 Some outer page with IFRAME
     in which a .risc page is opened
         in which a PDF pages is created with DefaultBufferedContent

If your x-frame-otions are now set in the following way...
Code:

 (outest)
     "true" by system.xml
         "sameorigin" by DefaultBufferedContent

...then the PDF page will not be shown.

Currently the only way to overcome to override the following method within your DefaultBufferedContent extension...
Code:

     /**
      * In the default implementation the header parameter "x-frame-options" is set
      * to "sameorigin" so that the buffered content is not embed-able into pages
      * coming from some different host. You may override this behavior.
      */
     public void preProcessResponse(HttpServletResponse response)
     {
         ServletUtil.setResponseHeader(response,"x-frame-options","sameorigin");
     }

and set/not set the parameter properly. (In case you want to net set things at all you just override by:
Code:

     public void preProcessResponse(HttpServletResponse response)
     {
         // do nothing!
     }

This smells like some area of improvement.
In one of our next updates we can provide a configuration for the default that is curerently coded to "sameorigin".

Kind regards! Björn

PS: for other readers the security guide https://www.captaincasa.com/docu/eclnt_risc_securityguide/ contains all information "around"...

(mail copied into this forum - to the author: this is a great forum question, would be great to follow up communication here...!)

I have a question about the PDF renderer. Recently we can no longer display PDFs because “X-Frame Options” is set to “deny”.

I then updated our software to release 20220314.

So that we can theoretically display CaptainCasa Page in an IFrame set embedableasiframe="true" in the server.xml.

But how can I allow this for the PDFRenderer? The PDF is displayed in an IFRAME.

In the ChangeLogs I saw that you could overwrite the DefaultBufferedStreamContent class and adjust the header in the preProcessResponse method.

Is there another solution? And if not, how would I overwrite it so that the overwritten class is used?

...is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog

There was a problem with the RISC-setup.exe file that was uploaded with 20231113: it was internally flagged with version "20231113_INT1". Because of this we published 20231114 which is now correctly named.

There is no functional difference between 20231113 and 20231114.

Maven users do not have to update, it's only the setup-file (which you do not need when using Maven...).

Kind regards! Björn

..is available in the download area.

Details about changes: http://www.captaincasa.com/docu/eclnt_changelog