Why does REST URL call LogOut an Aware session in diff wind?

Jaymer

If I am logged in and doing normal things in Aware,
It seems that if I have another Browser Tab open and do a REST call to my server, that the 1st Aware session is getting logged out immediately.
A call like this on the URL:
http://xxx.yyy.xxx.yyy:8080/crm/REST/CRM/QList?theID=2000798

That seems odd to me... and certainly not acceptable.
WHY?

johntalbott

Consuming an AIM REST API from with AIM app>

Jaymer

I hope support can add an answer to this.

also, I'm contemplating using a "dummy" BSV to get the initial data structure - so if I'm running CRM, then couldn't I call a service in CRM2 to return the JSON?

also, does Aware crap out when I POST data to a service? Does the new Session thingy happen then too?

Maybe I just scrap Aware (since I'm writing this to handle JSON) and use node.js

jaymer...

Jaymer

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/5515729/why-set-a-jsp-page-session-false-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.

Jaymer

from oracle

JavaServer Pages Best Practices - Avoid Using HTTP Sessions
Avoid using HTTP session objects if they are not required. If a JSP page does not require an HTTP session (essentially, does not require storage or retrieval of session attributes), then you can specify that no session is to be used. Specify this with a page directive such as the following:

<%@ page session="false" %>

This will improve the performance of the page by eliminating the overhead of session creation or retrieval.

aware_support

See my answer on another thread. DO NOT USE REST API as part of the Aware IM UI session - this is not what it is for.
REST is a solution to communicate between two systems on the backend - not from the UI.

If you want to know how the front end works and how it communicates with the server from the UI study the Aware IM UI code which is available in the AwareIM/Tomcat/webapps/AwareIM/aware_kendo directory. The XML interface that Aware IM backend offers for this is all you need.

And also
DO NOT MESS WITH JSESSIONID.

Jaymer

Support, my issue had nothing to do with the front end functionality like John was wondering about.
I am trying to have JavaScript create some HTML, and display it in and aware HTML box.
So I made a rest service which created a JSON response.
Then I had a JS program written to parse the JSON and create HTML which would be displayed on an aware screen.
Since it was easy to make the JSON , and we’ve talked multiple times on the forum about how a rest service can easily create JSON , then this seemed like an easy way to get the data.
But I see I will have to take another approach.
Thanks for clearing this up.

One approach can still be to have a second BSV and call a separate application to get JSON sent to me.
Can you tell me if I can submit JS to a rest service on the same BSV without clearing the session ID?

Jaymer

aware_support wrote
. DO NOT USE REST API as part of the Aware IM UI session - this is not what it is for.
REST is a solution to communicate between two systems on the backend - not from the UI.
.

Just because it was not meant to do this, what is it hurting?.
I want to bring up a form, and have the initialization script execute some JavaScript. It just so happens it’s a GET to a REST service on my own machine. It’s my own server, why should I not be allowed to do that?
It seems the only thing breaking this is the generation of the session ID Which is Not needed in a reply of a REST service.
At least that’s what it seems like to me.

Are you saying that it’s super important for a session ID to be sent out with a REST reply? If this is unchangeable, then there’s no use pushing this request. But I’m not sure if that’s what you’re saying. Because what you said is “it’s not what it is for “

aware_support

I am confused. Why do you need a REST service here at all? What is it supposed to do?

If it goes to another server (communicates with a 3rd party system) it doesn't need a UI session ID. If it goes to the same server, which handles the UI, then it shouldn't be a REST service - you need to call it the same way the rest of the UI works (using "actions" that send XML to the server through an AJAX request that automatically includes all browser cookies)

Like you said, you need to rethink your approach with REST in this instance.

Jaymer

I talked to Jake about this, and aware cannot do what I wanted to do.
You’re confused, but I’ve put hours into it.
If it wasn’t for this session issue, then I would have an awesome working functionality for a very specific business case that cannot be done in native aware. I’d be glad to discuss it with you if you are interested.

aware_support

When Aware IM handles REST request it ALWAYS creates a new Tomcat session. It has to. And it is allowed to do this because by design it is not supposed to be called from the code that cares about session id. So again, it is not supposed to be called from the UI.

The JSP directive that disables return of the session id to the UI is not an answer:
1) The UI needs to have session ID returned
2) REST servlet does NOT return a JSP page

What you have to so is use an Ajax object to communicate with the server. An example of the Ajax request is in serverCallAction.jsp.