It’s great that this has been added to the core, only six years after it was originally in the issue tracker - that puts Matomo way ahead of WordPress, which has been waiting for it for well over a decade!
I haven’t attempted to look at the source code to see if I can work it out, but does it work with IPv6 as well as IPv4?
Lukas
(Lukas Winkler)
January 24, 2019, 12:22pm
2
Hi,
I’m pretty sure it supports IPv6, but I am not sure if it just considers completly identical IP-adresses and not ranges.
matomo-org:3.x-dev
← matomo-org:2888
opened 02:12AM - 24 Sep 18 UTC
As discussed in #2888 a quite simple implementation that should do the job. Heap… s more could be done as mentioned in the comments but might not be needed.
It took me couple hours to understand all the authentication/login flows as there are lots of different components now such as Auth, SessionAuth, SessionInitializer, Access, etc. and it wasn't clear where to put things to make it work universally while still being clear about when it happens etc.
Also had to add couple of events eg for failed logins. The most important part is really to register a failed login attempt when there is one (we often authenticate eg API requests etc even though the user didn't, or we always authenticate first against session then regular auth adapter etc which makes things complicated). And it is important to check whether IP is blocked when trying to attempt to log in. All those parts should be covered.
When an IP is blocked, I did not want to block any already logged in users in the UI. This could be annoying when a company shares the same IP and it would otherwise even block the super user.
The superuser has a diagnostic page to unblock all users and a console command. Can also document in a FAQ how to do it through the SQL database directly.
For system settings and diagnostics page screens see screenshot tests.
Functionality wise you specify two values: X amount of login retries allowed in Y amount of minutes. If you have more than X amount of logins within Y amount of minutes, you are blocked and cannot log in. Even when successful token provided for example. You can only log in again, when some time has passed and you had less than X amount of login retries within the last Y amount of minutes. There is no specific lock out time that you can configure so if people lock themselves out they can use UI again after eg 30 min or 60min. By default we allow 20 logins within 60 minutes. When sharing an IP within an office those 20 logins could be reached within an hour but should be maybe fine. Hard to find the right balance here.
You can also whitelist and blacklist specific IPs.
fixes #2888
I'll try to write some more tests for the different login failures once the PR is reviewed.
Check here for the coresponding unit tests.
matthieu
(Matthieu Aubry)
February 14, 2019, 3:45am
3