Author |
Message |
|
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?
|
|
|