Hi,
(I tried to search the forum... but I think the search is broken, it does not return any results for whatever I'm trying to search, anyways)
I'm evaluating to migration a cgi Webspeed App. The app is currently tracking session with it's own session Cookie. I wish to make use of the JSESSIONID instead. I saw that the session is not explicitly created on first request. In fact, if I use client.login.model=anonymous it's not created at all.
I don't really want to change the client login model and make use of the client-principal thing. Having the session created is enough for me for the moment.
So, I set create-session="always" in anonymousLoginModel.xml and seems to be created now. My question, it is the best way to do it ?
<http pattern="/**"
auto-config="false"
use-expressions="true"
create-session="always"
disable-url-rewriting="true"
authentication-manager-ref="nullApplicationAuth"
entry-point-ref="http403ForbiddenEntryPoint"
realm="OpenEdge" >
Thanks
Stephan
A sessionid should be used to identify the logged in user. Is client-principal created outside PASOE? If yes, how is it passed in every request? How are you wiring the JSESSIONID and client-principal ?
anonymous login model implies there is no authentication required to access the service. So it doesn't care who is calling the request & hence doesn't have session id.
A session identifier does not implicitly mean that the user is authenticated. It's just there to differentiate the session ( client's browser).
The old Webspeed framework took care to validate if the session id was valid and if the user was logged in and so on. It was using it's own cookie that was created at first request (let's call it "MYAPPCONTEXT").
I just want to rely on the spring JSESSIONID cookie instead (and discard the use of the old cookie name).
The JSESSIONID is a cookie that contains a reference to server-side Web Session storage that is maintained by the Tomcat web server. One possible use of the Web Session is in containing a user's login security token that is produced by the ABL web app's Spring Security authentication layer. There can be other uses of that server-side Web Session by Java web apps, but not via direct access by the ABL application code ( that I know of ).
In your example you have triggered the SpringSecurity component (i.e. Java web app) to create a JSESSIONID and server-side Web Session - but your ABL application has no direct access to it. If you do not want to change from the classic WebSpeed's implementation, then using JSESSIONID will not be an option for you and just adds overhead to Tomcat in maintaining those Web Sessions.
If you ever consider moving to a stronger security model that employs Spring Security authentication/authorization and Client-Principals - contact us and we can discuss your particular product's requirements to see if there is a match.
Thanks Michael.
I was currently looking at Spring Security and Client-Principal this morning. Not sure I will implement it right now... but eventually.
And you right about the overhead of the tomcat just to get the session id cookie. I'll probably stick to my current implementation and migrate it as-is.
Stephan