Alternate user template / parent page potentially viewable via /processwire/access/users/my-name/

[adrianbj]

Short description of the issue

If you are using the alternate user template/parent setup and a user that has a frontend viewable template gets moved to the processwire/access/users parent, then their page will be viewable at https://mysite.com/processwire/access/users/my-name/ even for guest users.

Expected behavior

Because this page is now effectively an admin page, it should not be viewable by guest users. They should get the login dialog instead.

Actual behavior

They see the page at that admin URL using the viewable template it's assigned to.

Steps to reproduce the issue

1. Setup alt template/parent users
2. Create viewable template for a user
3. Move that user to processwire/access/users/ parent via the Parent select field on the user's Settings tab.
4. View the page as a guest user.

[ryancramerdesign]

@adrianbj Do you have access control enabled for that user template? If so, it's no longer inheriting access from the admin template, so you'd need to control access from your user template instead. Alternatively, you can turn off access control for it, and then it should inherit from the admin template again.

[adrianbj]

Hi @ryancramerdesign - no, access control is off

[ryancramerdesign]

@adrianbj I can't duplicate it here. These are all the steps I take setting up alternate user templates and parents. Anything I'm missing, or any variation from what you did?

• Created template user2 and set page class as User in the template settings.
• Created template users2, set it to allow children of template "user2" or "user".
• Updated template user2 to allow users2 and admin as parent templates.
• Created parent /users2/ using template users2.
• Updated /site/config.php for userTemplateIDs and usersPageIDs.
• Created template file user2.php to output "Hello world".
• Created /users2/user2 as new user
• Viewed /users2/user2 as both superuser and guest.
• Moved user2 to /processwire/access/users/user2 using Settings tab on user2 page editor.
• Viewed /users2/user2 as superuser, but got login screen when attempting to view as guest.

[adrianbj]

Thanks for testing this @ryancramerdesign - I have finally figured out the key factor and it relates to this issue: #1455

In my alternate user branch/template setup I have some users that don't need to be able to login and some that do. The problem (as outlined in that other issue) is that those users that don't need to login can't be viewed on the frontend (their public bio page) without assigning them a limited admin role, so I give them a frontend-person role and then assign the user-view-frontend-person to the guest role so that guest users can actually view them.

The problem is that this approach triggers this line: https://github.com/processwire/processwire/blob/3cc76cc886a49313b4bfb9a1a904bd88d11b7cb7/wire/modules/PagePermissions.module#L302 to return true even when the user has been moved to the admin users branch.

Please let me know if anything still isn't clear.

Thanks again!

[adrianbj]

Just also wanted to note that because PagePathHistory will track the movement of the page from it's original frontend branch to its new home under admin/users, all of a sudden we have a mechanism which will expose the name/url of the admin page which we might have intentionally modified to something custom.

I guess ideally I would like a way for user-view-guest to work so there would be no need for a custom role for these frontend user pages. I suppose care would still need to be taken to ensure user-view-guest doesn't allow guests to view users than are under the admin user parent though.

[ryancramerdesign]

@adrianbj The user-view-* permissions there there to make the user viewable. It's not a permission I would recommend assigning to the guest user. But if it otherwise suits your purpose, then you will have to work around it a bit for your custom output needs. But if I understand your case correctly, maybe one of two approaches (or a combination of both) would be preferable?

1. A User::viewable hook to insert your own logic into when a user is viewable; or
2. A gateway page like /users/ where a user is identified in urlSegment1, i.e. /users/adrian/ and you map that to the user when you want the user viewable, or wire404() when you don't, i.e.

$name = $input->urlSegment1;
if($name) {
  $u = $users->get($name);
  if(!$u->id) wire404();
  if(!$u->hasRole('frontend-user')) wire404();
  // render user profile info
} else {
  // list users having role, or those you want to be viewable
}

[adrianbj]

@ryancramerdesign - I have been doing this for a long time. I always assumed, based on your words

For instance, if you were running a publication with lots of authors, you might like for those 'author' users and their biography pages to be one and the same.

from here: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users that this was an acceptable practice. Is there some other approach that you recommend to let guests view these biography pages without giving them a user-view-* permission

[ryancramerdesign]

@adrianbj I think your approach is fine if you are limiting it to your front-end users page. But it sounds like you aren't differentiating between those users and those in the admin. So add something like parent=1234 in your user(s) finding selectors, so that you are focusing on those you want to use for front-end purposes. But if you don't want to do that, then I'd recommend those I mentioned in my previous message. An example of a hook might be:

$wire->addHookAfter('User::viewable', function($e) {
  if(wire()->user->hasPermission('user-admin')) return;
  // where 1234 is your front-end users parent id
  $e->return = $u->parent_id == 1234 && $u->status < Page::statusHidden;
}); 

…or an example of a page template file for the parent users page ID 1234:

$name = $input->urlSegment1;
if($name) {
  $u = $users->get($name);
  if($u->parent_id !== $page->id || $u->status < Page::statusHidden) wire404();
  // render user profile info
} else {
  // list front-end users
  echo $page->children->each("<li><a href='./{name}'>{name}</a></li>"); 
}

[adrianbj]

@ryancramerdesign - I am definitely differentiating between frontend users and those under the admin. I think perhaps the thing that could solve all my potential problems is simply re-checking the "Don't allow pages to be moved" on the frontend user template so that they can't be accidentally moved back under the admin access/users parent.

Is there actually a reason you say that option needs unchecking to make things work - I can't see why it's needed.

[adrianbj]

Or should the PW core just simply prevent viewing of any pages under the admin branch (with the exception of repeaters etc)?

I still do wonder about my other issue around the user-view-guest permission though - if the alternate parent/template user setup is designed to allow frontend viewing of users, then why can't it also view users with only the guest permission - I think it's not unusual to have (for example) blog authors who don't actually edit any admin permissions - someone posts their article for them, but assigns that user as the author.

[adrianbj]

An update on this one, since a couple of things have moved:

• The side thread here about user-view-guest (Missing / not working "user-view-guest" permission #1455) is now resolved by 203d49ca on dev — thanks Ryan! The permission is generated and honored for users whose only role is guest.
• The main issue reported here is still present though, and note that the new user-view-guest path has the same behavior: for User pages, Page::viewable() delegates entirely to PagePermissions::userEditable(), so any user-view-* permission held by the guest role (which is the reproduce condition Ryan was missing — hence the "can't reproduce" label) makes a user page render at its admin URL for non-logged-in visitors, with the admin template's login requirement never getting a say.

I've submitted processwire/processwire#357 which adds a guard in the viewable branch of userEditable(): user pages located within the admin branch are never viewable to users that are not logged in, so guests get the login screen there instead (matching the expected behavior in this report). Logged-in users with user-view-* permissions and user pages under front-end parents are unaffected — verified end-to-end on a live install with the alternate template/parent setup from the steps above.

Re my PagePathHistory concern: in testing on current dev, moving the user to the admin parent didn't leave a redirecting path history entry — the old front-end URL just 404s for guests — so that part appears to be a non-issue.