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

SiteAccessRules setting doesn't work well in the Symfony Stack

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 2014.01
    • Fix Version/s: 2014.03, 5.3
    • Component/s: Platform stack
    • Labels:

      Description

      It seems there's a problem with the SiteAccessRules setting when working with the legacy stack. I will try to explain it:

      In my extension i have this definition in one of my site.ini.append.php

      [SiteAccessRules]
      Rules[]=access;enable
      Rules[]=moduleall
      Rules[]=access;disable
      Rules[]=module;user/login
      Rules[]=module;user/register
      Rules[]=module;content/view
      

      For reproducing this bug, you can add these same settings to any of your legacy extensions and go to "user/register" in the symfony stack

      With this settings i'd the "disable view" error when going to "user/register" in the symfony stack, but user/register is still accesible. Also content/view is even it shouldn't

      Going directly with the legacy stack, all works as i'd expect.

      Here's what i found so far.

      eZModule::accessAllowed uri try to gets the value of this setting in https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezutils/classes/ezmodule.php#L2089

      Doing a var dump of the items var after the call we have different values if the site is fully powered by the legacy stack and the symfony stack.
      For the simfony stack we get

      array(13) {
        [0]=>
        array(2) {
          [0]=>
          string(6) "access"
          [1]=>
          string(6) "enable"
        }
        [1]=>
        array(1) {
          [0]=>
          string(9) "moduleall"
        }
        [2]=>
        array(2) {
          [0]=>
          string(6) "access"
          [1]=>
          string(7) "disable"
        }
        [3]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(10) "user/login"
        }
        [4]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(13) "user/register"
        }
        [5]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(12) "content/view"
        }
        [6]=>
        array(2) {
          [0]=>
          string(6) "access"
          [1]=>
          string(6) "enable"
        }
        [7]=>
        array(1) {
          [0]=>
          string(9) "moduleall"
        }
        [8]=>
        array(2) {
          [0]=>
          string(6) "access"
          [1]=>
          string(7) "disable"
        }
        [9]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(10) "user/login"
        }
        [10]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(13) "user/register"
        }
        [11]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(12) "content/view"
        }
        [12]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(14) "content/search"
        }
      }
      

      If going with the Symfony stack this is what we get

      array(3) {
        [0]=>
        array(2) {
          [0]=>
          string(6) "access"
          [1]=>
          string(7) "disable"
        }
        [1]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(10) "user/login"
        }
        [2]=>
        array(2) {
          [0]=>
          string(6) "module"
          [1]=>
          string(11) "user/logout"
        }
      }
      

      I think this is because symfony loader performs a settings injection, but this injected settings are not correctly merged with the ones provided from your legacy settings .

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            desorden Carlos Revillo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: