It doesn't send anything out straight away, it just sets the flag in the database the same as if you set these values in the ACP when editing a user. If it's set to require email confirmation the user would need to click a link to send the email when they log in next, and if it's set to reset password it only sends the email when the user logs in.Hhow does this work exactly?
If I enable this, and have 10.000 users that are inactive for the last 180 days, will it send a password reset email to all of them at once?
I ask this because my mail provider probably won't like that. So I'll have to do it in smaller batches.
No real reason it should be doing that, it only runs a basic select query in a cron, doesn't do anything intensive. Will loop round a lot of users on first run but shouldn't be that bad.If I set is to 180 days, I get a server 500 error. If I use a bigger time frame, like 5000 days, then it works.
we had the same issue with 40k old users selected from 120k. It was necessary to run it 4 or 5 times due to nginx-timeouts. No significant load was created, took maybe ~2min in total.No real reason it should be doing that, it only runs a basic select query in a cron, doesn't do anything intensive. Will loop round a lot of users on first run but shouldn't be that bad.
Quite a few of the ones I checked were not listed.We have also confirmed that at least two accounts are not listed on HaveIBeenPwned.
One way to help pinpoint where this is coming from would be to find an active user who has had their account taken over and ask them if they use a third party service to store their passwords. Most of the accounts appear to be abandoned, but there have been a few mentions of active accounts being taken over.Quite a few of the ones I checked were not listed.
I think the reason it's primarily dormant accounts that are being hit, is at least in my case on my older sites, I have many times more dormant accounts than active ones.One way to help pinpoint where this is coming from would be to find an active user who has had their account taken over and ask them if they use a third party service to store their passwords. Most of the accounts appear to be abandoned, but there have been a few mentions of active accounts being taken over.
The most recent accounts we can see that are impacted were registered in late 2021. The oldest accounts are many years old. That data must be from late 2021, 2022 or 2023, which could line up with a LastPass leak in 2022.I think the reason it's primarily dormant accounts that are being hit, is at least in my case on my older sites, I have many times more dormant accounts than active ones.
I don't know what went wrong, but after running this add-on and then the 'rebuild user cache', I only have 600 users left instead of 60.000It doesn't send anything out straight away, it just sets the flag in the database the same as if you set these values in the ACP when editing a user. If it's set to require email confirmation the user would need to click a link to send the email when they log in next, and if it's set to reset password it only sends the email when the user logs in.
No real reason it should be doing that, it only runs a basic select query in a cron, doesn't do anything intensive. Will loop round a lot of users on first run but shouldn't be that bad.
We don't need to be introduced to it.Let me introduce you to RIPE.net / ARIN.net / APNIC.net that govern the IPv4 space and allocate subnets to different organizations in non-contiguous blocks.
Regardless of Nationality, people do things that are best for their server or situation, we have ZERO use for people hitting our server from the Ukraine, so we blocked the entire block too because I can! 109.107.166.0/24I mean, I know you guys down there do things slightly differently but this time it's just a mosquito and you want to nuke it from orbit...
I believe another reason is due to the lifespan of the compromised data. If the spammers are purchasing lists from a hack that was several years ago, for example, chances are greater for older accounts to be compromised. In our case, on two different forums, the accounts were dormant, but I also don't necessarily think that means active accounts were spared. It's just that forums in general tend to have a large membership base with only a small percentage of the members participating.I think the reason it's primarily dormant accounts that are being hit, is at least in my case on my older sites, I have many times more dormant accounts than active ones.
The users are still there, it's just the count that's wrong, it doesn't count users that are set to re-confirm their email address, but there's already code that should be recalculating that.I don't know what went wrong, but after running this add-on and then the 'rebuild user cache', I only have 600 users left instead of 60.000
No clue what happened here, but I'm afraid I'll have to do a rollback.
I agree--there are times when a forum has an audience only in certain parts of the world, and there's no sense in allowing access to those countries or regions with no legitimate interest. I have hundreds of entries in a blocklist that I use in my server firewalls to keep many of those countries out. I guess I missed Moldova.People do things that are best for their server or situation, we have ZERO use for people hitting our server from the Ukraine, so we blocked the entire block too because I can! 109.107.166.0/24
Thanks... Needless to say, our chests are puft out this morning an inch or two more than usual.To add, on a forum with Spaminator from @Ozzy47 no one got through. I can see Korean IP's are blocked, several per hour.
Do you have something else to prune inactive users or anything? You must have something else set up to delete users that haven't activated their accounts or something, in which case you wouldn't want to be setting lots of users to that state.Thanks! But I also don't see them in ACP -> Users -> List all users!
Well deserved, I might say. It's a unique approach to catching spam activity, and it actually works. If it takes a load off of our volunteer staff, that alone makes it worth the cost. I never thought I'd see a use for the Login Spaminator until this all started happening.Thanks... Needless to say, our chests are puft out this morning an inch or two more than usual.
We have one customer who a couple years ago reported a overnight addition of more than 5000 entries in his log - it was a brute force login attack. The timestamps proved the attack actually happened over a four minute period. This incident though, tops that just due to lots more people helped - we know none of our customers are having to deal with this silliness. It's a proud day.Well deserved, I might say. It's a unique approach to catching spam activity, and it actually works. If it takes a load off of our volunteer staff, that alone makes it worth the cost. I never thought I'd see a use for the Login Spaminator until this all started happening.
We use essential cookies to make this site work, and optional cookies to enhance your experience.