The parameter resetting.token_ttl is used for two different things. It is used to determine the time to live for the token and the time the user must wait before retrying the request.
These two times are inherently different, the token life should be relatively long, about the day that is the default, the time the user has to wait should be relatively short, a minute or two at the most. A user who is trying to retry their password reset is often retrying because they somehow messed up the previous reset: eg. lost the email.
Also the message about the wait has the 24 hours wired into the i18n, so it's hard to change.
I've added the second parameter to my bundle and feel it should be added to the FOS User Bundle. Adding to my bundle required: override the controller, add the config for the new parameter to the DIC, override the translations. A lot of work for an additional parameter.
:+1:
:+1:
I would love to see that in the bundle.
The same story. It would be grate to have such option in fos.
My workaround is the next. I create compiler class for my user bundle (read about it here http://symfony.com/doc/current/cookbook/service_container/compiler_passes.html), create my own param acme_user.reset_token_lifetime: 86400 and then just replace fos param with my:
public function process(ContainerBuilder $container)
{
if ($container->hasDefinition('fos_user.listener.resetting')) {
$definition = $container->getDefinition('fos_user.listener.resetting');
$args = $definition->getArguments();
if (in_array('%fos_user.resetting.token_ttl%', $args)) {
$args[array_search('%fos_user.resetting.token_ttl%', $args)] = '%acme_user.reset_token_lifetime%';
}
$definition->setArguments($args);
}
}
Not so much code and works greate.
Could anyone please explain me what is the reasoning behind entire "wait before retry" feature? Why make user wait before retry?
Maybe he deleted his original message accidentally or overlooked it, so now he has to wait for 24 hours?
I can't tell you how much trouble this reset lockout has caused me. I understand not wanting to SPAM a user, but there is a point of sanity as well.
I agree. I would be great to have a separate parameter for setting the lockout timeout and attempts. For example, I would like to allow 2 resets per day.
:+1:
:+1:
:+1: I tried to set it to 0 so it wouldn't have to wait for reset and now they immediately expire
:+1:
馃憤
Also would love to see a fix for token_ttl to separate its functionality
Indeed the current behaviour does not pass the real-life test.
馃憤
Maybe someone could provide a PR with this feature instead of posting stupid 馃憤 comments. This feature wouldn't come automatically when there are 1452 馃憤 s
3.5 years and still was not fixed?
Does everyone these days have their own user management bundle or something? )
Can you guys have a look at https://github.com/FriendsOfSymfony/FOSUserBundle/pull/2418 ?
Most helpful comment
Maybe someone could provide a PR with this feature instead of posting stupid 馃憤 comments. This feature wouldn't come automatically when there are 1452 馃憤 s