Arthmoor

So here's an example of one of the spam posts. They've been identical up to this point. Word filtering isn't stopping them at all.

So in recent weeks my forum has had a wave of spammers who have been able to freely post blatantly obvious spam on the site. Word filtering is absolutely ineffective to preempt them, and in the most recent case, isn't stopping them at all despite the terms being added to the post filter. In the support thread I filed, it was made clear your current anti-spam system only deals with user accounts, NOT with the content of the things they're posting. I'd say that's proven to be more or less useless. What IPS needs is preemptive/proactive spam defense, not reactive flagging and content deletion. To that end, I'd like to very strongly suggest that IPB set up a partnership with the Akismet anti-spam service that's widely used by Wordpress blogs and a number of other sites and applications. Their system works by analyzing the actual content being posted and will return a yes/no type of response as to whether they think it's spam or not. From my own experience, they're rarely wrong about that. I'm using it on a bug tracking site I wrote myself, along with an obsolete forum package I still keep online for an old MUD. A properly implemented Akismet setup will flag spam and store it in a temporary place for moderator review. From there, the content can be checked. If it's not spam, the moderators can click a button to indicate this, and a false positive is sent to Akismet for the system to learn from it. If it is spam, you can either delete it on the spot or let it sit in the pool until a specified expiry time (on my other 2 sites, I use the suggested 30 days). If a post actually does manage to hit the forum, the moderators can click a button there to have it reported as spam and their system learns from that as well. So it's very adaptable. What's even cooler, is the content scanning is done in real time so there's no having things sitting in some queue for days before it's evaluated by their servers. There's a great deal more useful information to be found at https://akismet.com/ such as developer support and API documentation etc. I'm sure they could explain the gory details a lot better than I can. In the end though, this would be a wildly more effective way of dealing with spam than what we currently have.

There shouldn't be. I haven't enabled anything like that via any options in the ACP. That seems very much less than effective then because bot farms don't keep using the same accounts. With the previous batch of airline ticket scammers, it was fresh new accounts every day. With these crypto bots, it's sleeper accounts they embeded on site months ago. Filtering solely based on the registration is completely ineffective. So I'll take your other advice and post on the other forum and recommend you guys partner up with Akismet - their service acts on the content and is ludicrously effective. Wordpress ships with that as a default plugin and everything.

Yes, the word filters have been in place for several days now with no result. They're still able to post. When I tried it myself, the filter blocked me from doing so. Which is why I don't get it. This shouldn't be getting through at all. Yes, I'm referring to the "Flag as Spammer" function. If that doesn't do anything with the post comment, then I have to wonder, what's the point? You can't defend against spam properly if the system you're using doesn't do anything to analyze the content of the posts. Merely flagging a user as a spammer is pointless in this case and just clogs up the database with banned accounts.

Hi, me again. Your resident pest about anti-spam measures 😛 Different problem this time though. I've got a message (actually a regularly repeating set) that has two terms which we have set to explicitly block submission in the word filtering for posts. The accounts doing the posting are still able to submit though, which shouldn't be the case. I've tried a test post using my own admin account and it won't let them through, as expected. I can't see anything out of the ordinary about this latest batch, but I've preserved one of the messages - hidden from public view of course. It should be at the bottom of this thread: https://www.afkmods.com/index.php?/topic/8841-tel-nalta-ii-patch-collection/ The blocked terms are "crypto pump", "crypto pumps", and "pump_upp". The first two being set to exact match, the third set to loose because they've been varying stuff before and after it. And before someone suggests it, yes, the posts have been reported as spam with no favorable outcome for doing so.

The theme errors were resolved once the upgrade process to 4.7.6 was done. The RFC 3339 errors have not been, and are still flagging in the ACP as being frequent. They also don't appear to be theme related in any way. All I can gather is that those have something to do with DateTime issues and that they only seem to happen on the login page.

Is that what the error I posted is about? Cause if you're referring to the ones that were thrown on the 12th, that was when I updated the site to 4.7.6.

