symfony 3.3 http_basic_ldap event for (successful) login?

0
votes

how do we run our code after user (successfully) logs in with http_basic_ldap?

http://symfony.com/doc/3.3/security/ldap.html#configuration-example-for-http-basic
(kudos to devs for making ldap login that easy!)

https://symfony.com/doc/3.3/components/security/authentication.html#authentication-events
i tried with AuthenticationEvents::AUTHENTICATION_SUCCESS and SecurityEvents::INTERACTIVE_LOGIN but either my code is wrong, or those events are not fired for http_basic_ldap.

my test src/AppBundle/EventSubscriber/LoginSubscriber.php:

namespace AppBundle\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Security\Core\AuthenticationEvents;
use Symfony\Component\Security\Http\SecurityEvents;

class LoginSubscriber implements EventSubscriberInterface
{
    public function onUserLogin ($dunno)
    {
        file_put_contents("/tmp/dunno.log", "yay, got called!\n", FILE_APPEND);
    }

    public static function getSubscribedEvents()
    {
        return [
            AuthenticationEvents::AUTHENTICATION_SUCCESS => 'onUserLogin',
            SecurityEvents::INTERACTIVE_LOGIN => 'onUserLogin',
        ];
    }
}

ps. my goal is to load the users roles from symfony database/entity (but always login through ldap).

1
symfony

1 Answers

0
votes

the code above does work for http_basic_ldap!
(and it seems even with both events, only once after login)

the problem was that debian9 now has PrivateTmp=true for apache2 service, so writing to /tmp/dunno.log with php through apache2 won't write to /tmp/dunno.log, but to /tmp/some-long-random-string/tmp/dunno.log...

as this is our (virtual) dev machine, i dont care about such things, so heres how to deactivate that:

sudo -i
cat <<- 'EOF' > /etc/systemd/system/apache2.service.d/override.conf
[Service]
PrivateTmp=false
EOF
systemctl daemon-reload
systemctl restart apache2

ps. i could make excuses like "i didn't even know the feature PrivateTmp existed", or "if the dir name was apache2.service-systemd-private-c23fc69cc5ae4f89bcf2e1317081f152-ZfVyIg instead of systemd-private-c23fc69cc5ae4f89bcf2e1317081f152-apache2.service-ZfVyIg i probably could have spotted it easier"...