SP 2.5.1 ss:mem target lost
Cantor, Scott
cantor.2 at osu.edu
Sun Apr 14 18:24:54 EDT 2013
On 4/14/13 3:26 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
>I had hoped that I would be able to see in the log file the
>consumption of the target parameter and its conversion to a
>ss:mem relay state "bucket" but I did not see that, or any
>other way to confirm that the SP is receiving the target
>parameter.
There's no way for it to fail except for obvious reasons, so there's
nothing to log unless it fails a lookup, in which case it logs an error in
native.log. If the system isn't clustered, then the only failure mode is a
corrupted value from the IdP or an expiration of the data. The time limit
appears to be 10 minutes (I had no recollection what I used, I just
looked). The storage code doesn't allow for "soft" expiration where the
data can be purged but is still returned if asked, though that would be a
nice thing for this particular use case.
>a) The incomplete URL encoding of the value for the target
>parameter concerns me and I intend for it to be fixed to rule
>it out as a problem, but since the flow works "correctly"
>approximately 80% or more of the time is the URL encoding
>issue likely or not to contribute?
It probably would depend what was in the URL but if the same URL works or
not, then no.
>b) Is there a shibd.logger configuration I can make to have
>the consumption of the target attribute and its conversion
>into a ss:mem relay state logged so that I can see it?
No.
>c) Any ideas as to why the problem may be happening?
Clustering and a delay before completing the login are the only
possibilities I can think of. The only bug with this mechanism was the
problem with collisions, which is finally fixed.
-- Scott
More information about the users
mailing list