[3.0] Remove PHPSESSID

[sbulen]

Partial for #8383 (addresses 3.0 only)

This PR removes PHPSESSID URL handling altogether from SMF. It also addresses the 8.4 SID & session parameter deprecation issues, that are related. The point of the 8.4 changes was to eventually remove PHP's PHPSESSID URL processing.

It goes a bit further and will not write sessions where cookies are not present/allowed. I believe this last part can significantly decrease MySQL CPU workload for websites that are getting crawled heavily (like mine).

Testing thus far is fine. Things work OK with & without cookies. No impact to logon/logoff. No impact to queryless URLs. And there are DEFINITELY far fewer session records, that I believe were all unused anyway.

Loss of functionality:
I believe the only functions that are no longer supported are:

• Guest posts with cookies disallowed
• You cannot view who likes posts with cookies disallowed
• Search verification with cookies disallowed (search works OK without verification)
• New user registrations with cookies disallowed (not really a loss, because they can't login with cookies disallowed)

[sbulen]

See #8394 for 2.1 version.

[sbulen]

Resolved conflicts.

[Sesquipedalian]

If we want something cleaner, another option would be to not display the search & post (& login) buttons when cookies are not found. Or an error popup, saying cookies are required. Open to feedback.

An error popup is a good idea. This should be implemented in this PR before we merge it.

[Sesquipedalian]

We might as well rename ob_sessrewrite to something like obDebug while we're at it.

Also, it would be nice to add that error popup you suggested earlier, if you are willing to write the code for that.

[sbulen]

I'm looking into the popups. While testing this code with various options, I discovered two new wrinkles:

• The captcha for new user registrations doesn't work either
• The login error message for no cookies changed... It used to give you a nice 'please check your cookies' error, now it gives a session error.

The latter issue is a bit of a headscratcher, as the session issue is encountered far earlier, before the cookie check or the logon action is invoked. I.e., can't just fix it with a simple edit in the logon action. And 3.0 behaves differently than 2.1 here - the session error is buried in the browser console & not actually displayed.

...So, logically, I spent the last 3 days trying to get xdebug to work without cookies to debug properly. Most of the info out there is out of date & predates xdebug3, and actually broke my IDE pretty bad, leading me to upgrade my out-of-date IDE... 🙄

(I put the water on to boil & started peeling the potatoes, while peeling the potatoes, the phone rang, while on the phone, the doorbell rang, opening the door, the dog escaped...)

[Sesquipedalian]

Oof. I didn't think it would be quite so miserable to do that. Thanks for being willing to slog through it, @sbulen!

[sbulen]

Question... in Subs-Compat.php, ob_sessrewrite points to ob_sessrewrite. But ob_sessrewrite only does part of what it used to do - it no longer does the queryless URLs function.

In Subs-Compat.php, should ob_sessrewrite call both functions?

[Sesquipedalian]

Good catch. Yes, it probably should.

Outdated

[sbulen]

Notes on the recent commits (same as in 2.1):

With cookies disabled, & PHPSESSID removed from URLs:

• Captchas did not work - the image was missing on the screens. This affected guest posts, guest searches, & new user registrations.
• Even when captchas were not required, guest posts did not work & registrations did not work - they errored out on session errors.
• Guest searches work fine if captcha is not required.

Note that if you went to the action under these circumstances, the screen was incomplete - it was missing the capcha image. Since it can look quite odd/confusing, partially painting the screen of a function they can't use, it is a little tidier to just not let them go there.

Note also that the login logic needed a little tweaking - checking the session before loading the theme made it difficult to provide a meaningful 'check your cookies' error upon login. A workaround is proposed here.

The posting function cannot be tested at the moment in 3.0, I believe there are permissions issues for guests... See #8615