I don't feel the need to have an admin notification every time a user mistypes a password. Is there some way I can avoid having a number on the admin tab for trivial issues like this? I think if there is always a number there, it will inure me to actually look at the real errors. And I don't particularly want to purge the logs at all times. It may be useful to go back and review if specific users have password issues or hacking attempts against their logins.
IOW: I just want to NOT have this come up in the admin tab.
(https://i.imgur.com/MpPGNBP.png)
While I agree that it is indeed excessive, and largely an unnecessary distraction because of just that, there are no related options to configure at this moment. What you could probably do is edit it out of the template, but I haven't bothered looking in to this, I've just learned to ignore it most of the time.
I'm more and more regretting the upgrade. :(
This was something that was discussed a few years back, eliminating trivial errors from logging, or putting them somewhere else. It tends to bloat the error log, and often causes admins to ignore the log. It ended up nothing was done about it. It's more annoying in 2.1 because it shows up on the Admin button.
I think there should be a differentiation on what show up in the admin alert and what doesn't show up.
Things that need action should be there (Eg. Approving users, moderating reports, etc.). Events that I have essentially no power to do anything about, but that may be needed in an investigation, should not show up there,
Users typing in a wrong password is an excellent example of the latter.
I agree, this is something that could be improved.
(https://thekrashsite.com/pics/deadhorse.gif)
Not to beat a dead horse, but there were a number of things discussed over ten years of development that could/should have been done to make 2.1 a better product, but weren't. I suppose the devs had their hands full just trying to get it to final, but surely some of these issues could have been addressed early on. A lot of missed opportunities.
Then again, many of the "opportunities" that YOU think needed to to be changed are not what WE thought.
This is a case of a rare concordance. :P 😜
in Sources/LogInOut.php you have this
else
{
// They've messed up again - keep a count to see if they need a hand.
$_SESSION['failed_login'] = isset($_SESSION['failed_login']) ? ($_SESSION['failed_login'] + 1) : 1;
// Hmm... don't remember it, do you? Here, try the password reminder ;).
if ($_SESSION['failed_login'] >= $modSettings['failed_login_threshold'])
redirectexit('action=reminder');
// We'll give you another chance...
else
{
// Log an error so we know that it didn't go well in the error log.
log_error($txt['incorrect_password'] . ' - <span class="remove">' . $user_settings['member_name'] . '</span>', 'user');
$context['login_errors'] = array($txt['incorrect_password']);
return;
}
i would think you could edit out the log_error or remove the else completely... i have not tested either option.
Quote from: Illori on September 18, 2022, 04:25:32 PMin Sources/LogInOut.php you have this
,,,
i would think you could edit out the log_error or remove the else completely... i have not tested either option.
Now see, I'm not against writing these errors to the log file. it is useful from time to time, if we're looking into attempted security breaches or account hacking. What I'm against is to inflate the *visible* count of errors that may indicate actionable items.
Thing is, the admin count is calculated by just counting the number of issues in the admin error log. In order to filter out some of the items which are in the log but you don't want an account would add add an unnecessary and potentially complicated series of code...
Not disagreeing, but the current implementation is ... shall we say "less than ideal"?
Marking solved as the original question has been answered and because of the fact that the team is aware of this.
Quote from: Steve on September 19, 2022, 09:17:13 AMMarking solved as the original question has been answered and because of the fact that the team is aware of this.
Uncommon semantic, but yea, time to move on, solved or nowt.
lol, well, realistically, this is not a bug - so the issue is "solved" :)
it's also unlikely to be changed much (unless that change is to completely remove the logging on bad passwords.)
I understand your frustration, however. ;)
Marking solved doesn't necessarily mean the problem was fixed. It can mean the solution was identified and the appropriate people made aware and there's nothing more to do in the topic. :)
Edit: or it can mean what Kindred said. :P
There is/was a mod available to help with this: https://www.simplemachines.org/community/index.php?topic=535900.0
Unfortunately, it hasn't been updated recently.
Quote from: sah62 on September 19, 2022, 02:51:34 PMThere is/was a mod available to help with this: https://www.simplemachines.org/community/index.php?topic=535900.0
Unfortunately, it hasn't been updated recently.
That mod doesn't work properly with SMF 2.1.2 (plus it breaks ./Sources/LogInOut.php when it is installed).
However, I am a co-author on some of
@dougiefresh's other mods so I'll look at updating that mod when I can but it won't be for a couple of months as I'm about to head away on holidays.
Quote from: GL700Wing on September 19, 2022, 06:06:04 PMHowever, I am a co-author on some of @dougiefresh's other mods so I'll look at updating that mod when I can but it won't be for a couple of months as I'm about to head away on holidays.
I'm pretty much sure this has been hashed to death during 2.1.2 design and planning, and probably a few times after that. I also suspect it's non-trivial, but IMHO the ideal solution would be if error messages had severity levels and admin alerts could be set to a specific severity level.
But yea, my days of designing complex software suites are long in the past, so perhaps if you ever come up with something, post back here or PM me so that I can give it a test run?
In the mean time, enjoy your holiday.