Why would it be necessary for a session ID to get sent out with a rest JSON packet?
We need to find out if this is under aware’s control.
Or maybe it’s coming from tomcat, and there’s a way to instruct tomcat not to do it.
I did some more research on this.
When I make a test call from Postman or the Browser, each time I get a different JSESSIONID in return. You would think that each time it adds one more Session to the Tomcat heap for it to remember (in case another call comes in with that JSESSIONID) and that would be a waste of resources. Thing is, even though it generates a new JSESSIONID, it doesn't remember it. Viewing the Tomcat/Manager system doesn't show a JSESSION out there for the REST call.
So again, WHY does it have to disable the existing/valid JSESSIONID?--> I think the code is sending the reply, then destroying the session - because the Tomcat Manager definitely doesn't know anything about that JSESSIONID that was sent with the JSON response. If this is the case, then its just an oversight to be generating the SESSIONID to begin with.
there is precendent for NOT needing a session each time: https://stackoverflow.com/questions/551 ... -directive
and there is a JSP Directive "<%@ page session="false" %>" which can be used to NOT create a SESSIONID. I think thats the key for Support. Simply adding that directive (or similar function) somewhere in the REST code will keep this all from happening.
This directive is already being used several places in the Tomcat mgmt pages:
Line 18: <%@page session="false" contentType="text/html; charset=ISO-8859-1" %>
in connectorCiphers.jsp, sessionDetail.jsp , sessionsList.jsp
Perhaps Support can add this directive when sending back the JSON response.