[Building Sakai] Access to HTTP Session Data

[Steve Swinsburg]

It might help looking at the confluence page about shibboleth in sakai. The
one that Denny wrote. ANU spent a fair bit of time on this a few years ago,
there might be some info there about accessing the attributes.

sent from mobile
On 04/01/2014 10:42 PM, "Mark J. Norton" <markjnorton at earthlink.net> wrote:

>  Thanks, Chuck.  Yeah, I kinda had a bad feeling about it as well, hence
> the shout out for confirmation.  Our fall back position is to extend the
> RequestFilter and stuff Shib attributes into something we can get ahold of
> later, such as the ServletContext.
>
> - Mark
>
> On 1/3/2014 8:22 PM, Charles Severance wrote:
>
>
>  On Jan 3, 2014, at 6:55 AM, Mark J. Norton <markjnorton at earthlink.net>
> wrote:
>
>
>    - CONTAINER_SESSION = 0;    // don't do anything.
>    - SAKAI_SESSION = 1;             // use the sakai wide session.
>    - CONTEXT_SESSION = 2;       // use the context session.
>    - TOOL_SESSION = 3;              // use the tool session, in any, else
>    context.
>
> Looking at the web.xml<https://source.sakaiproject.org/svn/portal/trunk/portal-tool/tool/src/webapp/WEB-INF/web.xml>
>  file for the Portal, I note that the "http.session" init parameter is
> not specified, thus defaulting to TOOL_SESSION.
>
> My question is this.  If I add an init-param XML block to specify  the
> HTTP Session at SAKIA_SESSION, for example, will it screw up all of Sakai?
> For example:
>
> <init-param>
>             <param-name>http.session</param-name>
>             <param-value>1</param-value>
> </init-param>
>
> My concern is that by shifting the HTTP Session into the Sakai Session (or
> Servlet Context, etc), that it would be missing in the Tool Session, where
> tools expect it to be.  I'm willing to just try this and see what happens,
> but I though it would be useful to give someone the chance to say, "Don't
> do that!  Are you crazy!?!".
>
>
> My feeling is "Don't do this, are you crazy?"  Everything in Sakai is
> written to expect "Tool Scoped" sessions.  Changing it in the portal would
> be too broad of a change.   The *only* reason that I can even vaguely
> remember in having this parameter was in case we had some old legacy
> Servlet we would have this value in the web.xml for a single servlet.
>
>  My guess is that you could change it and perhaps nothing would break
> right away in simple testing - but if tools ended up with a single
> commingled session they might start tromping on each other's data.   Also
> the "Tool Reset" for a single tool might reset all tools.
>
>  I am not 100% sure - this is just my gut reaction.
>
>  /Chuck
>
>
>
> _______________________________________________
> 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/20140106/825e5655/attachment.html