Module Admin Restrict Branch

[Kiwi Chris]

I'm not sure whether it's an issue with the current version of the core (3.0.203), or some other interaction, but currently I'm getting a weird issue.

All users, regardless of what branch they're restricted to, are being restricted to the same branch. 

ie branch restriction is happening, but regardless of what branch is specified, they all get the same branch.

[edit] I seem to have found the source of the problem. It is an interaction between Multisite module and @kixe version ofAdminRestrictBranch.

What seems to be happening, is that when a user logs in, they will get the full page tree of whatever domain they have logged in under, regardless of how AdminRestrictBranch is configured.

In some ways that's desirable: log in under a domain, and only get that domain's page tree, but it's also a security issue, as if a user knows another domain in the same multisite setup, and logs in with the login that's supposedly restricted to the page tree for another domain, they can see the page tree of the other domain.

 

 

[adrian]

Is there a problem with my version of the module, or just kixe's? What features does that have that made you choose it - can I integrate them into mine?

[Kiwi Chris]

Oops! Sorry @adrian I just realised I got my module mentions back to front. I'm using your 'official' version of AdminRestrictBranch, and the Multisite version by @kixe

There does seem to be some interaction going on between them that's causing unexpected results. It's not necessarily a fault with AdminRestrictBranch, it looks like an issue with Multisite module as it hooks AdminRestrictBranch::getBranchRootParentId , but it's still worth mentioning here in case someone else runs into the same problem, so that they're aware of potential issues using the two modules together.

I found an easy fix was just to comment out the hook code in the Multisite Module.

[adrian]

Just an FYI that a couple of years ago I used Soma's multisite with ARB without any issues - in case that is at all useful.

Do let me know if there is anything I can do to allow that AdminRestrictBranch::getBranchRootParentId to not break things.

 

[Paul Greinke]

There have been no updates to this module for a long time.  Is it still good to use with 3.0.227 or are there better, more active alternatives?

[teppo]

"If it works, don't touch it" ?

Seriously speaking though, this module works well and does what it needs to do. So yes, if you want to restrict access by branch then it is a good option, regardless of which core version you are using.

[adrian]

Hi @Paul Greinke - as @teppo said, it still works as intended on the most recent PW versions and I use it in production so I should be aware of any issues that might arise in the future.

[Paul Greinke]

Great, than I'll keep using it. Thank you for your feedback!

[biniyam]

Hey.

I am a beginner in Processwire, can someone help please me with an issue:

Is there a way to restrict a role (e.g. 'sports-editor-role') to a page (e.g. 'sports-page') automatically via a PHP script? Only the superusers has access to Admin Restrict Branch, we have prepared a form for admins to assign roles to member users. 

[adrian]

@biniyam if you configure this module to the restriction you need you should be fine if your form assigns the required role to the users. It sounds like the "Role Specified Branch Parent" might be the best option based on your description - shouldn't need a php script.

[biniyam]

@adrian Thank you for your response.

I have configured it exactly as you mentioned above (i.e. configured the module to "Role Specified Branch Parent" option & the admins via the form assigns the required role to the users for existing roles created by superusers).

We have 'News' page and it's children are 'sports', 'politics', 'food' etc. and these children pages have corresponding roles as well. Whenever the admins add child pages to the 'News' page, a new role is created programmatically. For the existing roles('sports-editer', 'politics-editer', 'food-editer') the superuser has set branch restriction in the role setting manually. That means: if a user has a 'sports-editer' role, the user can only view/edit the 'sports' page. Now what we want is, for future creation of 'News' page children pages, we want to set the branch restriction via a PHP script. The reason being the client do not want the 'admins' to have access to Admin Restrict Branch Module, Access>Users, Access>Roles etc., there is a form prepared for such tasks for the admins.

I am just wondering if there is a way something like this: 

$role = new Role();
$role->name = 'sports-editor';
$role->admin_restrict_branch = $sportsPage->id;
$role->save();

Thank you.

[adrian]

$role->branch_parent is what you're looking for rather than admin_restrict_branch. But otherwise your example code should work.

[biniyam]

@adrian Thank you so much, this fixed the issue.

[herr rilke]

Many thanks from me too for the wonderful module,  @adrian!

Is there a way to display another navigation point in addition to "pages"?
I created a module that outputs statistics about the page in the backend. I would like to have this as an additional access point for users.

[ottogal]

Guten Tag herr rilke,

1 hour ago, herr rilke said:

Is there a way to display another navigation point in addition to "pages"?

This might be helpful:

https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/

[herr rilke]

hello ottogal,
Thanks for the hint!
I actually know the site, but I can't yet see how I could implement my plan. AdminRestrictBranchSelect could be an approach, but I don't know if it can link to admin pages.

[bernhard]

Hey @adrian I had a look into your modules code to see how you restrict search results in the PW backend. I need this for a multisite module I'm building. I took your hook:

