[shib_auth] class registry in drupal 7 conflicting with shib sessions
Patrick Dawkins
p.dawkins at ucl.ac.uk
Wed Aug 28 16:29:35 CEST 2013
For uclu.org we run Memcache as the default cache backend and haven't run
into issues. We also run Varnish (for the filter, page, and block caches).
Patrick
On 28 August 2013 15:22, Kristof Bajnok <bajnokk at niif.hu> wrote:
> Andy,
>
> Can you please elaborate, what part of the session was overlapping between
> the users? I think we need to find a safe way for storing session-local
> variables without being screwed by the various caching mechanisms from time
> to time.
>
> For th OP, I can't think of a reason why shib_auth would get into registry
> cache at all. If you can dump the contents, you can spot whether there is
> anything interesting in it.
>
> Kristof
>
>
> Andy Kohler <akohler at ucla.edu> wrote:
>>
>> You might also try disabling memcache, if you use it.
>>
>> In our environment, we've found that with memcache enabled (via
>> settings.php, as a backend cache for everything except forms), Shib-created
>> sessions can seemingly overlap (a user logging in within a few minutes of
>> another user sees the first user's name).
>>
>> This isn't the same as Mike's problem, but since cache is involved, it
>> might be relevant.
>>
>> --Andy
>>
>>
>> On Wed, Aug 28, 2013 at 3:07 AM, Patrick Dawkins <p.dawkins at ucl.ac.uk>wrote:
>>
>>> Hi Mike
>>>
>>>
>>> The shib_auth module doesn't get involved with the registry - it
>>> contains no classes or interfaces, and the statement "SELECT * FROM
>>> registry WHERE module = 'shib_auth'" yields nothing.
>>>
>>> I have never had registry issues with Shibboleth (although I have with
>>> Drupal Commerce, for which the registry rebuild<https://drupal.org/project/registry_rebuild>module is very useful).
>>>
>>> So it sounds like it's something else and you have more debugging to do.
>>>
>>> Since cache clearing has something to do with it, perhaps you have a
>>> module that's doing extra caching somewhere that's misbehaving. And the
>>> Performance section by no means lists all the caches in Drupal core or
>>> contrib - the list of caches can include bootstrap, block, page, menu,
>>> theme, system, user, node, token, views, entity, etc. What cookies are set
>>> in the browser after Shibboleth login - when it's working and when it isn't?
>>>
>>>
>>> Regards
>>> Patrick
>>>
>>>
>>>
>>> On 27 August 2013 20:29, Mike Cammilleri <mikec at stat.wisc.edu> wrote:
>>>
>>>> We are using the shibboleth module with D7 which works, most of the
>>>> time. Users can click on the shibboleth login link, be directed to the Idp,
>>>> authenticated successfully and returned to D7, at which point .htaccess
>>>> allows them in with
>>>>
>>>> AuthType Shibboleth
>>>> ShibRequireSession Off
>>>> require shibboleth
>>>> ShibUseHeaders On
>>>>
>>>> About an hour or so goes by and all of a sudden D7 stops allowing the
>>>> shib-authenticated user in. The user can still authenticate to the shib
>>>> Idp, but when returned to the D7 site, drupal just behaves as if they never
>>>> logged in at all. No error page, no 404 not found, no white page of death,
>>>> just back to the D7 site and the login button for shib is still sitting
>>>> there as if they never clicked on it.
>>>>
>>>> In order to fix this, all I need to do is flush the Class Registry from
>>>> the Flush All Caches menu. Simply flushing that cache corrects the behavior
>>>> and once again D7 will allow users to log in via shib. Until another hour
>>>> goes by and D7 stops allowing shib users, and I need to flush the Class
>>>> Registry again.
>>>>
>>>> Has anyone experienced this? What is in the Class Registry that could
>>>> be causing D7 to think users aren't logged in? (Local drupal accounts work
>>>> fine by the way). I turned off all caching in the Performance section,
>>>> except for block caching which is greyed out because I'm using the Access
>>>> Control module. This still has not fixed the problem.
>>>>
>>>> Any hints would be greatly appreciated.
>>>>
>>>> ______________________________**_________________
>>>> shib_auth mailing list
>>>> shib_auth at listserv.niif.hu
>>>> https://listserv.niif.hu/**mailman/listinfo/shib_auth<https://listserv.niif.hu/mailman/listinfo/shib_auth>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> shib_auth mailing list
>>> shib_auth at listserv.niif.hu
>>> https://listserv.niif.hu/mailman/listinfo/shib_auth
>>>
>>>
>> ------------------------------
>>
>> shib_auth mailing list
>> shib_auth at listserv.niif.hu
>> https://listserv.niif.hu/mailman/listinfo/shib_auth
>>
>>
> _______________________________________________
> shib_auth mailing list
> shib_auth at listserv.niif.hu
> https://listserv.niif.hu/mailman/listinfo/shib_auth
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.niif.hu/pipermail/shib_auth/attachments/20130828/b0dc72ec/attachment.html>
More information about the shib_auth
mailing list