Option "pagefileSecure" Breaking Image Visibility in User Profiles

[netcarver]

Summary

Setting pagefileSecure seems to prevent a user from viewing images in their profile page, even though they have permissions to do so.

Expected behavior

A logged-in user, with correct permissions, should be able to view their profile image in AdminThemeReno when pagefileSecure is true.

Actual behavior

Setting the pagefileSecure flag to true in the config file and then logging in as a non-super-user stops their profile image from showing within their profile page, despite them having permissions that should allow this field to be editable (and even visible) by/to the user. In addition, if you have the option enabled, the Reno Theme fails to show the user avatar in the navigation bar.

Screenshots that demonstrate the issue

Super-user view of a non-super-user user page. All is normal.

The Photo field is setup to allow users to edit it in their own profile permissions...

Yet here is the same page's photo field as seen when the user visits their profile page with pagefileSecure set to true.

A look at the network inspector shows the request for the image is being greeted with a 404.

Suggestion for a possible fix

When following the link the inputfield is generating to fetch the image, I'm seeing the following notice...

Trying to get property of non-object in public_html/wire/modules/PagePermissions.module on line 254

Further investigation shows that this is generated by the following code in the conditional statement on line 254...

$this->wire('page')->process == 'ProcessProfile'

...removing this part of the conditional restores visibility when pagefileSecure is true - yet is probably unsafe as I'm totally ignorant of any side-effects of doing so.

Steps to reproduce the issue

1. Add an image field to the user template.
2. Set pagefileSecure = true in the config file.
3. As super user add an image to a non-super-user's image field.
4. Make sure the image field is added to the user's profile privilages.
5. In an incognito session, log in on the non-super-user's account and visit the profile.

Setup/Environment

• ProcessWire version: 3.0.105
• PHP version: 7.2

[ryancramerdesign]

Thanks @netcarver I've pushed a fix for this one. Please let me know if you find any issues with it. Thanks.

[netcarver]

@ryancramerdesign That seems to fix it here, thank you! Closing issue.

[kixe]

This issue should be reopened. The bug was "restored" in the last commit to PagePermissions module.

FIXED
processwire/processwire@b6ec6cd
Lines 269 – 271 added

FIX REVOKED
processwire/processwire@3485aa8
Lines 269 – 271 removed

[netcarver]

@kixe Thanks Christoph, reopened for @ryancramerdesign

[kixe]

@ryancramerdesign
Reminder: Could you please look into it? Thanks!

[ryancramerdesign]

@kixe That bit of code that you mention was problematic because it assumed that the user was allowed to view just because it was data that is attached to their account. And maybe this is correct it many instances, but for others it isn't. So it was replaced with a 'user-view-self' permission. You can add this permission automatically by going to Access > Permissions > Add New, and it's a selectable option. Then you can add that permission to a user's role. Do you find this provides what you need?

[kixe]

@ryancramerdesign Thank you for the explanation. The additional permission meets my needs. Issue can be closed. Would be great to find a description of the additional permissions like "user-view-self" or "user-view-*" (*role)
Maybe here? https://processwire.com/docs/user-access/permissions/