Enterprise Client Community

Hi,

the web.xml filter/servlet information was moved into an API-based configuration 2 years ago... Since then we are telling "Please clean up the web.xml"! ;-) - The problem: there is a certain level of coexistence between web.xml configuration and API-based configurations. So problems only show up in certain scenarios.

One issue we found now in a certain usage-scenario: due to old web.xml configuration the sequence of filters that is applied may be a wrong one. In particular: if the "SecurityFilterGeneral" is executed after the "ThreadingFilter" then you will receive a session-check-id-error...

The problem was solved by cleaning up the web.xml.

All web.xml that is required by CaptainCasa is listed in the web.xml below. Please check your web.xml. - Btw: the web.xml configuration is stable since 2 years (this was exactly the main goal of moving into an API based configuration), so only "old" usage scenarios need to be checked for clean-uo.

Kind regards! Björn

Code:

 <?xml version="1.0" encoding="UTF-8"?>
 
 <!--
 	The default configuration of the servlet context is done in class
 	CCInitialiServlets. 
  -->
 
 <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
          xmlnssi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee <a href="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" target="_blank" rel="nofollow">http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd</a>"
          id="WebApp_ID" 
          version="3.1">         
          
   <display-name>CaptainCasa based application</display-name>
   <welcome-file-list>
     <welcome-file>index.html</welcome-file>
     <welcome-file>index.htm</welcome-file>
     <welcome-file>index.jsp</welcome-file>
     <welcome-file>default.html</welcome-file>
     <welcome-file>default.htm</welcome-file>
     <welcome-file>default.jsp</welcome-file>
   </welcome-file-list>
 
   <!-- ********** CONTEXT PARAMETERS *************************************** -->
 
   <!-- JBoss Deployment - use the reference implementation that comes
        with CapatainCasa by default -->
   <context-param>
     <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
     <param-value>true</param-value>
   </context-param>  
 
   <!-- ********** LISTENERS ************************************************ -->  
   <listener>
     <listener-class>org.eclnt.jsfserver.util.CCServletContextListener</listener-class>
   </listener>
   
   <!--
   PLEASE PAY ATTNETION: the registration of the CCServletContextListener in the web.xml
   is sufficient for many servlet engines (e.g. Tomcat). For other servlet engines (Glassfish,
   JBoss) the regsitration needs to be done through a file "META-INF/services/javax.servlet.ServletContainerInitializer".
   This file needs to be visible to the webapp classloader, i.e. needs to be part of WEB-INF/classes
   or part of one of the .jar libraries in WEB-INF/lib.
   <br><br>
   A template file is coming with CaptainCasa's eclntjsfserver*.jar file, here:
   "META-INF/services/javax.servlet.ServletContainerInitializer_template".
   -->
     
   <!-- ********** SESSION MANAGEMENT *************************************** -->
   <session-config>
       <session-timeout>60</session-timeout>
       <tracking-mode>URL</tracking-mode>
   </session-config>
   
   <!--
   Alternative session management via cookies. Also has to be configured in
   eclntjsfserver/config/system.xml!
   
   <session-config>
       <session-timeout>60</session-timeout>
       <tracking-mode>COOKIE</tracking-mode>
       <cookie-config>
           <http-only>true</http-only>
           <secure>true</secure>
       </cookie-config>
   </session-config>
   -->
   
 </web-app>

...is available in the download area.

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

Hi,

in our central "FileManager" we have this protection for not writing files with ".." inside... that seems to be the only issue against what you propose. We did this check for security reasons (you know: there might be e.g. a function to upload content and passing a file-name: by adding "../../../" the user might try to place a file in a directory which is not considered at all by the application processing...).

We can overcome this in the editor by directly transferring the "../"-directory into some real directory name without "../" which then is used internally.

Should not be a big problem, I expect this function to be part of next Monday's update.

Thanks! + Best wishes to you!
Björn

...is available in the download area.

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

(from mail conversation)

Problem: label and button texts end with "..." on some browsers. On other browsers they are correctly visible.

Solution:

Check the display settings of the browser. In Chrome/Edge there is a section "Schriftart anpassen"/"Font settings". In this section there is the possibility to define the minimum font size by a ruler-component. - Shift the ruler to the very left ("winzig"/"minimum size").

Background: with this browser option the browser may overrule font size settings by the application. E.g. the application defines a button font of font-size "12px". The browser settings overrule this to e.g. "13px". As consequence the label of a button does not fully fit inside and will be abbreviated by "...".

Kind regards! Björn

(from mail conversation)

A TABBEDPANE component with two tabs always opens the 2nd tab (which in this case contained a ROWPAGEBEANINCLUDE) - without having an explicit TABBEDPANE-VALUE management behind. How can this happen?

Solution:

The content of the second tab requested the focus! And if there is some element requesting the focus within an TABBEDPANETAB then the correspondign tab will be activated...

Hi,

some report on evaluation of scenarios on iOS in which there were problems with the security-id that is sent with requests as cookie:

There are problems on iOS-Safari - because Cookies of IFRAMEs are in general ignored and the browser does not send them into the IFRAME's application. Problems occur in https scenarios "only"... (there is no sending of Security-Cookies for http...), and they occur in scenarios "only" in which an embedded IFRAME-URL is loaded from some different origing than the outside page.

There are two ways out... (well, actually only one):

1. Switch off the "Avoid cross-sitetracting" in the iOS configuration (Configuration > Safari > Disable Cross-Sitetrackinh). Well, unfortunately you can only configure this on this very rough level (on/off) - you e.g. cannot configure on per-site base.

2. You need to arrange all the applications of your scenario that you want to access by IFRAME behind one origin-web-address. So, all applications have to be reachable by the same address https://yourserver:yourport - This normally means: arrange some server (Apache, HAProxy) in front of you server-applications which distributes the requests to the corresponding applications.

Kind regards! Björn

...is available in the download area.

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

Dear community,

thanks to all participants for coming to Heidelberg/Schwetzingen last week!

The slides are available here: https://captaincasa.com/pdf/20220602_CommunityMeeting.pdf

Kind regards! Björn

Hi Makis,

OK... - there is a way to find out, but it's not totally straight forward:

Any selection in the grid is done by calling:

Code:

 FIXGRIDBinding.onGridAction(ActionEvent ...)

You now can override this method for your grids (there are two FIXGRIDListbinding in your code - which are connected). In your implementation you first part the information which one is the active grid in youd page bean. Then you call the super.onGridAciton(...) method.

Now you can ask for the grid which was the one to initiate the current event.

Kind regards! Björn

Hi Makis,

first of all: why not assigning the popupmenu on the right side only.

Example:

Code:

 <t:rowdemobodypane id="g_1" objectbinding="#{d.DemoGridFixColumns2}" >
     <t:row id="g_5" >
         <t:splitpane id="g_6" dividercolor="#00000030" dividerlocation="150" height="100%" width="100%" >
             <t:splitpanesplit id="g_7" >
                 ... left grid ...
             </t:splitpanesplit>
             <t:splitpanesplit id="g_14" >
                 <t:row id="g_15" >
                     <t:arraygrid id="g_16" border="0" borderheight="0" borderwidth="0" height="100%" horizontalscrollmode="always" multiselect="true" objectbinding="#{d.DemoGridFixColumns2.grid}" rowpopupmenu="RIGHTGRID" sbvisibleamount="30" width="100%;200" />
                 </t:row>
             </t:splitpanesplit>
         </t:splitpane>
     </t:row>
 </t:rowdemobodypane>
 <t:popupmenu id="RIGHTGRID" >
     <t:menuitem id="g_18" command="CLEAR" text="Clear" />
 </t:popupmenu>

The POPUPMENU "RIGHTGRID" will only show up ion the grid where it is defined.

Kind regards! Björn

Hi,

thanks to Joris Kimpe we now know: openPdf is the official follow-on versopm of what before was iText 4. We tested in our scenarios and did not find any problems so far.

For those one who want to switch:

Code:

 <dependency>
 <groupId>com.github.librepdf</groupId>
 <artifactId>openpdf</artifactId>
 <version>1.3.27</version>
 </dependency>

Thanks to Joris! ;-) - Björn

Hi Klas,

the reason for these components is: pure compatibility with the Swing client. In the Swing client there was full access to the client's file system. - In the browser client (luckily) there is no knowledge about the client's file system. the controls serve as simple String-input components here.

Also, if you upload a file via the upload components you will never receive back the full file name (including directory), but only the last part (actual file name). - ANd for selecting the file to be downloaded, there is no chance to pre-set the directory that should be opened.

Kind regards! Björn

PS: great to have you met at the community meeting!

...is available in the download area.

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

(from mail conversation)

Hi,

with update 20220411 we introduced an improved security management, in which a security-id-cookie is always sent from the client side to ensure that no "man in the line" can hijack into sessions.

There are some situations in which problems are caused by this (e.g. when running cc-pages inside an IFRAME). In this case you can switch off this security-id-management by using the system.xml configuration file:

Code:

 <system>
 ...
     <filterconfiguration 
        active="false"
        classname="org.eclnt.jsfserver.util.SecurityFilterGeneral"/> 
 ...
 </system>

If using this then still session hi-jacking is prohibited but it is then not based on Cookie-management but on internal sending of corresponding ids.

Please contact us in this case! We are of course interested in collecting information about scenarios in which the "general management" has problems.

Kind regards! Björn