I was checking the ACP this morning and notice it's warning about repeating log entries. They all appear to be exceptions thrown at the login page but I have no idea what they're referring to or what this is trying to tell me. Error: Call to a member function rfc3339() on null (0) #0 /home/**********/public_html/applications/core/extensions/core/MemberSync/System.php(426): IPS\_Member->apiOutput() #1 /home/**********/public_html/system/Member/Member.php(4030): IPS\core\extensions\core\MemberSync\_System->onProfileUpdate() #2 /home/**********/public_html/system/Member/Member.php(442): IPS\_Member->memberSync() #3 /home/**********/public_html/system/DateTime/DateTime.php(61): IPS\_Member->save() #4 /home/**********/public_html/system/Member/Member.php(1165): IPS\_DateTime::ts() #5 /home/**********/public_html/system/Patterns/ActiveRecord.php(335): IPS\_Member->get_joined() #6 /home/**********/public_html/system/Session/Session.php(294): IPS\Patterns\_ActiveRecord->__get() #7 /home/**********/public_html/system/Session/Session.php(175): IPS\_Session->regenerateCsrfKey() #8 /home/**********/public_html/system/Session/Session.php(97): IPS\_Session->init() #9 /home/**********/public_html/system/Theme/Theme.php(417): IPS\_Session::i() #10 /home/**********/public_html/system/Theme/Theme.php(312): IPS\_Theme::currentThemeId() #11 /home/**********/public_html/system/Dispatcher/Standard.php(54): IPS\_Theme::i() #12 /home/**********/public_html/system/Dispatcher/Front.php(759): IPS\Dispatcher\_Standard::baseCss() #13 /home/**********/public_html/system/Dispatcher/Front.php(76): IPS\Dispatcher\_Front::baseCss() #14 /home/**********/public_html/system/Dispatcher/Dispatcher.php(110): IPS\Dispatcher\_Front->init() #15 /home/**********/public_html/index.php(13): IPS\_Dispatcher::i() #16 {main}

One of my moderators captured this as an example. In this pic, both "Airlines" and "Reservation Number" are listed as blocked in the word filters, but you can see they ended up in the title all the same. I've also specified that red phone emoji as well but that's not working either. You'll notice the blocked terms are nowhere in the post body at all, because the system stopped them from posting it with those terms in it.

I don't, because who wants to keep spam visible on the site after all? It's easy to reproduce though. Set up a post filter to block a word, making sure that even admins are subject to the filter. Put the offending word into the body of a post. It will block submission informing you that you included the forbidden word. Now try it again, only put it in the title of the post instead. The system will allow it to go through. This should definitely not be happening since spammers rely mostly on the titles to attract attention from search bots.

For the cost of the license we should be getting that level of spam protection as part of the package, not as part of a 3rd party purchase on top of the package. IMO, whatever system is currently in use is worthless. Maybe it's time for IPB to partner up with Akismet and implement something centered around that, because that actually works and correctly learns from behavior immediately rather than waiting some unspecified super secret amount of time before obvious as hell spam is blocked by the system.

The reason I asked about deleting the accounts wasn't about whether they could come back and register again. Your system is utterly failing to do that anyway. A new frustration in all this has come up though. The realization that the post filtering feature only checks the content of the post body. It doesn't check the titles at all. So despite the fact that I added block terms to the filter, I logged on today to yet more spam from these people with the blocked terms in the title but not the post body. That doesn't really do any good when it's the titles they're using to the greatest effect. Including their stupid little phone emojis. So I don't get why topic titles aren't being checked by this. That seems like a pretty big oversight. And I gotta say, it was a delicious irony to find the emails coming from this site to tell me that there were new posts in this thread are being flagged as spam by Gmail. All in all, I gotta say that I'm not really happy with the poor showing that the spam defense system is presenting. Seems pretty damning to me when other customers are recommending Marketplace packages that do a better job of this than a full team of professionals.

I wasn't asking you how the filtering works, I just wanted to know how long it takes for reported spam to get incorporated into the detection. So I'll ask a related question instead. Once we flag a spammer, do we need to leave their data in the system or can those accounts and content be permanently removed without issue? With the registration data, can I suggest that a feature be added at some point so that we can see which questions the spammers have been asked? It's been my experience elsewhere that when they do break this, they tend to only break a specific question or two and replacing them goes a long way toward tripping them up. But we can't do that right now because the system doesn't keep track of it. Regarding the spam defense setup, perhaps you missed where I told you that every single one of these spammers scored a 1, so changing the level 3 action won't matter. Besides, we've had legitimate users get dinged at level 3 and require manual approval far too often so it seems to me there's something very wrong there when the only people being inconvenienced in some way are the legit users. Yes, I did look at the hCaptcha settings and bumped it up to moderate difficulty. I guess since nothing the system you've provided us is actually doing anything, I can try bumping it up to the max difficulty.

