Support

User login is a special case. It is not handled the same way as the other security exceptions. In fact, the user login event which Admin Tools is using runs in a different context. Therefore, WAF exceptions do not apply.

If you want to stop your users from being blocked, you should disable the "Treat failed logins as security exceptions" option in WAF config. This will prevent failed user logins from being treated a security exceptions. In its turn, this will prevent users from being blocked. Users, actually their IP addresses, are being blocked by Admin Tools when the "Auto-ban Repeat Offenders" feature is being used. Since failed logins are treated as security exceptions, multiple failed logins will cause the automatic bak to kick in.

OK, this is confusing if you don't know how Joomla! works. I will try to explain it more in-depth. Bear with me.

Joomla! builds and run the application in several phases whenever you load a page or submit a form. The first phase is initialisation. WAF executes in the onAfterInitialize event which occurs right after that first phase (initialisation) has occurred.

A few phases down the road we have the Dispatch phase. At this point Joomla! hands over execution to the component. When logging in to the site (submit the login form) you are calling the com_users component, namely its user.login task. This component then calls back a method in the main Joomla! application, asking for a user login. Joomla! will then load the user and authentication plugin, check if the user should log in and return this information back to com_users. com_users will now fire a new event, onUserLoginFailure, when a login fails before telling the Joomla! application to redirect back to the previous page with an error message. In order to track failed logins we have to hook on the onUserLoginFailure event.

Why do we have to do that? When the rest of WAF runs (in the onAfterInitialise event) Joomla! has not yet called com_users and it has not asked Joomla! to log in the user. Therefore at the time we are parsing WAF exceptions we DO NOT know if the user credentials are correct. We can only see a username and a password. WAF will process it through its filters. It is possible that a complex password triggers the XSSShield or the SQLiShield filter. This is why I am talking about WAF exception with regards to com_users.

However, your request IS NOT blocked at this stage. It goes through and Joomla! processes the login information. When it sees that the user should not be allowed to log in, com_users raises the onUserLoginFailure event and the Admin Tools plugin hooks on it and runs. At this point we do not take WAF Exceptions into account.

Moreover, it would be absurd to take WAF Exceptions into account in the onUserLoginFailure handler. It performs only one thing: treat a failed login as a security exception if you have configured it so. If we processed a WAF exception for com_users it would be equal to turning off the "Treat failed logins as security exceptions" option, because user login attempts from all components and all modules are always handled by com_users. There is no point going through the computationally very expensive business of parsing WAF exceptions when turning off "Treat failed logins as security exceptions" does exactly that. There should never be two ways to globally disable the same setting in an application. Doing so is asking for trouble. If someone has a problem with failed logins not being treated as security exceptions where do you look? We already have to look for four things:
- PHP version
- Is the Admin Tools plugin published
- Is the Admin Tools plugin published as the first plugin (lowest ordering)
- Is the "Treat failed logins as security exceptions" checked
The first three are common across all WAF options and are easy to eliminate. The latter is a single option which is also easy to eliminate. Adding yet another check about a fuzzy thing like WAF Exceptions would make it virtually impossible for end-users to troubleshoot and add take its toll for us doing support.

And now let's go back to my carefully phrased documentation line: "Let's say we want to disable WAF for all front-end logins to avoid a complex password throwing a 403 error to our users." See? I am only talking about a complex password causing a 403, implying that a valid (but complex) password may be tripping WAF. I am not talking about multiple failed logins (where an invalid username and/or password causes Joomla! to deny login to the user) causing the user's IP address to be banned. It's very carefully phrased :)

Hm, that last question is a good one. No, it wouldn't happen. Joomla! does log the user in. It updates the session data and sends a cookie to the browser. Since the browser doesn't accept the cookie, during the next page load a new session is created by Joomla! and the user experiences not being logged in (different session means Joomla! doesn't know it's the same browser instance which tried logging in just a moment ago). Since no failed login even is fired there is no way for Admin Tools to block the user due to a failed login. The major problem with those users is that they end up creating massive amounts of session table rows, with all the problems this brings along (waste or resources, sluggish performance, the session table may crash and bring your site down, the database may fill up on hosts with very limited database space, that kind of stuff).

I already explained you how Joomla!'s login and how Admin Tools' plugin works. As you understand, the log data you describe are inconclusive. They only tell us that a user was bouncing between two pages. Also, the explanation that the user logged in is an arbitrary one. You CAN'T possibly see that in the log file. At best you can see a POST request. You can't see the outcome (in Joomla! 1.5, at least). What you did is to fill in the missing information with arbitrary data. This arbitrary data you used sounds intuitive, but in fact would only work in the event Joomla! and Admin Tools were animate objects, developing free will and working in a completely different way than they are programmed to. Since they are not, your explanation is obviously false. So, what's going on? We'll have to take an educated guess.

Unfortunately Joomla! 1.5 does not allow us to see from the log file if the user is logged in or not. Even in the case of an error page it return a 200 OK status. It is very likely that what you see is this: User goes to the page, enters his login data. User is denied login which means that Joomla! returns him to the previous page. User insists. User is denied login again and returned to the previous page. User is stubborn and tries again. At this point he triggers his third failed login within a few minutes. And now my turn to fill in the picture with arbitrary data: I suppose that you are using the default values in WAF Configuration which would allow a maximum of 3 security exceptions per a small amount of time. I suppose these login failures happened during this time frame. I suppose you are using the "Treat failed logins as security exceptions" option. Based on these assumptions it is perfectly clear why the user's IP address (and not the user, as you claim – these are two very different things, mind you!) was blocked. You can take a look at the Security Exceptions Log to verify this.

Now, if you do not see the IP address of the user being blocked but the user account itself (the Blocked setting is set to Yes in the User Manager) you can rest assured that Admin Tools did not do that. Admin Tools does not disable user accounts. It would be moronic to do so and I can prove it. If Admin Tools would do that and I were a malicious hacker, I'd first take a look at your site. Chances are I'd be able to figure out your username. I'd then write a script to rapidly try to login with your username and false passwords. Thus, I'd get you blocked from your own site. That's why such a feature would be moronic, therefore it is not implemented in Admin Tools.

Which means that my guess is correct. The only way this can happen is if she was using the wrong username and/or password to begin with. You can see that in Admin Tools' Security Exceptions Log.

Not necessarily so. Try logging out and visit that page.

You should see the same thing for your client, too. This is the only way Joomla! 1.5 can work.