Jump to content
Announcing Achievements! ×



  • Posts

  • Joined

  • Last visited

About jay5r

Recent Profile Visitors

649 profile views

jay5r's Achievements See all achievements


Apprentice (3/13)

  • First Post
  • Collaborator
  • Reacting Well Rare
  • Week One Done
  • One Month Later

Recent Badges



  1. jay5r

    Message Spam

    This thread was originally posted in the feedback forum. IPS (presumably) moved it here. But yes, I agree – it doesn't seem to be a server management/optimization issue. Clearly IPS needs to make some improvements. Today I added yet another level of groups. I had defined "New Member" too broadly and too many people were getting restricted, and hence frustrated, by it. So now I have two levels of reduced privilege – "New" and "Junior". I'm hoping that will be enough to keep my good members happy when they haven't quite met the threshold for full membership.
  2. jay5r

    Message Spam

    So I implemented the whole New User scheme and there are issues… According to my members "Conversations allowed to start per day" is misstated. It's actually "Messages allowed to send per day" which is a completely different concept. If you're trying to stop a spammer you need "Conversations allowed to start per day" not "Messages allowed to send per day". AND it makes no sense to include messages to the admin/moderation team in the caps (which they are, apparently). New members should be able to respond to any message they were sent, and send messages to the admin/moderation team. It's just they shouldn't be able to initiate more than X new conversation threads per day. So basically controls to stop spammers using the message system create problems with the good users. In order to keep the good members I'm going to have to loosen the restrictions to the point where spammers can cause a bigger problem.
  3. jay5r

    Message Spam

    I've set up additional groups (one for new users, one for trusted users). Hopefully that will do the trick. One question though… When you set up criteria for promotion (or demotion), the criteria you list are all have to be met, correct? In other words it's Criteria 1 AND Criteria 2 AND Criteria 3, not Criteria 1 OR Criteria 2 OR Criteria 3, correct? Which means if they have to meet multiple criteria to get promoted then you can do that all in one criteria set, but if meeting any of a few different criteria can get them demoted to a lower group, then that needs to happen each in a separate criteria set. Right?
  4. I'm using InnoDB, with 3 GB of RAM in a pool with 4 instances. Typically buffer usage is around 98%, and key efficiency 100%. I didn't look too closely when I truncated the table this morning, but I know the first time I did it there were only about 500 records in `core_sessions`. Right now there's about 1250 records in the table and everything is operating smoothly. I simply don't understand how sometimes, all of a sudden, there are problems.
  5. For the third time in as many weeks I've discovered that IP.Board is causing problems with MySQL. When I go in and look client connections to MySQL I see a backlog of requests that look like this one: -- Connection Id: 208197222 -- User: username -- Host: localhost -- DB: databasename -- Command: Execute -- Time: 3206 -- State: Sending data /*IPS\Session\Store\_Database::getOnlineUsers:79*/ SELECT COUNT(*) FROM `core_sessions` WHERE ( core_sessions.id IN(SELECT MAX(id) FROM `core_sessions` AS `s` WHERE s.running_time>1572865467 AND s.login_type!=3 AND s.login_type!=1 AND s.member_id IS NOT NULL GROUP BY `member_id`) OR core_sessions.id IN(SELECT MAX(id) FROM `core_sessions` AS `s` WHERE s.running_time>1572865467 AND s.login_type!=3 AND s.login_type!=1 AND s.member_id IS NULL GROUP BY `ip_address`) ) AND core_sessions.member_id IS NOT NULL /* statement may be truncated */ I've been able to fix the problem by killing those queries and then truncating the `core_sessions` table (which seems to cause no problems). How do I stop this problem? It slows down everything on my server (not just the IP.Board site).
  6. jay5r

    Message Spam

    I'm talking about registered members causing problems with the message system, not guests. But I did just check the permissions and guests can access the Messages module, but I'm not quite sure what that means since when I go to the site as a guest I can't seem to access or see anything related to messaging.
  7. jay5r

    Message Spam

    AFAIK, I never received any type of notification saying there was an update available. I'm religious about doing updates promptly when Invision informs me an update is needed. When a Wordpress plug-in needs updating, you know about it. But it's crickets with IP.Board. Bottom line I didn't really need member map, so I'll just keep it disabled. If people miss it and complain I'll think about putting it back.
  8. jay5r

    Message Spam

    The only one of those I hadn't already done is defining a new member group. I'm unable to create new groups. When I click "Create New Group" I get the error: TypeError: Argument 1 passed to IPS\membermap\extensions\core\ContentRouter\_MemberMarkers::__construct() must be an instance of IPS\Member or null, instance of IPS\Member\Group given, called in /web/sites/somedirectory/somedomain/public_html/system/Application/Application.php on line 858 I've had problems editing or creating groups for a while now. Never tried to fix it because it wasn't urgent – it doesn't seem to break anything other than creating and editing groups (which I haven't needed to do). But having done nearly everything on the list, it's just not enough.
  9. I'm having a considerable problem with spammers using IP.Board's message system to spam with links I'm concerned lead to malware. I've disabled most URLs site-wide. And I've put a message before all new URLs saying "[think before following links]", but they continue to try to get my members to go to URLs. (Even putting "virus free!" after the URL, like anyone would believe that.) On top of everything when you mark someone as a spammer I'm pretty sure the messages they've sent don't get disabled. I know when I actually delete their account their messages continue to exist in the `core_message_posts` table in MySQL (with the `msg_author_id` set to 0). It just feels like IP.Board's message system is an enormous security hole. Here are things I think would help… Don't allow new members to post links anywhere on the site – messages, forum posts, etc. New members who try to send messages with URLs in them should have their messenger system turned off (or set to receive only). They should have to ask an admin to turn it back on. Clearly, a warning message would be needed telling them not to include URLs, so "good" members don't get tripped up accidentally. Any emails that go out notifying the recipient of the message should not contain the body of the message if it's sent from a new user. Otherwise the harmful link remains in their inbox after it's deleted in IP.Board. New users should be required to go through reCAPTCHA when they submit any type of content (messages, forum posts, etc.) How "new users" are defined is up for debate. I use the community rating system and think that some threshold of points would be a decent definition of "new user", but there should also be a time limit – must have been a member for a month or two, or whatever. However, the system would need to be hardened so spammers with multiple accounts don't use their older accounts to give their new accounts ratings. And anyone who gives ratings to spammers should lose that amount of rating when the person they rate is marked as a spammer (which means ratings need to be able to go negative). Basically I'd encourage you guys to get much much tougher on people who use IP.Board to spam and hack.
  10. Is it possible to have different prefix/suffix/hashtags per forum? That's sort of an important feature for me. Also, is it possible to not shorten the links (in which case Twitter shortens them with t.co)? IMHO, third party link shorteners have lower click-through rates. Since links that are only shortened by t.co display the name of domain of the site, the user knows where they're going and trust/click the links more.
  11. This doesn't work on SSL-based sites, but one small tweak will fix it. In public -> js -> FeedEk -> FeedEK.js the call to to googleapis should be protocol agnostic - so, just //ajax.googleapis.com/ajax/services/feed/load?v=1.0&num= In other words, take off the http The other small problem, which really isn't a problem, is that when it breaks on SSL there's a broken image where the feed should be. The image is the loader.gif image is in public -> js -> FeedEk, but it's trying to load the image from the root directory of the site. Not quite sure where that problem is coming from though… Once the call to googleapis is fixed it's a great mod. Thanks!
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy