Process module permission catch-22

[MarkE]

I have built a custom page-builder module 'ProcessMotif' (to be released if I ever get it working to my satisfaction!) and have hit a small snag with permissions.

The module is a process module and has a page that I want to appear on the main menu and be available to certain roles. The only way I can seem to get it to appear like that is to set the permission 'admin-motif' in the module info and assign it to the relevant roles. Without that permission set, the page is only visible to superusers.

However, the module also has a whole bunch of methods that need to be executed by guest and other users to navigate the site. If I give the module a permission, then I need to assign that permission to the guest role otherwise they can't see anything. I don't want to have to do that.

I get the feeling that I'm missing something obvious and basic here, but I've read all the stuff about process modules (especially the excellent stuff by @bernhard here and here) but am none the wiser on this point.

Anyone got any ideas? Ta.

[Robin S]

4 hours ago, MarkE said:

However, the module also has a whole bunch of methods that need to be executed by guest and other users to navigate the site.

I suggest using URL hooks for any requests coming from the front-end. It wouldn't be ideal to have front-end requests going to a Process module page in any case because that would decrease site security by publicly revealing the admin login URL.

[MarkE]

1 hour ago, Robin S said:

It wouldn't be ideal to have front-end requests going to a Process module page in any case because that would decrease site security by publicly revealing the admin login URL.

Perhaps I should have elaborated more: the methods (and static functions) are entirely called within the API from Page Class scripts, so the requests are not coming directly from the front end. Perhaps that gives me a clue - to assign the permission before making the calls?

EDIT:

So I added this around the main include script for the rendering using the module and it seems to work well without having to manually set (or save) permissions:

//Assign the required permission to access the ProcessMotif module temporarily
$guest = $roles->get('guest');
$guest->addPermission('admin');
$guest->addPermission('admin-motif');
// NB the permissions are not saved
include_once(wire('config')->paths->siteModules . 'ProcessMotif/include/_motif_include.php');
//Remove the temporary permission to access the ProcessMotif module
$guest->removePermission('admin-motif');
$guest->removePermission('admin');

 

[Robin S]

1 hour ago, MarkE said:

the methods (and static functions) are entirely called within the API from Page Class scripts, so the requests are not coming directly from the front end

I don't have a good sense of what you're doing in your code, but AFAIK Process module permissions should only be applicable to viewing the page of the Process module. I would have thought you would be able to do something like this...

$m = $modules->get('MyModule');
echo $m->myMethod($foo, $bar);

...regardless of if the current user is guest or not.

But great that you've found a solution.

[gebeer]

IMO your solution seems a bit hacky.

Don't know enough about the structure of your module and how you load it in your Page Classes. But here are 2 ways you could approach it.

You could use https://processwire.com/api/ref/modules/get-module/ which has an option noPermissionCheck which lets you load the module regardless of the current users permissions.

It seems that you have already isolated the required methods into _motif_include.php. You could refactor and put them in their own module (which depends on the main module and gets installed by it). That module could then have different permission settings. That would be a much cleaner approach IMO.

[MarkE]

9 hours ago, Robin S said:

I don't have a good sense of what you're doing in your code, but AFAIK Process module permissions should only be applicable to viewing the page of the Process module. I would have thought you would be able to do something like this...

$m = $modules->get('MyModule');
echo $m->myMethod($foo, $bar);

That's pretty much exactly what I am doing. I thought the permission would only apply to the page as well, but it seems that I am wrong.

7 hours ago, gebeer said:

You could use https://processwire.com/api/ref/modules/get-module/ which has an option noPermissionCheck

That doesn't work as it needs the permission to load the module with noPermissionCheck ?. It just results in "You do not have permission to execute this module..." without even any debugging!

7 hours ago, gebeer said:

IMO your solution seems a bit hacky.

?but it was a bit late last night

7 hours ago, gebeer said:

You could refactor and put them in their own module (which depends on the main module and gets installed by it). That module could then have different permission settings. That would be a much cleaner approach IMO.

Yeah I thought about that, but it was going to be a bit of a hassle compared with my little hack. Undoubtedly this is the right answer given that I (together with@Robin S, so I am in good company) was wrong in my assumption as to how the permissions work.

I note that 'Process module king'  @bernharddid a little module "RockHitCounter" where he adopted this approach, presumably for the same reason - so that the page is in a separate Process module with the permission, which is installed by the main module which has no permission.

[gebeer]

1 hour ago, MarkE said:

That doesn't work as it needs the permission to load the module with noPermissionCheck ?. It just results in "You do not have permission to execute this module..." without even any debugging!

Thanks for clarifying this. I hadn't tested it before suggesting it as potential solution. But I had some cases in the past where this resolved my module permission issues.

[ryan]

@MarkE If it's a Process module (i.e. extends the Process class) then that's a module designed to be an application in the admin, and that module is only executed when clicked on in the navigation (assuming the user has permission for it). 

It sounds like you also need a module that has the "autoload" enabled, meaning that it either loads every time PW boots, or under some autoload condition that you define. Process modules aren't meant to be "autoload" modules. Process modules are interactive applications, creating and processing forms in the admin. Autoload modules hook into ProcessWire and adjust runtime behavior. These are very different responsibilities, so you want 2 modules: one Process module and one autoload module. For instance, there's FormBuilder and ProcessFormBuilder, UserActivity and ProcessUserActivity, ProCache and ProcessProCache, etc. 

If you absolutely had to have it all in a Process module, you could, but you'd have to do your own permission check in the execute() method(s), and your module would appear in the admin navigation even for people that didn't have access to it. It's cleaner to do it with two modules, and one can install/uninstall the other just by using the "installs" property in your module info for one of them, and "requires" for the other. 

[MarkE]

3 hours ago, ryan said:

It's cleaner to do it with two modules, and one can install/uninstall the other just by using the "installs" property in your module info for one of them, and "requires" for the other. 

That's exactly what I've now done and it works fine. It was a bit of a hassle refactoring it, but worth it. Thanks to all ?