Enterprise Client Community

In case someone is still using Swing...

We did a CaptainCasa Update from 20221005 to 20230206. After the update the applet containing the swing client did not start with a ClassNotFoundException.

After checking the server-side logs we saw a problem with SecurityFilterRemoteAddress. Session information and request information did not match and the jar was not loaded.

...
2023:02:08 14:35:22:817 | 1945 | SEVERE | Client that sends the request is not the one that created the session. Aborting security check with error. /elektrang/eclnt/images/splash_neutral.jpg
2023:02:08 14:35:22:818 | 1945 | SEVERE | Session information: 10.6.12.167/null/Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
2023:02:08 14:35:22:818 | 1944 | SEVERE | Client that sends the request is not the one that created the session. Aborting security check with error. /elektrang/eclnt/lib/eclnt.jar
2023:02:08 14:35:22:818 | 1945 | SEVERE | Request information: 10.6.12.167/null/Mozilla/4.0 (Windows 10 10.0) Java/1.8.0_202
2023:02:08 14:35:22:818 | 1944 | SEVERE | Session information: 10.6.12.167/null/Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
2023:02:08 14:35:22:818 | 1944 | SEVERE | Request information: 10.6.12.167/null/Mozilla/4.0 (Windows 10 10.0) Java/1.8.0_202
2023:02:08 14:35:22:818 | 1944 | SEVERE | Problem occurred during request processing. Please check for details in the server-side logging.
.......... Stacktrace Info ..........
java.lang.Error: Client that sends the request is not the one that created the session. Request is cancelled: /elektrang/eclnt/lib/eclnt.jar
at org.eclnt.jsfserver.util.SecurityFilterRemoteAddress.performCheckRemoteAddress(SecurityFilterRemoteAddress.java:80)
at org.eclnt.jsfserver.util.SecurityFilterRemoteAddress.doFilterExecute(SecurityFilterRemoteAddress.java:50)
at org.eclnt.jsfserver.util.CCFilterBase.doFilter(CCFilterBase.java:41)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
...

The filter was introduced in CC-Version 20221219. The implementation of the check changed when it was moved from SecurityFilterGeneral to SecurityFilterRemoteAddress.

To solve the problem we deactivated the filter in system.xml.

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

Regards
Axel

Hi Axel,

uuuh - you are right!

We now added the do-not-execute-for-Swing-client line in the "SecurityFilterRemoteAddress", too. So from next update on, it will work without the system.xml update.

Thanks for adding this info! - Björn