[Building Sakai] sakai access/.../WebServlet, skitzo Sakai Sessions, and the joys of /web URL - a question in Sakai 2.4.x

Casey Dunn caseyd.stan at gmail.com
Fri Mar 6 22:38:22 PST 2009


Hi folks.

I am having a re-occurring issue with access to the Content Hosting services
via the
access tools WebServlet mechanisms.

Here's the deal.

I have an application which is POSTing content to Sakai via the WebServlet's
offered /web/ URL.

Infact it's posting a fair amount of content. It can do this a lot, but now
and again we find that Sakai
is lying about the Users AuthN.

This is not considered useful.

read on -

In a non-load-balanced, single server environment we've seen a few of these
sequences:

3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO: upload
cwrks228_228Coursework_Q1.mov to:
https://coursework-qa1.stanford.edu/web/Sp08-ITALSOPI-22/SOPI_Responses/Sp08-ITALLANG-22A-01/?sakai.session=8f3ad7ae-0f99-45db-0084-c13e30787d8b
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:15 PM sopiApp.sopi.oldUI.OldSopiTestPage fnSetUpQst
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO: Test
Page: setting up question movie for userQ:  2
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:15 PM sopiApp.sakaisupport.SakaiSite putFile
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO:  upload
HTTP status 403  for: cwrks228_228Coursework_Q1.mov to:
https://coursework-qa1.stanford.edu/web/Sp08-ITALSOPI-22/SOPI_Responses/Sp08-ITALLANG-22A-01/?sakai.session=8f3ad7ae-0f99-45db-0084-c13e30787d8b
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:15 PM sopiApp.tasks.MovieUploadTask doInBackground
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] SEVERE: NO
UPLOAD ALLOWED: 403
3/6/09 5:55:15 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:15 PM sopiApp.tasks.MovieUploadTask failed



yet later ...


3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO: upload
cwrks228_228Coursework_Q2.mov to:
https://coursework-qa1.stanford.edu/web/Sp08-ITALSOPI-22/SOPI_Responses/Sp08-ITALLANG-22A-01/?sakai.session=8f3ad7ae-0f99-45db-0084-c13e30787d8b
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:43 PM sopiApp.sopi.oldUI.OldSopiTestPage fnSetUpQst
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO: Test
Page: setting up question movie for userQ:  3
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:43 PM sopiApp.sakaisupport.SakaiSite putFile
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO:  upload
HTTP status 200  for: cwrks228_228Coursework_Q2.mov to:
https://coursework-qa1.stanford.edu/web/Sp08-ITALSOPI-22/SOPI_Responses/Sp08-ITALLANG-22A-01/?sakai.session=8f3ad7ae-0f99-45db-0084-c13e30787d8b
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] Mar 6, 2009
5:55:43 PM sopiApp.tasks.MovieUploadTask finished
3/6/09 5:55:43 PM [0x0-0xe60e6].com.apple.JarLauncher[16828] INFO:
MovieUploadTask:  done uploading indexQ: 1 upload size: 557815


If you're not paying attention that's OK.

here's whats happening, AKA the "executive summary."

The first upload request gets a 403 error. Note the sakai session ID.

The second upload request is not met with any such nonsense.

Note the timestamps; the second request is complete just a few seconds after
the first.

No admin is modifying user privs within this timeframe. The LB has not
switched the client session
to a new Sakai server ( which leads to an invalid sakai session exception
due to the unlivelyness  and illresiliance of Sakai sessions ).

It's the same Sakai server.

The user has been logged in for at least 2 min.

During the time before and between the upload requests the Sakai server has
honored session referencing WebService calls for
state updates.

I've reviewed the code at the head of the 2.5.x branch for changes to the
"WebServlet" and no giant leaps of
session management hygene lept out at me.

Has anyone else seen this behavior, or had experience with it?

in a Browser the user would get some sort of error ( xlogin, or perhaps just
a benign error and a "retry" ) - have your Support people logged a mess of
tickets for upload errors?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090306/042ad273/attachment.html 


More information about the sakai-dev mailing list