[Building Sakai] access/.../WebServlet.setSession question in Sakai 2.4.x

[Stephen Marquard]

Hi Casey,

You can't use SAKAI_SESSION values, which refer to UsageSessions, for auth sessions, which are different altogether.

The request filter also has support for basic auth (instead of cookies), which you could try using.

e.g. a URL like this:

https://vula.uct.ac.za/access/content/group/4432d51e-96f7-49c5-802e-e56eb1e95899/black%20and%20white.html?__auth=basic

(i.e. append __auth=basic to the parameter list). I'm not sure if it works for POST.

Why does your LB want to renegotiate the SSL sessions? It seems the simplest solution is to fix the LB.

kernel trunk (which you could run with 2-6-x) has support for terracotta clustering, so allows sessions to be shared across app servers in the cluster.

As to the "less than accurate" suggestion below, I'd suggest you create JIRA with full details demonstrating the issue.

Regards
Stephen

>>> Casey Dunn <caseyd.stan at gmail.com> 2009/03/07 08:51 AM >>>
Hi folks.

Ive got quick question about the access WebServlet code. This is not about
Sakai being less than accurate about users AuthN during access to the
WebServlet front end to the Content Hosting system.

This email is about Session Migration.

background: I've a situation where occasionally  the LB / FW we have in
front of Sakai will renegotiate a SSL session. When it does so it _may_ send
the session to a new LBed Sakai server. ( background music: "SSL renogiation
and IP spoofing" )

When the request ends up at the new server the Sakai session is invalid.
"Who the heck are you?" is the essential response.

This is because the Sakai 2.4.x sessions are not viable across a pool of
Sakai servers.

I am considering making the WebServlet setSession code, well, should it
fail, dig into the SAKAI_SESSION table and see if there has recently been,
somewhere, a session with the same ID. the Session code will only WARN if a
duplicate Sakai Session Id is re-used. A specific factor is that my client
dumps the SAKAI_SESSION (etc) table daily... so say we all!

If there has been a viable session I would then establish a new session on
the new server for the purpose of pushing in the upload. I might establish
this server's session with the same darn ID, and then refresh the Auth group
stuff blah blah blah for this ride into sakai.

Has anyone tried this yet?

TIA,
Casey