Jump to content

Superuser when bootstrapping


apeisa
 Share

Recommended Posts

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); 
  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 9 years later...

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));

 

  • Like 1
Link to comment
Share on other sites

@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;
    }
}

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...