The composer.json imposes a limit of "doctrine/orm": "~2.2,>=2.2.3" - is the upper bound strictly necessary?

Doctrine 2.5 offers a lot of improvements, and whilst it's not going to be the default in Symfony for ages (even 3.0), upgrading to it was painless with zero BC breaks in my relatively large Symfony project.

Any thoughts?

There is a way to check if the login redirect is active... ? So after we have reached the number of failed logins to be able to redirect the user to a "too many login attempts" route / page where I would like to be able to output some message to make visitor aware why is it not able to see the login page again:

{% if ( 'admin/login' in app.request.headers.get('referer') ) or
( 'admin/dashboard' in app.request.headers.get('referer') ) %}

Too many login attempts

However first time the twig is displaying my message as the referer is the admin/login route ... in my case, but if I will refresh that landing page the message is no longer displayed... so can I check a session var or something to be able to accomplish this ?

Thank you for sharing your code

According to the documentation, after the before_return_http_500 limit is reached an login attempt should raise error 500. This however doesn't happen.

The voter will simply vote for access denied in this occasion (shouldn't it be something like throw \Exception() here?)
https://github.com/codeconsortium/CCDNUserSecurityBundle/blob/master/Component/Authorisation/Voter/ClientLoginVoter.php#L148

It seems to create a redirect loop, at least in my experience.

This bundle doesn't take into consideration that different IP addresses might be used to brute force a specific username. However, blocking the account based on multiple attempts for a specific username, irrespective of the IP address, creates another problem i.e. user A can attempt to log in as user B, hence blocking access for user B. To overcome this, we need to make sure that access for user B is allowed from a pre-saved/whitelisted IP address.

Do you have any opinion/thoughts on the matter?

Would a PR be welcome to log successful attempts to login?

Update your bundle to symfony 2.6, please.

The scenario:

1. "duration_in_minutes" was set to "15 minutes"
2. The lockout was triggered and the user was redirected to the password recovery.
3. User requested a new password and successfully logged in to the site.
4. User logged out.
5. User will not be able to login again since the previous session is still active.

Is this normal? I'm thinking of once the user successfully logged in to the site, the previous session should be cleared already.

I could need a way to disable this feature altogether. Maybe with

ccdn_user_security:
  route_referer: false

or

ccdn_user_security:
  route_referer:
    enabled: false

Hi,

we just integrated CCDNUserSecurityBundle into a legacy application where we do not yet use the FOSUserBundle, nor do we have a (doctrine) entity for our user class.

So we where stuck a bit, because we did not now, what value we could provide for this configuration key:

ccdn_user_security:
    entity:
        user:
            class: Acme\YourUserBundle\Entity\User # Required

After greping through the code we came to the conclusion that this configuration value is never used. So we left the example value in there and everything worked fine.

Is it right, that this configuration key should be removed from CCDNUserSecurityBundle

The dependencies defined for this bundle have an upper bound on the supported Symfony version. It should however work without changes with symfony 2.5 too. I've seen no backwards incompatible chanes from 2.4 to 2.5 that should affect this bundle.

Given this config:

ccdn_user_security:
    entity:
        user:
            class: Netvlies\WbBundle\Entity\User
    route_referer:
        enabled: false
    login_shield:
        route_login:
            name:                  netvlies_wb_security_login
            params:                []
        force_account_recovery:    # Specify all routes to block after attempt limit is reached, and account recovery route to force browser redirect.
            enabled:               false
        block_pages:               # Specify all routes to block after attempt limit is reached.
            enabled:               true
            after_attempts:        5
            duration_in_minutes:   30
            routes:
                - netvlies_wb_security_login
                - login
                - login_check
                - logout

Also on our homepage (/ route) there is a small login form on top of the page. We don't want to add the homepage to the blocked routes list.

Now lets imagine a user tries 5 times to login with the wrong credentials. What we expect to happen:

• user cannot visit /login route
• user cannot trigger a login attempt any more

But what actually happens is that the of course can't open the /login route anymore but is still able to post to /login_check. When the credentials are false a 403 blocked page is shown, but when the credentials are correct the user is successfully logged in. In other words: its still possible to brute force accounts. When showing a small login form on your homepage, this actually is very easy for anyone.

I've been digging in the code and have found what causes this: the BlockingLoginListener has a lower priority then Symfony's Symfony\Component\Security\Http\Firewall listener. The Firewall is registered with a priority of 8 on the kernel.request.

To fix the brute force problem I've changed the priority of the BlockingLoginListener to 9. With force_account_recovery set to false everything works as expected. Unfortunately with force_account_recovery set to true (as in the Behat suite) this breaks things.

If we increase the priority of the BlockingLoginListener before the Firewall and we enable force_account_recovery then as soon as after_attempts is reached, the $event->stopPropagation() prevents the Firewall listener to actually trigger a (failure) login. This makes it impossible to reach the blocking level:

        if ($result == $securityManager::ACCESS_DENIED_DEFER) {
            $event->stopPropagation();

            $redirectUrl = $this->router->generate(
                $this->forceAccountRecovery['route_recover_account']['name'],
                $this->forceAccountRecovery['route_recover_account']['params']
            );

            $event->setResponse(new RedirectResponse($redirectUrl));
        }

I think in order to solve this problem we need to refactor BlockingLoginListener into two listeners: BlockingLoginListener with priority 9 on kernel.request and ForceAccountRecoveryListener with a lower priority then 8.
And perhaps split up the ClientLoginVoter into separate voters too.

Any thoughts on this @reecefowell ?

If I've some spare time I'm willing to do the refactoring. But not before we agree on the solution 😄 .

When a user got locked out due to exceeding number of failed attempts and proceed to reset their account and click the link, change password and so on, user still unable to get to the login page immediately and have to wait until the configured force_account_recovery duration. Is there not a way to reset the previous failed attempts once the customer successfully reset their password?

$request = $this->requestStack->getMasterRequest();
var_export($request->request->all());

returning empty array, even if we have posted a form with username and password.

Any thoughts?

FILE:
D:\xampp\htdocs\staging\vendor\codeconsortium\ccdn-user-security-bundle\CCDNUser\SecurityBundle\Component\Authorisation\SecurityManager.php

the composer.json says >= 5.3.2, but the readme says 5.4. If it really is 5.4, is there any way it could be adjusted for >=5.3.2 ?

I use isGranted method inside a Symfony command:

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        ...
        $this->getContainer()->get('security.context')->isGranted(...)
        ...
    }

