[BUG] Multiple AJAX sessions will invoke sorcerer's apprentice mode

[presjpolk]

Describe the bug

The portal accumulates ajax web sessions, causing exponential growth in duplicated output

To Reproduce

Steps to reproduce the behavior:

• Open an AJAX web client
• close the window
• Open an AJAX web client

Results: Everything you send, sends twice. Everything you then get back, you get back FOUR times.

Expected behavior

Each web client should be treated independently.

The PROPER fix I've discussed with Caracal ( see #3327 ), but is more involved. An immediate fix for the problem of ever-increasing duplication of output is below. Also note that there's probably some unnecessary code in websocket that was inadvertently working around that mistake in sessionhandler.

```diff
diff --git a/evennia/server/portal/webclient_ajax.py b/evennia/server/portal/webclient_ajax.py
index d6dc3c9fbf..d10c852c1e 100644
--- a/evennia/server/portal/webclient_ajax.py
+++ b/evennia/server/portal/webclient_ajax.py
@@ -242,6 +242,11 @@ class AjaxWebClient(resource.Resource):
         # actually do the connection
         sess.sessionhandler.connect(sess)
 
+        for s in self.sessionhandler.sessions_from_csessid(csessid):
+            if not s == sess:
+                s.sessionhandler.disconnect(s)
+
         return jsonify({"msg": host_string, "csessid": csessid})
 
     def mode_keepalive(self, request):
diff --git a/evennia/server/sessionhandler.py b/evennia/server/sessionhandler.py
index 0dd7956b48..b8d8ef6982 100644
--- a/evennia/server/sessionhandler.py
+++ b/evennia/server/sessionhandler.py
@@ -784,7 +784,7 @@ class ServerSessionHandler(SessionHandler):
             sessions (list): The sessions with matching .csessid, if any.
 
         """
-        if csessid:
+        if not csessid:
             return []
         return [
             session for session in self.values() if session.csessid and session.csessid == csessid

[Griatch]

Thanks for the fix and analysis!

As a background, the AJAX client is old and is normally only used as an emergency fallback if the server is misconfigured (usually by not opening the WS ports or WSS configuration fails). Considering websockets are supported by all browser these days, this should normally not be an issue for most people (but this definitely needs to be fixed of course).

(Note: while a diff works, a PR is often easier since one can then discuss solutions in-place. Also allows proper credit to be given)

[Griatch]

Hm, testing this, I cannot reproduce this behavior. I see no duplicate inputs no matter how many tabs I open or how many times I close and reopen the client. I also don't see any buildup of django sessions in the database (it's re-using the same session as reported in #3327, but that's a different matter).

In fact, your patch to the ajax webclient breaks the ability to open a second tab in MULTISESSION_MODE=0 (the default) for me; instead of taking over the session from the other tab, the second tab instead becomes unresponsive.

(I did apply the fix to the sessionhandler though, looks like that path is not used by the websocket client).

I tested this with firefox, using a fresh game dir and WEBSOCKET_CLIENT_ENABLED=False in settings to force the ajax client. Which OS and browser are you using, and which MULTISESSION_MODE?

[presjpolk]

I'm using a pretty standard Brave with Windows 11.

The game I'm working on is set to MULTISESSION_MODE 1.

My problem with websockets isn't browser support. It's mobile support. Most people access the Internet on their phones, and a pure websocket approach works very poorly in that environment. People's IP addresses frequently change on mobile networks, which breaks fixed socket-based connections, including telnet and websockets.