Superuser when bootstrapping

[apeisa]

When you have bootstrapped pw it would be nice to have superuser rights. Ie. now if you bootstrap and use selector like:

$roles->find("name=guest") it returns zero results. If you have bootstrapped, you probably have no reason for access management (not 100% sure though)?

[ryan]

Technically all API access is superuser, since the API doesn't pay any attention to the user. But there is one exception: any function that returns a PageArray will filter out results that the current user doesn't have access to. That's done as a convenience so that you don't have to check access for every page that gets returned from a find() operation. It's also necessary for things like pagination to function with low overhead. These options are provided so that you can change that behavior for any given find operation:

<?php
$pages->find("[selector], include=all"); // include ALL results, with no access or status filtering
$pages->find("[selector], include=hidden"); // allow inclusion of results that have 'hidden' status
$pages->find("[selector], check_access=0"); // don't check access (roles) when finding results

However, when calling find() from $users->find(), $roles->find() or $permissions->find(), it's supposed to automatically add the "include=all" for you, and it wasn't. So that was bug that was limiting access too much. I've just fixed it in the latest commit, thanks for finding it.

As for making the bootstrap API assume the user is superuser for $pages->find() operations, I'm reluctant to do that just because I think whether that's desirable or not really depends on the context. If I was bootstrapping the API for use in some other application, I would still want PW to honor my permission settings in $pages->find() operations the majority of the time. But for the times you don't, add the "include=all" to your selector, or change the user to be who you want:

<?php
$users = wire('users'); 
$superuser = $users->get("apeisa"); 
$users->setCurrentUser($superuser); 

[apeisa]

Ryan, thanks for your answer and fix. That all makes sense. Those $users, $permissions and $roles were exactly what we were playing with. My co-worker has some kind of magical php-shell where he bootstraps pw and these issues came there (also addRoles() stuff I posted, but that was probably just misunderstanding from our behalf (probably thinking in 2.0 way...), will check it again tomorrow). I will post about that shell more too soon, it is very interesting stuff.

[ryan]

My co-worker has some kind of magical php-shell where he bootstraps pw and … I will post about that shell more too soon, it is very interesting stuff.

Sounds intriguing–I'm very interested in hearing more about this.

[bernhard]

9 years later I hit the same wall ? 

I have a kickstart script that installs several modules. I got this error:

ERROR: application encountered an error and can not continue. Error was logged.

Then I found this log in /site/assets/logs/tracy/exception.log:

[2020-12-14 20-17-00] ProcessWire\WirePermissionException: You do not have permission to execute this module - ProcessDatabaseBackups in \wire\core\Modules.php:1337  @  CLI (PID: 15532): site/modules/RockBuilder/kickstart.php  @@  exception--2020-12-14--20-15--dd5f3e67ab.html

When setting the user to the superuser everything works:

<?php namespace ProcessWire;
/** @var Wire $wire */
include("index.php");
$users->setCurrentUser($users->get(41));

 

[schwarzdesign]

@bernhard Can you use $modules->getModule() with the noPermissionCheck option? I haven't tried it yet, but according to the documentation it should bypass permission checks.

We had a similar problem with a script that updates the database dump included in the site profile for our base installation. I solved it in the same way as you, by manually setting the current user to the superuser:

use Composer\Script\Event;
use ProcessWire\ProcessExportProfile;

use function \ProcessWire\wire;
use function \ProcessWire\fuel;

class SchwarzdesignDevTools {
    /** @var string The path of the webroot. */
    public const PUBLIC_WEBROOT_DIR = __DIR__ . '/../../../public/';

    /** @var string The name of the site profile. */
    public const SITE_PROFILE_NAME = 'site-schwarzdesign';

    /**
     * Script to update the database dump included in the schwarzdesign site profile.
     *
     * @param Event|null $event
     * @return void
     */
    public static function createDatabaseDump(?Event $event = null): void
    {
        // bootstrap processwire
        require_once self::PUBLIC_WEBROOT_DIR . 'index.php';
        // set the "current user" to the superuser to enable access to the site profile export module
        $users = wire('users');
        $superuser = $users->get(wire('config')->superUserPageID);
        $users->setCurrentUser($superuser);
        // initialize the profile exporter
        $processExportProfile = wire('modules')->get('ProcessExportProfile');
        // dump the database into the site profile
        $path = self::PUBLIC_WEBROOT_DIR . self::SITE_PROFILE_NAME . '/install/';
        $processExportProfile->mysqldump($path);
        $realpath = \realpath($path);
        echo "Database successfully dumped to {$realpath}/install.sql!" . \PHP_EOL;
    }
}