How-to hide some/all images in a private Processwire installation used for note-taking?

[SwimToWin]

How might I hide some/all images in a private Processwire installation used for note-taking?

Acceptance criteria
* Hidden image file url is never accessible
* Hiding images per page is preferred (as opposed to hiding all pages for the site via .htaccess or similar)

Suggested solutions (that I currently don't know how to implement):
* ProcessWire module controls output of image files
* PHP file to control image output ("/img.php?file=img_1234.png")?
* .htaccess hinder external access to all image files (will work as a last resort)

The Processwire installation in question is being used for personal purposes (think Notion.os, Evernote, etc.).

[BrendonKoz]

Template settings (along with role management/assignment in user administration) should handle all of the scenarios you list. Here's a screenshot of the template edit screen's "Access" tab... In the first section, you could choose "Yes" to limit access to any pages using the template you're editing (in this case the "basic-page" template; likely not the one you'd choose) and assign a role, or roles, that can access pages created with this template.

The second section would prevent using direct URL access to any file(s) held on pages created with this template.

Be default, images and files are associated/stored relative to each page.

[wbmnfktr]

As much as I support @BrendonKozanswer... I really don't understand what you want to accomplish.

Do you want to hide images from backend or frontend users?
And if so... what should be the result to which?

There is always the option to secure PageFiles. But.... does this fit to your task/question?

[SwimToWin]

@BrendonKoz I'm aware of this possibility that doesn't satisfy the acceptance criteria because the image file is directly accessible (for instance, when a search engine or web spider somehow finds the direct image url).

@wbmnfktr Most pages in this website are used for private note-taking and images (think Notion.os, Evernote, etc.). I don't share my private notes.. ?

[Jan Romero]

4 hours ago, SwimToWin said:

I'm aware of this possibility that doesn't satisfy the acceptance criteria because the image file is directly accessible (for instance, when a search engine or web spider somehow finds the direct image url).

I don’t think this is true. That’s the whole point of the secure files setting. It will only deliver the requested file if you’re logged in. So you can know the URL all you want, you also need a valid session cookie and potentially other fingerprinting stuff (eg. the correct IP).

[SwimToWin]

@Jan Romero Steps to reproduce:

1. Create page with image
2. Edit page to get image url. It will look like so: https://www.example.com/site/assets/files/9999/foo.0x260.png
3. Log out (or open a private browser session). Go to the link
4. Result: Image is shown

[zoeck]

You have to use $config->pagefileSecure https://processwire.com/api/ref/config/#api-pagefileSecure

like @wbmnfktrSaid..

(then you have to set the rights to the page/Template!)

[SwimToWin]

@zoeck, @wbmnfktr - Works. Thanks!

How to protect / hide image files (info for others):

Method 1:

1. config.php: Add "$config->pagefileSecure = true;" #
2. Go to the Page template
3. Revoke "view pages" permissions for the "guest (everyone)" role to ensure guests have no permissions.
4. Result:
   1. Page is now inaccessible unless you're logged in (as expected)
   2. When using a direct link to the image file, the Image file is also protected
      1. I had to save the page before linked image files became protected (so there seems to be an issue for image files on existing pages)
      2. Image files on new pages are protected right away

Method 2:

1. Edit the page directly
2. Set Page status to Unpublished
3. Result:
   1. Page is now inaccessible unless you're logged in (as expected)
   2. When using a direct link to the image file, the Image file is also protected

[BrendonKoz]

19 hours ago, SwimToWin said:

@BrendonKoz I'm aware of this possibility that doesn't satisfy the acceptance criteria because the image file is directly accessible (for instance, when a search engine or web spider somehow finds the direct image url).

I led you towards where to look, but didn't show all of the involved steps. It actually is able to prevent access. After re-reading everything, it might be too restrictive for what you're trying to do though, so I am glad that you found a way to get things working.

I set up a quick PW install just to test this and verify I wasn't remembering wrong, so any images that are shown may be minimal simply because I chose the Blank profile for testing purposes. In this quick test, I did modify the basic-page template simply so I didn't have to create another template, and the homepage is still accessible by any user.

Here's a screenshot of the settings, from the access tab of the basic-page template, that restricts access to viewing pages using this template, viewing/accessing any assets belonging to pages created with this template, and preventing search from returning any pages created with this template (unless the user is a super user, since a blank profile only has the super user [default account: admin] and guest roles).

Using the settings as shown will not allow access. Setting $config->pageFileSecure wasn't necessary here. This is essentially the same as your Method #1. ?  In the settings I show above, I also chose to redirect any guest user to a login page so that I wouldn't have to create any additional templates. Sending someone to a login page is a perfectly reasonable solution, though it might be preferred to send to another page instead (which the template settings allow you to choose to do).

When logged in or not (the homepage):

 

When logged in (the basic-page example):

...and when not logged in:

...and when not logged in and trying to access the image by direct URL (which a search engine realistically should not be able to know):

https://example.com/site/assets/files/1015/1526898_10152005302794342_1548624436_n.jpg

Interestingly, it seems like the 404 for the Blank Profile is redirecting to basic-page which is now supposed to be role/profile locked. I think this is a tiny oversight in the provided files for the blank profile that cause this, and an expectation that basic-page would not be role/profile locked. In a real site, the chances of that happening are slim. (I'm surprised it even rendered it, to be honest; in this instance I probably would've expected a 500 error, so it's actually kind of nice that it forced the render for the 404.)