and I get this error:

PHP Fatal error: Call to a member function get() on a non-object in ...\vendor\codeconsortium\ccdn-user-security-bundle\CCDNUser\SecurityBundle\Component\Authorisation\SecurityManager.php on line 101

It seems Synfony call your CCDNUser\SecurityBundle\Component\Authorisation\SecurityManager voter and there is no request as no HTTP request is being done.

How can I disable CCDNUserSecurityBundle with commands? if it´s not possible, is there a way to avoid this problem?

We introduced CCDNUserSecurityBundle in our project without using FOSUserBundle and it works. I think it would be helpful also for others to provide a documentation section that starts from a minimal introduction of CCDNUserSecurityBundle and adds features (and configuration) step by step.
(Pull Requests welcome, I assume...)

I do have
ccdn_user_security:
entity:
user:
class: Application\SonataUserBundle\Entity\User # Required
login_shield:
route_login:
name: sonata_user_admin_security_login
params: []
force_account_recovery: # Specify all routes to block after attempt limit is reached, and account recovery route to force browser redirect.
enabled: true
after_attempts: 2
# !!! check also the Default controller for timing the cookie also
duration_in_minutes: 2
route_recover_account:
name: help
params: []
routes:
- fos_user_security_login
- fos_user_security_check
- fos_user_security_logout
block_pages: # Specify all routes to block after attempt limit is reached.
enabled: true
after_attempts: 3
duration_in_minutes: 3
...
and also

• sonata_user_admin_security_login

under block pages...

It seems to work correctly under chrome browser on laptops but on Android device Chrome does not block the page after 3-10 wrong logins...

Any ideea how to fix it ?

The cc_security_session table accumulates all failed login attempts but is never cleaned so it grows without bounds. This might also be a privacy issue because this table can contain IP adresses from legitimate users too, who just forgot their password.

Is there a standard method in Symfony to distribute cronjobs in a Symfony bundle? Maybe one could provide some command that can be executed once an hour or day to delete old entries from the cc_security_session table.

The composer.json imposes a limit of "symfony/symfony": "~2.5" - is the upper bound strictly necessary?

Symfony 2.7 is the current LTS.

Hi,

Symfony 2.7 was just released and bundle have <2.7 constraint.

Regards.

Before we used CCDNUserSecurityBundle, we had a list of the individual Symfony components that we depend on. Since CCDNUserSecurityBundle has a dependency on Symfony/Symfony we had to finally make the step to depend on the full Symfony distribution.
It was not such a problem in our case, but it might be for others. So maybe it would be better if CCDNUserSecurityBundle would depend just on the Symfony components that are real dependencies.

The LoginFailureHandler adds the failed login attempts to the cc_security_session table. But couldn't that be done in a listener?

And the redirection logic in all the handlers, isn't this a code duplication with what is already provided by Symfony? Plain Symfony already provides means to redirect the user to the last seen page before the login attempt.

Hi,

I face a problem when running PHPUnit tests with PHP5.6 under Jenkins, it returns me this error :
Doctrine\Common\Persistence\Mapping\MappingException: Invalid mapping file "CCDNUser.SecurityBundle.Entity.Session.orm.yml" for class "CCDNUser\SecurityBundle\Entity\Session" at n/a in /var/lib/jenkins/jobs/MyProject/workspace/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/MappingException.php line 86

Do you have any idea of why this happens?
The schema seems to be valid, in sync with the entity.

Thanks,
Nicolas

Currently error messages of login form from FOSUserBundle are missing when using this bundle, because the logic of handling error message shall be handled from handler implementing AuthenticationFailureHandlerInterface. Error messages shall be set to session appropriately in the failure handler.

Hi, is it possible to define a new stable version for Symfony ~2.5 ?
Because I must use "dev-master" (for my Symfony 2.7 project) wich SensioLabs Insight and me doesn't like very much 😢