wire()->addHookAfter('ProcessPageSearch::executeFor', $this, 'hookSearchResults');

...but wondered why it did not trigger my callback. First I thought the bd() call in the callback might not be working, but turned out the callback was never triggered. So I added a hook recorder and got a log like this:

ProcessWire\FieldtypeModule::formatValue
ProcessWire\FieldtypeModule::formatValue
ProcessWire\ProcessController::execute
ProcessWire\FieldsArray::changed
ProcessWire\FieldsArray::changed
ProcessWire\FieldsArray::changed
---
ProcessWire\ProcessPageSearchLive::execute
ProcessWire\ProcessPageSearchLive::getDefaultPageSearchFields
---
ProcessWire\FieldtypeModule::formatValue
ProcessWire\Pages::find
ProcessWire\PageFinder::find
ProcessWire\PageFinder::getQuery

Which made me aware of "ProcessPageSearchLive". I then changed my hook to hook into ProcessPageSearchLive and boom, everything worked as expected.

Now I'm wondering why your module only hooks into ProcessPageSearch. Does that even work? Or am I missing something?

Thx!

[adrian]

Hey @bernhard - I don't think I want the ProcessPageSearchLive in my case because I want any user to be able to find view links publicly available pages, but because the module makes these restricted pages uneditable for the user, the edit links for restricted pages aren't returned via the live search anyway.

As noted in my source code, ProcessPageSearch::executeFor is for things like pages returned from autocomplete when inserting a link to a page in a CKEditor field.

So, I think I am covered, but please do let me know if I have misunderstood or overlooked something.

[bernhard]

Thx @adrian that already helps!

12 hours ago, adrian said:

As noted in my source code, ProcessPageSearch::executeFor is for things like pages returned from autocomplete when inserting a link to a page in a CKEditor field.

I missed that comment!

12 hours ago, adrian said:

because the module makes these restricted pages uneditable for the user, the edit links for restricted pages aren't returned via the live search anyway

This one is interesting. This is not the case for me! I'm also hooking Page::editable and Page::addable and the live search returns non-editable pages as well...

[adrian]

4 hours ago, bernhard said:

This one is interesting. This is not the case for me! I'm also hooking Page::editable and Page::addable and the live search returns non-editable pages as well...

Does it return them with links to edit those pages, or just view them? For me it returns the view link which is fine.

[bernhard]

Ah, thx! That's what I was missing 🙂 It returns only view links which I don't want either. Thx for the clarification 🙂 

[Kiwi Chris]

I'm not sure whether this comes under the scope of this module or not, but I want to be able to not just restrict viewing/editing of branches of the page tree, but actual page views as well.

I discovered that if you use the search box: 

Even if a page is within a branch that is restricted from a user in the page tree, they can still view it.

I tried adding another hook:

$this->wire()->addHookAfter('Page::viewable', $this, 'hookPageViewable');

and this:

  protected function hookPageViewable($event)
     {
         // in case there is already a defined exclusion for this user's role for this page
         if (!$event->return) return;

         if ($this->wire('user')->hasPermission('page-view')) {
             $event->return = $this->onAllowedBranches($event->object);
         } else {
             $event->return = false;
         }
     }

But the end result is that admin menus that the user could previously view are hidden, so it's now working TOO well.

What I want is for pages that aren't viewable or editable from the page tree aren't viewable from search either.

[adrian]

Hi @Kiwi Chris - this module is all about restricting branch access in the admin (so basically viewing and editing in the admin). It does not attempt to prevent viewing on the frontend at all.

I honestly find the page-view permission in PW very confusing in certain situations and it has some bugs associated with it - the latest I found is: https://github.com/processwire/processwire-issues/issues/2107

I assume you are attempting to lock things down after the recent security issue that was eluded to (although the implications not really explained as well as they should have been) here: https://processwire.com/talk/topic/31385-pw-30251-–-core-updates/#comment-249810 ?

 

[Kiwi Chris]

7 hours ago, adrian said:

Hi @Kiwi Chris - this module is all about restricting branch access in the admin (so basically viewing and editing in the admin). It does not attempt to prevent viewing on the frontend at all.

The issue I have is pages that are not publicly viewable, but are viewable only to people with a specific role. AdminRestrictBranch works fine with regard to restricting editing access, but as you mention, it doesn't work for frontend access. Because the criteria I want to use to restrict view access are the same as what I want to restrict edit access, I figured extending the module functionality with my own custom code for view access would be a practical way to meet my needs, but I haven't figured out how to apply the code so that it doesn't block view access to admin pages as well. It's probably a selector thing.

I'm not even sure if this is the right thread to ask, but seeing as the functionality I want extends what the module already does, I thought it would be a good place to start, case anyone else needed to do similar.

[adrian]

@Kiwi Chris - would it work to use the hook you showed above, but limit it so it's only applied on the frontend so it doesn't break things in the admin?

Maybe I am still not understanding full though?