Populating session context fails lookups
Misagh Moayyed
mmoayyed at unicon.net
Mon Sep 14 12:44:36 EDT 2015
Thanks, the replacement of that class sounds like something that would be
least painful for my needs. I am on the latest snapshot of 3.1.3 and been
meaning to upgrade. This seems like the perfect excuse. I'll rework my dev
environment to point to the latest trunk and will report back findings,
which brings me to this question: are there snapshots available for the
idp installer at this point? I suppose artifacts themselves are somewhere
up on the repo, so those should be OK.
> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
> Sent: Monday, September 14, 2015 9:37 AM
> To: Shib Dev <dev at shibboleth.net>
> Subject: Re: Populating session context fails lookups
>
> On 9/14/15, 12:29 PM, "dev on behalf of Misagh Moayyed" <dev-
> bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
>
> >This attempts to locate the session from cookies via the
> >SessionResolver, finds the cookie value, calls the storage service to
> >look up the cookie by that value. The call stack eventually ends up
> >inside "ServletRequestScopedStorageService" where it attempts to
> >collect all cookies and find one that is "shib_idp_req_ss". This is
> >where it fails, because the only two cookies I can see are the idp
> >session cookie and jesssion cookie.
>
> So you're basing on 3.1.x at this point? Just clarifying. The
> ServletRequestScopedStorageService bean is strictly cookie-based, vs.
the
> replacement that's in svn now on the trunk that does both cookies and
> local storage.
>
> >So, where does that cookie come from? And why might cause it to be
> >absent on subsequent tries?
>
> Yes, web.xml. Your profile path(s) have to be under cover of the servlet
> filter that catches responses and writes out the cookie. That's gone in
> 3.2 because the replacement storage service doesn't need it (which is
one
> reason it's an improvement).
>
> Sorry, should have thought of that.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net
More information about the dev
mailing list