For the last 2 days, our site has gone from essentially zero spam to suddenly being under heavy assault by bots all registering to post airfare scamvertising. Last night I took advice from another thread suggesting switching the registration captcha to hCaptcha instead of the default. That hasn't even slowed them down one bit, because again today I've had to flag 2 dozen accounts (and my moderators are fielding dozens more I haven't seen myself). Every single one of the accounts we've all flagged in the last 2 days have bypassed the spam defense system with a score of 1, so it isn't an issue of being too generous with account registrations. They must also be bypassing the question & answer challenge we have set up in addition to the standard captcha. Further SOME of the posts are being caught and flagged for manual approval, but not all of them, despite them all literally using the same colorful rainbow emojis in their titles and text and all linking to the same set of scam websites for airline tickets. The other thread suggested turning off all of the social logins, like Facebook, Google, and Twitter, but for us those were never activated to begin with. Only the standard IPB login system is enabled. So in light of this I have a couple of questions: 1. When a spammer is flagged, how long does it take for the defense system to learn this and act accordingly to stop them from registering? 2. When a clearly scammy topic is posted, why does the forum only catch some of them and not others? 3. Is there a way to look into the registration data and see which question and answer set someone had to go through? Maybe it's simply a case that the botnet running this attack has found one or more then can readily answer and we just need to change or remove them. 4. WHY oh WHY does the "Contact Us" form not use any form of captcha on it by default?!? (this is a whole other source of problems not related to this)

I'd like to second a request for this as nearly every user who wishes to delete their account on our site also wants their content removed in most cases (usually gallery and downloads).

Disregard. Not sure what happened but the site is working fine today.

After updating the OS to bring in PHP 8.1 on my site, the status messages window is broken. Figuring it might be a theme issue, I checked on the IPS default theme only to see it's broken there as well. The window is filled with repeated instances of this error: [[Template core/front/widgets/recentStatusUpdatesStatus is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]] For obvious reasons I'm not about to reset the entire theme of the site to fix an error that didn't exist when PHP 7.4 was handling the site. I've been running IPS 4.7.1 since it released earlier this month and it was fine on PHP 7.4.

Well here's the issue. That box was NOT something I had checked myself. I've been over the logs and at no point was the forum permissions edited to allow that option. It got enabled by the package at some point during an update. I have no idea how long ago it was, but it also wasn't the only private area that was leaking. The second issue is that the recent posts widget AND direct URL access to a thread are NOT validating the access controls properly. You currently have things set up to let the "read topics" permission override the "see forum" permission. If you've set things up to block them from seeing the forum, it should never have allowed them to read the topics, and the widget should not have displayed it for all to see when they're not even logged in. That means bots like Google could index things that should never have been exposed.

I've checked over the remainder of our site and discovered this same issue was present on another forum intended to be private. The same flag allowing Guest users to read topics was enabled and I am 100% certain I did not set that flag myself. So it seems as though this checkbox issue has been introduced into the package by a previous update and IMO other forum admins need to check this on their sites too.

A user reported an issue today on our site that revealed a security issue. If a forum has been set up to be a private area, like for instance an administrators forum, but the checkbox in forum permissions for "Read Topics" is accidentally selected for a group, the "Recent Topics" widget will reveal this to any members of the group who happen to be surfing in Incognito Mode in their browser. In the case of our site, this happened to be an errant checkbox allowing Guest to read topics even though they'd been excluded from being able to see the forum. So for example, this is a valid setup that will properly prevent the widget from revealing anything: If instead you accidentally have the checkboxes set this way, Guests can read the topics even if they're not supposed to see the forum at all: If they happen to have the direct URL to the topic, they can also access that directly through the site without going through the widget. So there's apparently two different related issues at hand here. One that the widget is leaking info, and the other that the topic reading functions are not validating forum level permissions first.

I've been getting these "-200" errors ever since updating to 4.6.x and I'm pretty convinced it's due to the fact that the upload progress bars are not working. This is in turn causing the browser to lose communication with the server if the upload is large enough. If the upload takes too long then it triggers the error. This never used to be an issue with 4.5.x because the progress bars worked fine there and it didn't matter how big the file got as long as it compiled with the limits set in the ACP on the particular category.

I've already tried that, but it doesn't maintain them in the order they're uploaded in for some reason. So that doesn't help unfortunately.

When a file category has the "Keep previous versions" setting enabled, admins and moderators will be presented with an option during a file upload to toggle keeping the previous versions. When a regular member does this, no such option is given and they are simply told the previous copies will be archived. I filed a support ticket thinking this must have been a bug, but IPS says it's made this way intentionally and that I should file this here for consideration. So here I am. Regular members should get this option presented to them as well because not all uploaders want their older copies of things kept even when the category has the setting enabled.

Yep, another downloads module issue. It would be really nice to be able to get some way to drag & drop uploaded screenshots and place them in a new order. Right now there appears to be no way to guarantee a particular order to screenshots associated with an upload. I'm sure it seems like a silly thing to want, but people uploading stuff to showcase their work often have a certain order they'd like things in.

At the moment, comments and reviews on file uploads can only be enabled or disabled at the category level. So either they're off entirely for everyone, or they're on for everyone. I think this is something that would be useful to have optional controls for on each individual file upload. Some people may prefer to use the comments and reviews, others may prefer to direct things toward an actual forum topic. They might also want to decide to disable one or both of these at some future point as well. In addition, it would also be nice if a file upload had an option somewhere to point to a topic after an upload has already been submitted, and to specify one during the upload instead of having to use the topic linkage feature in the ACP to assign where they would go.