[2.1 & 3.0]: Denying guest access is still costly

[sbulen]

Basic Information

The check whether guest access is disabled is, unfortunately, late in the overall process - AFTER the session has been loaded & AFTER the guest's/user's online status has been logged.

I.e., it doesn't help. Although it effectively blocks the guest from reading anything, the problematic I/O and high CPU caused by bots/guests remains.

So... Folks on the forum attempt to handle bot issues by blocking guest access, but that won't work.

What's worse, is that log_online shows info about the request, not the end result. I.e., in the log it appears they're still browsing when they're not.

We need to find a way to make blocking guests more effective, & to stop all of the I/O associated with guests/bots, BEFORE the session & logging kick in.

https://www.simplemachines.org/community/index.php?topic=593888.0

Steps to reproduce

Expected result

No response

Actual result

No response

Version/Git revision

2.1.6 & 3.0 Alpha 4

Database Engine

All

Database Version

No response

PHP Version

No response

Logs

Additional Information

No response

[jdarwood007]

Going to tag for a future 2.1.8, but I'm not certain if this would make it. I'm not entirely certain what we can optimize here.

We could, when we determine that they don't have a cookie, not try to load the session.

[sbulen]

My suggestion here is that we move the KickGuest check earlier, before the logging, but after the session check. At that time we'll know if they're a guest or not. We'll still get the session writes, however, we won't get the log_online writes. Many folks find these confusing, as they have kicked guests, but the Who's Online still shows them all.

Not perfect, but it would reduce IO, and make Who's Online make sense...