Enterprise Client Community

Good enough for us does not mean automatically it's good enough for the customer ;)

I've tested it, looks good: Client requests and server responses contain the ccsessioncheckid in the HTTP header or as HTML form element - which are both encrypted in HTTPS connections.

Calls of URLs with JSESSIONID and without ccsessioncheckid lead directly to a filter error.

Thanks for your help, Björn!

Best Regards,
Thorsten

I will test this "session-check-id" feature, maybe this is good enough for the customer.

Thanks for the quick feedback Björn!

About that Development Guide section you've mentioned: I've already read that part, experimented with the .ccwebstart startup of the client, but I think I haven't understood it completely - is there a way to get rid of the JSESSIONID GET handling by using and setting this eclnt-id as cookie?

Thanks in advance!
Regards, Thorsten

Hi community,

after a security audit we are forced to switch our application to cookie only support. Jsessionids as GET parameter are no longer allowed.

I've changed my Tomcat to cookie-only mode with:
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>

Afterwards the ECLNT, started by JNLP, redirects on login attempt to a session invalid page and shows the following exception in the Java Console:

org.eclnt.client.comm.http.SessionTimeoutException
at org.eclnt.client.comm.http.DataTransfer.transferXML(DataTransfer.java:930)
at org.eclnt.client.comm.http.DataTransfer.communicateToServerSynchronous(DataTransfer.java:260)
at org.eclnt.client.page.Page.transferDataRun(Page.java:1200)

Is it possible to swith to cookie only tracking?