Decoración: Anular los servicios del núcleo y AsDecorator

Thanks! Maybe aditional videos for Bridge, Proxy, Chain of responsibility and Visitor designs patterns.

Thank you for the suggestions Vincent!

Ups. It's last chapter.
This theme is really interesting.
You have to add some patterns more! :)
Pattern Filter for example .

Hey Ruslan,

Thank you for your feedback! It may happen in the future ;) For now, we're focusing on other topics :)

Cheers!

Hi,
Thank you for OOP course.

Small note:

• "I'll just paste in the finished version: you can copy this from the code block on this page. We're simply calling the inner dispatcher in every method."

Looks like I don't see/find "the code block on this page".

Weird enough, I got that error

#message: "App\Decorator\DebugEventDispatcherDecorator::addListener(): Argument #2 ($listener) must be of type callable, array given, called in /srv/app/vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php on line 59"

Digging into Symfony\Component\EventDispatcher\EventDispatcher i found that addListener's signature looks like this:

public function addListener(string $eventName, callable|array $listener, int $priority = 0)

but the interface has this:

public function addListener(string $eventName, callable $listener, int $priority = 0);

Is it a bug in Symfony?

I fixed it on my code changing the signature of my decorator's method to match the signature from the component's method.

public function addListener(string $eventName, callable|array $listener, int $priority = 0)
{
    $this->eventDispatcher->addListener($eventName, $listener, $priority);
}

Cheers!

Hey @julien_bonnier!

That IS interesting! Hmm. So it's legal for a concrete implementation (e.g. EventDispatcher) to widen (i.e. allow more types) the arguments for a method from an interface. If the interface has callable $listener, it is legal for the concrete class to have callable|array $listener.

However, in practice this means that if someone ever calls ->addListener() and passes an array for the $listener argument, that "someone" should be type-hinting EventDispatcher and not EventDispatcherInterface. In other words, doing this would work, but you're kind of breaking the rules:

public function something(EventDispatcher $dispatcher)
{
    $dispatcher->dispatch('some_event', [$this, 'bar']);
}

The fact that you got this error makes me think that, in fact, something, somewhere is doing exactly that. The problem is that, wherever this is happening, if the type-hint changed from EventDispatcherInterface to EventDispatcher (so that it's more "honest"), that would totally break the ability to decorate the event dispatcher.

So... yes, something is "not right" here. But I'm not sure exactly what it is. It might simply be that, in reality, Symfony relies on $listener being able to be an array in some cases... and that the "bug" is that we need this... but we haven't make the $listener argument in the interface match this reality. I can't locate the history in Symfony where this changed, so I don't know if this was intentional or accidental. Interesting!

Cheers!

Not sure if you know about this GitHub issue. Seems like an issue that is likely to keep coming up.

Hi SymfonyCasts,

Great tutorial, as always.

I'm trying to decorate the HttpBasicAuthenticator class.
Because i want to change the support function.
But for some reason my decorator class is not reached (debugger does not stop there but it does stop in support function in original httpBasicAuthenticator class).
Could you help me out please?
Thanks in advance...

This is what i get for bin/console debug:container security.authenticator.http_basic

 // This service is a private alias for the service App\Decorator\AddSupportHttpBasicAuthenticatorDecorator

Information for Service "App\Decorator\AddSupportHttpBasicAuthenticatorDecorator"
=================================================================================

 ---------------- ---------------------------------------------------------
  Option           Value
 ---------------- ---------------------------------------------------------
  Service ID       App\Decorator\AddSupportHttpBasicAuthenticatorDecorator
  Class            App\Decorator\AddSupportHttpBasicAuthenticatorDecorator
  Tags             monolog.logger (channel: security)
  Public           no
  Synthetic        no
  Lazy             no
  Shared           yes
  Abstract         no
  Autowired        yes
  Autoconfigured   yes
  Usages           security.authenticator.http_basic
 ---------------- ---------------------------------------------------------


 ! [NOTE] The "security.authenticator.http_basic" service or alias has been removed or inlined when the container was
 !        compiled.

This is my decorator class 'AddSupportHtppBasicAuthentication'

namespace App\Decorator;

use Symfony\Component\DependencyInjection\Attribute\AsDecorator;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Exception\AuthenticationException;
use Symfony\Component\Security\Http\Authenticator\AuthenticatorInterface;
use Symfony\Component\Security\Http\Authenticator\Passport\Passport;
use Symfony\Component\Security\Http\EntryPoint\AuthenticationEntryPointInterface;


#[AsDecorator(decorates: 'security.authenticator.http_basic')]
class AddSupportHttpBasicAuthenticatorDecorator implements AuthenticatorInterface, AuthenticationEntryPointInterface
{

    public function __construct(
        private readonly AuthenticatorInterface $authenticator,
        private readonly AuthenticationEntryPointInterface $entryPoint)
    {
    }

    public function start(Request $request, AuthenticationException $authException = null): void
    {
        $this->entryPoint->start($request, $authException);
    }

    public function supports(Request $request): ?bool
    {

        // custom code
        // .......
  

        return $this->authenticator->supports($request);
    }


    public function authenticate(Request $request): Passport
    {
        return $this->authenticator->authenticate($request);
    }

    public function createToken(Passport $passport, string $firewallName): TokenInterface
    {
        return $this->authenticator->createToken($passport, $firewallName);
    }

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, string $firewallName): ?Response
    {
        return $this->authenticator->onAuthenticationSuccess($request, $token, $firewallName);
    }

    public function onAuthenticationFailure(Request $request, AuthenticationException $exception): ?Response
    {
        return $this->authenticator->onAuthenticationFailure($request, $exception);
    }
}

