I would maybe change the limit to 2 per hour? There are valid reasons to try it a second time.

Are there? If sending the email fails on Matomo side the request get's removed again. So a new request can be done until the email was sent.

Mail might get not deliviered on recieving end for some spam or missconfiguring reasons (e.g. greylisting, missing forwarding, wrong trusted networks, etc).

Then it would make sense to allow resending the last request once instead of allowing a complete new one...

I currently don't see a difference, but that seems fine for me.

Requesting a new reset means filling out the form again and generating a new token for the reset. That means the email content is slightly another as the link differs

Ok, it's fine for me to send the exact same mail again.

I would have also allowed 2 or 3 per hour as it can be useful eg if mailbox is full etc but if it otherwise works within an hour again should be fine. Could have been also useful to block per IP but not needed (to avoid someone requesting forget password feature every hour for all users and basically blocking the feature, not really an issue though)

@tsteur Wondering what would be the userfriendliest and securest implementation.

• Allowing to request a password reset only once an hour (e.g. an error will be shown when the last request was within the last 60 mins)
• Limit the number of requests possible per day (or maybe month), without any "wait time" between the requests
• Allowing to request a password reset only every 3-x hours, but show a message when another request is made within that time, that allows to trigger a resend of the last request (new token, but still the same password from the original request). Resending the request would also be limited to 2 or 3 times and afterwards an error would be shown to contact the admin

Ideally it would use the new brute force feature added in 3.8.0. We would add a new type column to the DB and methods to be able to take advantage of all the methods etc.

But it's a bit more work and #13813 is not even scheduled yet and not really important so would be too much work for now. I would probably simply allow 3 calls per hour for now or whatever is easiest.

@tsteur guess make sense to reuse that. This was just a quick approach to implement a simple rate limit. Maybe we should simply close this and implement it properly later?

No preference. Could also merge and just leave it like that. up to @Findus23 and @mattab

This PR fixes the most important issue (you can endlessly spam users), so I would say this is good for now. And I wouldn't create a too complex logic as I still think that one day the password reset should be replaced with the "normal" way (#11071) and then there wouldn't be a difference between resending a reset and sending a new reset.

just a quick feedback: reckon it should be possible to request again the password reset in the hour. For example if the mailserver was buggy and email didn't get sent, or any other problem. 3 times per hour sounds good and would not be considered spammy?

@sgiehl I set it back to WIP. Lets allow 3 times per hour.

Changed it so only 3 requests are allowed per hour.

Any chance to create an integration test for this @sgiehl ?

I've added some tests