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

[Stephen Swinsburg]

Hi Casey,

Can't help you with your problem sorry but regarding finding a recent  
session with the matching ID then re-establishing it, this could be a  
security concern as one could attempt to guess/modify a session ID and  
be logged in as someone else. I guess that is possible now, someone  
could attempt to guess their session, but if they have timed out, as  
far as I know, they aren't revived so it's ok.

cheers,
Steve

---
Steve Swinsburg
Portal Systems Developer
Centre for e-Science
Lancaster University
Lancaster
LA1 4YT

email: s.swinsburg at lancaster.ac.uk
phone: +44 (0) 1524 594870

On 07/03/2009, at 6:51 AM, Casey Dunn wrote:

> 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
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090307/1f500e67/attachment-0001.html