Hey @Annemieke-B

I'm glad to know you like our tutorials. Your decorator it's fine, what you're missing is to add that new authenticator to the firewall

security:
    firewalls:
        main:
            custom_authenticators:
             - App\AddSupportHttpBasicAuthenticatorDecorator 
             ...

Give it a try, it should work. Cheers!

Thankyou for the quick reply.
I have made some changes and it works now, but i'm not sure if i have done it the correct way.
It's nice that it's working but i want it to be correct. So could you check?

• I've added this to my security yaml file.

  firewalls:
    ...
    main:
      custom_authenticators:
        - App\Decorator\AddSupportHttpBasicAuthenticatorDecorator
  

• I have removed AsDecorator in decorator class because i don't need it in this case, am i correct?

• I am only implementing one interface instead of two in the decorator class. So only AuthenticatorInterface and not AuthenticationEntryPointInterface because i think i don't need both, you only need one common interface between decorator class and the vendor class, correct?

• And i needed to do this in services.yml:

  App\Decorator\AddSupportHttpBasicAuthenticatorDecorator:
    arguments:
      - "@security.authenticator.http_basic_ldap.main"
  

So it works, but it has some weird behaviour. With the debugger i can see, that when enduser logs in, de support function in my decorator class is called twice and also the support function in vendor class.

Thanks in advance for helping me (again) .
Annemieke

Hey!

I have removed AsDecorator in decorator class because i don't need it in this case, am i correct?

Yes, it's not required to decorate it, if you need to reuse some of its code, you could use inheritance

I am only implementing one interface instead of two in the decorator class. So only AuthenticatorInterface and not AuthenticationEntryPointInterface because i think i don't need both, you only need one common interface between decorator class and the vendor class, correct?

Correct! The AuthenticationEntryPointInterface it's needed when you specify the "entry point" in your security.yaml file

With the debugger i can see, that when enduser logs in, de support function in my decorator class is called twice and also the support function in vendor class.

Hmm, that's a bit unexpected. Do both calls come from the same authenticator? Is something in the request triggering another request? Could you debug further and find out who's making the extra call?

Hey Ryan, what PHPStorm plugin gives you these icons in the project view and in the gutter? They seem to be related to Symfony, but I have the Symfony plugin installed, and nothing like that shows up...

Sorry for asking a question that you've probable answered a thousand times somewhere, but nonetheless – there's no way I'd be able to find the answer in this bottomless pit of Symfony courses that you produce😅 Keep up the great workl!

Hey Andrey,

That's another PhpStorm plugin that give you such icons, it's called "Atom Material Icons". Install it if you want to the same icons style :)

And don't worry, that's not something we've talked in the course, so the valid question ;)

Cheers!

Very good course, I loved it. Looking forward for this course extension of more patterns.

Cheers! If there are any specific patterns you'd like to see, let us know!

Hello Ryan,

Thanks for the tutorial :)

I have a question about the Decorator pattern. One of the features of this pattern is that you can decorate objects at runtime simply using the set of decorators, manually instantiating them and passing the previous as argument. And as you explained in Multiple decoration section, there is a way for multiple decoration in Symfony, but it is not clear how can we apply just some of decorators depending on runtime conditions? Thanks.

Hey Maxim!

Ah, cool question! The easiest way to do this is on an environment-by-environment basis. For example, to do something in the dev environment only, it would be as simple as (in services.yaml)

when@dev:
    # ... now add the decoration config

I think you can also do this with PHP attributes:

#[AsDecorator(decorates: ...)]
#[When(env: 'dev')]
class MyDecorator implements SomethingInterface
{
}

If you need to do something more complex, like via the value of an environment variable, I'm not sure if that is solvable simply with some config. It might be, but I don't know. What I would try to do is:

A) register your decorator service via services.yaml
B) But, set that decorator to be created via a factory service https://symfony.com/doc/current/service_container/factories.html
C) In that factory service, read the env var value to determine if you should instantiate the true decorator service or some "dummy"/blank decorator.

Cheers!

Design patterns through Symfony - many thanks to your team, that was like a Christmas gift for me! Please, add Adapter, Command or any other pattern, which could participate in Clean Architecture. Thank you in advance

Hey Alexander,

Thank you for your feedback! We're really happy to hear you liked the tutorial! :) We will add those additional patters to our idea pool for future tutorials. ;)

Happy new year!

Cheers!

Oh yeah, happy new year & Слава Україні!

Happy new year to you too! :) Героям слава!