You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary: In borg.localrole.workspace.clra_cache_key, when generating the cache key for caching the result of checkLocalRolesAllowed, if the object does not have a getPhysicalPath attribute (such as a browser view), id(obj) is used instead (line 127). This assumes that the id() of that object is unique and constant for the lifetime of a request. This isn't necessarily the case, and it's possible to cause cache collisions using lots of restrictedTraverse calls. Collisions in this case result in the wrong set of local roles being returned.
History: We're seeing the problem because we have a browser view which is only visible in certain contexts - we know that somewhere in the acquisition chain the user will be able to see the view, so we run up through the aq_chain, try restrictedTraverse() and ignore any Unauthorized errors until we find a context where that view is usable. Since the security is tested after the view has been instantiated we're creating lots of instances of the view then immediately throwing them away. For some reason, there's a high chance that new instances of the same object share an id() which was previously used for a different instance (potentially in a different context!). When the local roles are read from the cache, the roles for a different context are returned, producing inconsistent results.
Potential fix: borg.localrole, workspace.py, line 127: change oid = id(obj) to raise DontCache. There's an obvious disadvantage to this, in that it means that local roles on browser views won't get cached.
The text was updated successfully, but these errors were encountered:
Copy of issue by @evilbungle over here: https://dev.plone.org/ticket/9915
Summary: In borg.localrole.workspace.clra_cache_key, when generating the cache key for caching the result of checkLocalRolesAllowed, if the object does not have a getPhysicalPath attribute (such as a browser view), id(obj) is used instead (line 127). This assumes that the id() of that object is unique and constant for the lifetime of a request. This isn't necessarily the case, and it's possible to cause cache collisions using lots of restrictedTraverse calls. Collisions in this case result in the wrong set of local roles being returned.
History: We're seeing the problem because we have a browser view which is only visible in certain contexts - we know that somewhere in the acquisition chain the user will be able to see the view, so we run up through the aq_chain, try restrictedTraverse() and ignore any Unauthorized errors until we find a context where that view is usable. Since the security is tested after the view has been instantiated we're creating lots of instances of the view then immediately throwing them away. For some reason, there's a high chance that new instances of the same object share an id() which was previously used for a different instance (potentially in a different context!). When the local roles are read from the cache, the roles for a different context are returned, producing inconsistent results.
Potential fix: borg.localrole, workspace.py, line 127: change oid = id(obj) to raise DontCache. There's an obvious disadvantage to this, in that it means that local roles on browser views won't get cached.
The text was updated successfully, but these errors were encountered: