Skip to main content ↑ ↓
Recent Posts
31
Chit Chat / Re: Tips for Bots
Last post by ahrasis -
I like the idea of what you did, could this be best, if we make this one of the ElkArte default features, with option to be disabled, or not, so once setup and install, an ElkArte forum is bots free or bots less?

What do you think @Spuds?
32
Chit Chat / Re: Tips for Bots
Last post by Steeley -
For the record. my site uses htaccess to make a significant part of my site "private". My Forum resides "behind the wall". the 'public facing pages' explain the topic of the site and provides lots of 'general' information. The public side also informs of the existence of the forum (could certainly provide some sample screenshots if I was fishing for members, but in my case it's not necessary).

There's a link off the main menu of my site for requesting access to the restricted side. It's two-step process.. Click the link, it brings up a simple form.. you enter your email address, and submit.  The form submittal generates a reply to the entered address, and embeds a 6-digit random code.  It also copies me with that email. 

If the applicant doesn't get an email, it means it was typed wrong. Go back and try again. I want to make sure I send the access credentials to a valid address!

Meanwhile, submittal also brings up a second form for the applicant with instructions about what to do now..  specifically, says to retrieve the email just sent to them, copy the email address AND the 6-digit code into the new form, and fill out a few other fields in the form, information that I use to validate the applicant as someone allowed access to the forum. (In my case, it's people stationed at a particular location during the 'Nam war - things they know about it nobody else would. Your mileage would vary, of course).  I ask for his nickname or call sign - that will inform the username I'll give him if he provides one, otherwise I'll tweak his first name or last name.

When the applicant submits that second form, I comes to me in Email.

[Note: If I were to use the same credentials for everyone. and it gets compromised, now I have a problem - everything "behind the wall" is compromised. I'd have to change it and inform EVERYONE, and likely the unauthorized person too in the process. With unique credentials for each user, I know which account is compromised and can address that one.]
(Steeley's law: If you be lazy up front, you be hate'n your life later. All non-academic knowledge comes in suppository form).

I'll create a password for him based on info he provides.. something easy he'll remember.. (OK, so he was a hydraulics mech with Squadron 345, and a Sgt, so password "bubbles345sgt" will suffice..) I send his unique access info back..

All of the access email requests and my response email providing their unique access credentials are stored in my local computer. 

Voilla! Now they have access to the forum to register. (I don't have guest read access,  so they must register, to get in.)

BOTTOM LINE:

My forum does not get spammed. At all.  Ever. No bots, except the spiders looking for something new on the public side. Occasionally, they get lucky and find something new to link and memorialize. All the private personal information from the guys we share with each other is kept hidden so as not to scare or freak out the civilian visitors -that is back in the restricted area, and secure and snug as a bug in a old forum software version.

If you run a "really large" form with lots and lots of users, just set up a database of users that forbids duplicate username entries to keep them all unique. Otherwise, if you create a duplicate, it overwrites the original and the first username entity can't get in any more..  (and note; username "Mac" is different than "MAC" and "mac" as far as htaccess usernames are concerned).

Oddly enough, I get very few "fakers"... I do get a fair number of first emails, but the second form presented pretty much stops them in their tracks .. they know they ain't gonna fake that stuff (many don't even know what the heck it's asking for in some fields), a couple squirrels gave it a shot over the past 7+ years, but my BS detector is pretty good and an email reply back to them requesting "clarification" never gets answered..  

Anyway, if you want to see how it works, PM me for the website url.. If you're a legit user and not a bot, I'll "get back to ya.."
35
Chit Chat / Re: Tips for Bots
Last post by shawnb61 -
Quote from: nwsw – The session_start on every GET request, combined with db session storage, has a dramatic impact on the server. As an immediate mitigation, I forced sessions to use cookies:

Code: [Select]
sources/Session.php:

@ini_set('session.use_only_cookies', true);

I then configured nginx to no longer serve requests that contain the session id. This only helps until the bots stop including the session id in their requests.

I'll probably move the session management to a ramdisk until I can figure out how to lean out the need for sessions by unregistered guests.

Note that PHP is deprecating the passing of PHPSESSID via URL in 8.x, and it will be removed in 9.0. 

That particular setting, 'use_only_cookies', will be retired soon - mainly because setting it to false is soon to be disallowed.  More here:
https://wiki.php.net/rfc/deprecate-get-post-sessions

So...  The idea is good - don't use PHPSESSID, and, since you're not generating it anymore, you can then block it via .htaccess. 

SMF implementation: https://github.com/SimpleMachines/SMF/pull/8394

One part of the SMF implementation, this commit, can save a LOT of resources.   It's causing some issues for forums that have guest-browsing disabled, though... Those issues are currently being addressed.:
https://github.com/SimpleMachines/SMF/pull/8394/changes/2f2a5e0ae404fd1adb408b87896ce00cca1715ec

The basic idea is that, since you cannot pass by URL, you MUST pass by cookie.  So...  When cookies are disabled, there is no way to pass the session.  At all...  So, don't even bother writing it.  Note certain classes of bots either block cookies or don't use them, or pass their own PHPSESSID...  All these variants cause more session writes. 

These changes will be a hard requirement before PHP 9.0.

You are effectively giving bots total control over your DB writes...   One step further, since they can flood you with writes, they can overwhelm your undo/redo logs.  Which can further lead to issues with backups.  Which can cause performance issues & even bring your site down... 

So stop that...

The savings can border on the ridiculous:
VGF-cpu-2025-01-13.png

In addition, this note outlines even further savings.  The goal is to avoid driving up CPU during bot storms.  I've been testing these on my site.  Check out the CPU charts before/after:
https://www.simplemachines.org/community/index.php?msg=4199062

The more broad notes found here might also help:
https://www.simplemachines.org/community/index.php?topic=593895.0
36
Chit Chat / Re: Tips for Bots
Last post by ahrasis -
I simply use cloudflare as my dns server, so never use any of the above. Not sure about bots as I never keep track on them.
37
Chit Chat / Re: Tips for Bots
Last post by nwsw -
The session_start on every GET request, combined with db session storage, has a dramatic impact on the server. As an immediate mitigation, I forced sessions to use cookies:

Code: [Select]
sources/Session.php:

@ini_set('session.use_only_cookies', true);

I then configured nginx to no longer serve requests that contain the session id. This only helps until the bots stop including the session id in their requests.

I'll probably move the session management to a ramdisk until I can figure out how to lean out the need for sessions by unregistered guests.
38
Addons / [Addon] Topic Preview
Last post by vbgamer45 -
Topic Preview
Version 1.0
by vbgamer45

Description:
Shows a styled popup preview when hovering over topic titles in the message index (board view). The popup displays the topic title, author name, post time, a preview of the first post body, and reply/view counts.

Compatibility:
  • ElkArte 1.1.x

Features:
  • Hover popup with topic preview on message index pages
  • Shows first post body text (truncated), author, time, reply and view counts
  • Smooth show/hide with configurable delay (no flicker)
  • Viewport-aware positioning (stays within screen bounds)
  • Admin settings panel to enable/disable and set preview length
  • Graceful fallback: when disabled, original tooltip behavior is restored

Installation:
Install via the ElkArte Package Manager (Admin > Packages > Install).

Settings:
After installation, go to Admin > Configuration > Addon Settings > General to find Topic Preview settings:
  • Enable Topic Preview popup - Turn the mod on or off
  • Preview text length - Number of characters to show in the preview (default: 256)

Uninstallation:
Uninstall via the ElkArte Package Manager. All file changes will be reversed and mod files removed.

Author:
vbgamer45 - ElkArte Mods

License:
BSD 3-Clause License