I want to alter default authentication process just after authentication success. I made a service that is called after authentication success and before redirect.
namespace Pkr\BlogUserBundle\Handler;
use Doctrine\ORM\EntityManager;
use Pkr\BlogUserBundle\Service\Encoder\WpTransitionalEncoder;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpKernel\Log\LoggerInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Http\Authentication\AuthenticationSuccessHandlerInterface;
use Symfony\Component\Security\Http\Authentication\Response;
class AuthenticationSuccessHandler implements AuthenticationSuccessHandlerInterface
{
protected $entityManager = null;
protected $logger = null;
protected $encoder = null;
public function __construct(EntityManager $entityManager, LoggerInterface $logger, WpTransitionalEncoder $encoder)
{
$this->entityManager = $entityManager;
$this->logger = $logger;
$this->encoder = $encoder;
}
/**
* This is called when an interactive authentication attempt succeeds. This
* is called by authentication listeners inheriting from
* AbstractAuthenticationListener.
*
* @param Request $request
* @param TokenInterface $token
*
* @return Response never null
*/
public function onAuthenticationSuccess(Request $request, TokenInterface $token)
{
$user = $token->getUser();
$newPass = $request->get('_password');
$user->setUserPassword($this->encoder->encodePassword($newPass, null));
$this->entityManager->persist($user);
$this->entityManager->flush();
//do redirect
}
}
in services.yml
services:
pkr_blog_user.wp_transitional_encoder:
class: "%pkr_blog_user.wp_transitional_encoder.class%"
arguments:
cost: "%pkr_blog_user.wp_transitional_encoder.cost%"
logger: @logger
pkr_blog_user.login_success_handler:
class: Pkr\BlogUserBundle\Handler\AuthenticationSuccessHandler
arguments:
entity_manager: @doctrine.orm.entity_manager
logger: @logger
encoder: @pkr_blog_user.wp_transitional_encoder
and in security.yml
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
secured_area:
pattern: ^/
anonymous: ~
form_login:
login_path: pkr_blog_admin_login
check_path: pkr_blog_admin_login_check
success_handler: pkr_blog_user.login_success_handler
logout:
path: pkr_blog_admin_logout
target: /
What I'm trying achieve is to just alter default behavior a little so I think why not to extend DefaultAuthenticationSuccessHandler
, add something to onSuccessHandler()
and call parent::onSucessHandler()
. I tried and the problem is that I have no clue how to add security parameters (set in security.yml) to my extended class constructor. DefaultAuthenticationSuccessHandler uses HttpUtils and $options array:
/**
* Constructor.
*
* @param HttpUtils $httpUtils
* @param array $options Options for processing a successful authentication attempt.
*/
public function __construct(HttpUtils $httpUtils, array $options)
{
$this->httpUtils = $httpUtils;
$this->options = array_merge(array(
'always_use_default_target_path' => false,
'default_target_path' => '/',
'login_path' => '/login',
'target_path_parameter' => '_target_path',
'use_referer' => false,
), $options);
}
So my extended class constructor should look like:
// class extends DefaultAuthenticationSuccessHandler
protected $entityManager = null;
protected $logger = null;
protected $encoder = null;
public function __construct(HttpUtils $httpUtils, array $options, EntityManager $entityManager, LoggerInterface $logger, WpTransitionalEncoder $encoder)
{
$this->entityManager = $entityManager;
$this->logger = $logger;
$this->encoder = $encoder;
}
It's quite easy to add HttpUtils service to my services.yml
, but what with options argument?
services:
pkr_blog_user.wp_transitional_encoder:
class: "%pkr_blog_user.wp_transitional_encoder.class%"
arguments:
cost: "%pkr_blog_user.wp_transitional_encoder.cost%"
logger: @logger
pkr_blog_user.login_success_handler:
class: Pkr\BlogUserBundle\Handler\AuthenticationSuccessHandler
arguments:
httputils: @security.http_utils
options: [] #WHAT TO ADD HERE ?
entity_manager: @doctrine.orm.entity_manager
logger: @logger
encoder: @pkr_blog_user.wp_transitional_encoder
actually the best way to do this is to extend default auth handler as service
and the AuthenticationHandler class would look like
If you only have one success / failure handler defined for your application, there's a slightly easier way to do this. Rather than define a new service for the
success_handler
andfailure_handler
, you can overridesecurity.authentication.success_handler
andsecurity.authentication.failure_handler
instead.Example:
services.yml
AuthenticationSuccessHandler.php
AuthenticationFailureHandler.php
In my case, I was just trying to set something up so that I could get a JSON response when I try to authenticate using AJAX, but the principle is the same.
The benefit of this approach is that without any additional work, all of the options that are normally passed into the default handlers should get injected correctly. This happens because of how SecurityBundle\DependencyInjection\Security\Factory is setup in the framework:
It specifically looks for
security.authentication.success_handler
andsecurity.authentication.failure_handler
in order to merge options from your config into the arrays passed in. I'm sure there's a way to setup something similar for your own service, but I haven't looked into it yet.Hope that helps.
You can easily see how default security listeners are manage in this file :
vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/Resources/config/security_listeners.xml
For example, DefaultAuthenticationSuccessHandler is registered like that:
So finally we can see that the option collection is empty by default !
options: {}
will do the job ^^ (Think a collection is represent by {} in yaml)For the best solution so far scroll to bottom of this answer
OK I finally got it working in a way I wanted. The problem was that Symfony2 was not passing config array from
security.yml
to constructor when custom handler is set. So what I did was:1) I removed custom handler declaration from
security.yml
2)
AuthenticationSuccessHandler
extends default handler class, rehash user password and finally let default handler do the rest. Two new arguments was added in constructor:3) added and changed some parameters in my
services.yml
so I could use them in my compiler pass class:4) created a compiler pass class
RehashPasswordPass
that changes default authentication success handler and adds some parameters to constructor:5) added compiler pass to container builder:
Now default handler class was changed but symfony will still pass configuration from
security.yml
to constructor plus two new arguments added by compiler pass.The better way
And it's all working, no compiler pass needed. Why didn't I thought of that from the begining...
Uhh it stopped working after symfony update
Now I get exception:
ScopeWideningInjectionException: Scope Widening Injection detected: The definition "pkr_blog_user.authentication_success_handler" references the service "request" which belongs to a narrower scope. Generally, it is safer to either move "pkr_blog_user.authentication_success_handler" to scope "request" or alternatively rely on the provider pattern by injecting the container itself, and requesting the service "request" each time it is needed. In rare, special cases however that might not be necessary, then you can set the reference to strict=false to get rid of this error.
It seems that I need to pass full container to my service. So I modified
services.yml
and event handler class.And it works again.
Best way so far
The solution above was best I knew until @dmccabe wrote his solution.
Unfortunately by using the
success_handler
option in the security configuration you can't provide a custom listener that extendsDefaultAuthenticationSuccessHandler
.Not until this issue is fixed: Symfony issue - [2.1][Security] Custom AuthenticationSuccessHandler
Until then the simplest solution is what
@dmccabe
suggested:Globaly overwrite the
security.authentication.success_handler
which is fine as long as you don't need to have multiple handlers for multiple firewalls.If you do (as of this writing-) you have to write your own Authentication Provider.