Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-16836

Cache for user policies is generated incorrectly when using ActiveAccessExtensions

    Details

      Description

      If there is a module extension, having a FunctionList definition in module.php that can be used to limit permissions and the extension, the module is defined in, is only activated per siteaccess (ActiveAccessExtensions) then eZUser::generateAccessArray() will generate a wrong access array. If the role caching is enabled this will cause access denied error if the user switches from the siteaccess for which the extension is not active to a siteaccess for which the extension is active. This means another assumption is, that the two siteaccesses share the same session.

      Steps to reproduce

      Enable role caching
      Disable SessionNamePerSiteAccess
      Create a module with functions for limitation
      Activate the module only for siteaccess A
      For example edit the user account on siteaccess B
      Switch back to siteaccess A and try to execute a view of the module

      Result: Even an admin user is not able to execute the module's view

        Activity

        Hide
        André R added a comment -

        This issue was introduced by object states code in 4.1.

        The change expanded * access to list of current modules / functions to be able to hard code limit to ez_lock state.
        This also caused issue where you'd have to clear user cache every time new modules where added to system as well as made this function ( generateAccessArray() ) more expensive.

        Awaiting feedback from PB about ez_lock as it does not seem to be needed any more with the .is_internal flag that was added to states.

        Show
        André R added a comment - This issue was introduced by object states code in 4.1. The change expanded * access to list of current modules / functions to be able to hard code limit to ez_lock state. This also caused issue where you'd have to clear user cache every time new modules where added to system as well as made this function ( generateAccessArray() ) more expensive. Awaiting feedback from PB about ez_lock as it does not seem to be needed any more with the .is_internal flag that was added to states.
        Show
        André R added a comment - Fixed in master: http://github.com/ezsystems/ezpublish/commit/b551dc3928c8d145992af61449ac9163302ab8b5
        Hide
        Kristof Coomans added a comment - - edited

        To clarify some things, as it seems like your understanding of ez_lock and is_internal is completely wrong.

        The ez_lock state was introduced to provide a full lock on content objects (no edit, delete by no one), and was intended to be used by the new implementation of the eZ Publish WebDAV server. I am not aware if it was eventually used by the WebDAV server or not, as this was implemented by someone else.

        The role policy limitations for the ez_lock state had to be implicitly added, as you do not want admins to have to modify each role to add those limitations. For the future I intended to add an API to add any kind of implicit policy limitations.

        The is_internal flag of object states has nothing to do with the implicit limitations for the ez_lock state that were added, it just specifies if a state group and its states is editable from the admin interface or not, as you do not want certain states to be changed, as it was the case for ez_lock.

        I see you removed the code that added the implicit limitations, making ez_lock also useless. The ez_lock state should be removed as well then, unless it is still needed, in that case the issue needs to be solved in another way.

        Show
        Kristof Coomans added a comment - - edited To clarify some things, as it seems like your understanding of ez_lock and is_internal is completely wrong. The ez_lock state was introduced to provide a full lock on content objects (no edit, delete by no one), and was intended to be used by the new implementation of the eZ Publish WebDAV server. I am not aware if it was eventually used by the WebDAV server or not, as this was implemented by someone else. The role policy limitations for the ez_lock state had to be implicitly added, as you do not want admins to have to modify each role to add those limitations. For the future I intended to add an API to add any kind of implicit policy limitations. The is_internal flag of object states has nothing to do with the implicit limitations for the ez_lock state that were added, it just specifies if a state group and its states is editable from the admin interface or not, as you do not want certain states to be changed, as it was the case for ez_lock. I see you removed the code that added the implicit limitations, making ez_lock also useless. The ez_lock state should be removed as well then, unless it is still needed, in that case the issue needs to be solved in another way.
        Hide
        André R added a comment - - edited

        In reply to comment #051957
        Thanks for the feedback kc.

        If it is used I'll re add it, but in another way that does not mean messing with the cached policies.

        Only place I can find it in kernel now is:

                // @as @todo implement setting properties
                // @todo implement locking and unlocking based on the code
                // lock:
                // replace 30607 with your object ID
                // $object = eZContentObject::fetch( 30607 );
                // $stateGroup = eZContentObjectStateGroup::fetchByIdentifier( 'ez_lock' );
                // $state = eZContentObjectState::fetchByIdentifier( 'locked', $stateGroup->attribute( 'id' ) );
                // $object->assignState( $state );
         
                // unlock:
                // $state = eZContentObjectState::fetchByIdentifier( 'not_locked', $stateGroup->attribute( 'id' ) );
                // $object->assignState( $state );
        

        So someone needs to implement it first, and while on it do it a bit differently.

        Show
        André R added a comment - - edited In reply to comment #051957 Thanks for the feedback kc. If it is used I'll re add it, but in another way that does not mean messing with the cached policies. Only place I can find it in kernel now is: // @as @todo implement setting properties // @todo implement locking and unlocking based on the code // lock: // replace 30607 with your object ID // $object = eZContentObject::fetch( 30607 ); // $stateGroup = eZContentObjectStateGroup::fetchByIdentifier( 'ez_lock' ); // $state = eZContentObjectState::fetchByIdentifier( 'locked', $stateGroup->attribute( 'id' ) ); // $object->assignState( $state );   // unlock: // $state = eZContentObjectState::fetchByIdentifier( 'not_locked', $stateGroup->attribute( 'id' ) ); // $object->assignState( $state ); So someone needs to implement it first, and while on it do it a bit differently.
        Hide
        ezrobot added a comment -

        This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

        Show
        ezrobot added a comment - This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

          People

          • Assignee:
            André R
            Reporter:
            (inactive) Gunnstein Lye
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: