Concept of Debug Activators

[xepozz]

There are a few places that can be redesigned to be scalable:

• yii-debug/src/Debugger.php

  Line 42 in cd4fe68

  if ($event instanceof BeforeRequest && $this->isRequestIgnored($event->getRequest())) {

• yii-debug/src/Debugger.php

  Line 47 in cd4fe68

  if ($event instanceof ApplicationStartup && $this->isCommandIgnored($event->commandName)) {

There are checks that disable (not enable) collectors' startup.
Thinking global it could be a list of classes/closures that can activate the Debugger.

It may be useful in production, when you want to enable debug only for your network/list of users/state of application/any logic.

[samdark]

That would a pretty big list, wouldn't?

[xepozz]

Possible (de)activators:

• command name / route name / request path
• user id
• user role
• ip subnet
• secure cookie
• session flags
• http header
• query parameter
• user callback

I think 1 or two will be used by default, like command/route names + ip subnet mask

[samdark]

What do you think of such concept?

interface ActivatorInterface // is there a better name?
{
    // null = no idea, true = activate, false = deactivate
    public function isActive($event): ?bool;
}

final class CompositeActivator implements 
{
    public function __construct(private array $activators)
    {}

    public function isActive($event): ?bool
    {
        foreach ($this->activators as $activator) {
            // how to deal with true-false situation?
            $result = $activator->isActive();
            if (is_bool($result)) {
                return $result;
            }
        }
        return false;
    }
}

final class IgnoreRequestActivator implements ActivatorInterface
{
    public function __construct(
        private array $urls = []
    )
    {
    }

    public function isActive($event): ?bool
    {
        if (!$event instanceof BeforeRequest) {
            return null;
        }

        return $this->isRequestActive($event->getRequest());

}


final class IgnoreCommandActivator implements ActivatorInterface
{
    public function __construct(
        private array $commands = []
    )
    {
    }

    public function isActive($event): ?bool
    {
        if (!$event instanceof ApplicationStartup) {
            return null;
        }

        return $this->isCommandActive($event->commandName);
    }
}

final class EverythingActivator implements ActivatorInterface
{
    public function isActive($event): ?bool
    {
        return true;
    }
}

Configuration for Debugger could be then:

'activators' => [
    new IgnoreRequestActivator(urls: ['a', 'b']),
    new IgnoreCommandActivator(commands: ['a', 'b']),
    new EverythingActivator(),
],

[xepozz]

Or we can make it as psr middlewares look like: passing next handler into the activator method, I like more the second option, but it's open for discussion.

Basically, activator may be connected to any point in the application: catch request and check user ip, listen for "authenticated" event and check role, listen for an exception, parse command line arguments.

In general looks good, I'd also use enums as a ?bool replacement.

Also I think it cannot be just a class that only returns true/false, but be a service that call debugger? Just thinking.

[vjik]

Also it may be useful to use this concept for each collector separately.