Have you ever seen this pattern before?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Have you ever seen this pattern before?

Dan McLaughlin
We see this pattern in our logs quite often. Within the same second we
see following...

2019-08-28 09:01:47 INFO Shibboleth.SessionCache [52] [default]:
removed session (_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 INFO Shibboleth.SessionCache [44] [default]:
session recovered: ID (_d4a97872909de981f033505fbd3d59fe) IdP
(https://idp.domain.com/idp/shibboleth)
Protocol(urn:oasis:names:tc:SAML:2.0:protocol)
2019-08-28 09:01:47 INFO Shibboleth.SessionCache [44] [default]:
removed session (_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [44] [default]:
duplicate insertion of revocation for session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [44] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [46] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [46] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [46] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [52] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)
2019-08-28 09:01:47 WARN Shibboleth.SessionCache [44] [default]:
blocked recovery of revoked session
(_d4a97872909de981f033505fbd3d59fe)

Is this expected behavior?  If not, what might cause this?

--

Regards,

Dan
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Have you ever seen this pattern before?

Cantor, Scott E.
On 8/28/19, 5:55 PM, "dev on behalf of Dan McLaughlin" <[hidden email] on behalf of [hidden email]> wrote:

> Is this expected behavior?  If not, what might cause this?

That would take competing Apache children all colliding and handling requests from the same client and stepping on each other until the session and cookies are finally gone and stop reappearing and going back around again. Probably depends on why the session is removed too.

There's no "expected" behavior with a feature with so little usage but I don't know much about how Apache tends to handle clients and distribute connections and how things might step on each other. I imagine it's not that surprising.

The code obviously clears the cookie but it was implemented so that if a client tries to hold on to one there's a backstop against the session reviving itself, particularly if it's ended for reasons that wouldn't just invalidate it again. I doubt the logging levels are very optimal, it takes a lot of use of a feature to settle on what the noise should be.
 
-- Scott


--
To unsubscribe from this list send an email to [hidden email]