"Disallow multiple logins" behaves differently in each session mode, and the help text describes only one of them

[e107help]

Summary

The Security preference Disallow multiple logins has two implementations and a third state in which it does nothing, and which one an admin gets is decided by the Session Storage and Track Online preferences on the same page. The help text (PRFLAN_130, lan_prefs.php#L116-L117) describes only the behaviour an admin does not get on a stock install.

Session Storage	Behaviour of a second login	Code
db (shipped default, default_install.xml#L278)	Allowed. The earlier sessions of that account are deleted, so the first browser is silently signed out on its next request.	login.php#L279-L301
anything other than db, with track_online on	Refused, with "This user is already logged in and cannot be logged in from another session."	login.php#L302-L308
anything other than db, with track_online off	Nothing happens. Neither branch runs and the preference has no effect, with no sign of that in the admin UI.	as above

The db behaviour is deliberate and was asked for in #4657 ("drop existing sessions that use the same USERID ... when 'database' sessions are in use"), because refusing the login counts towards the failed-login autoban counter (login.php#L716-L720) and could ban a legitimate user's IP. The help text was never updated to match, so an admin who enables the option, logs in a second time and sees the login succeed reports the preference as broken. That is discussion #6293.

How to reproduce

Clean install of master 7ca831e707653f004b280b0f7bdebcde014972e4, PHP 8.5, MariaDB 10.11, disallowMultiLogin set to 1.

1. With Session Storage on Database (the default), sign in as the same account in two separate browsers. Both logins succeed; the first browser is signed out at its next request.
2. Switch Session Storage to Files and repeat. The second login is refused and the first session survives.
3. Turn Track Online off and repeat. Both sessions stay signed in.

One more finding from the same run

With Session Storage set to anything other than db, the check reads the online table, whose rows are pruned five minutes after the last page view (online_class.php#L335-L339). A user who closes the browser without logging out cannot sign in again until their row ages out, and each attempt in the meantime counts towards the autoban. A stale row from an earlier run refused the first login of a later one while this was being tested.

Options

Deltik's call which of these is wanted:

• Reword PRFLAN_130 to describe what the default configuration actually does, and say that the preference's effect depends on Session Storage and Track Online.
• Make the storage modes behave the same, which means either reintroducing the refusal (and the autoban interaction Improve handling of Multiple logins from the same user/pwd combination #4657 removed) or dropping sessions in the other mode as well.
• Leave the behaviour and the wording as they are.

[e107help]

Built, per @Deltik's decision that the preference means the newer login drops the older session under every setting: #6413 against master, and #6415, its twin against release/v2.3.x.

What an admin gets afterwards is one behaviour instead of three. Tick Disallow multiple logins and the second sign-in always succeeds, the earlier session always goes, and Session Save Method and Track Online no longer change any of that. The refusal is gone, so the five-minute online row that locked a user out after they closed their browser cannot lock anyone out any more, and nothing about a second sign-in feeds the failed-login autoban.

One trade-off in there is @Deltik's call rather than mine, and it is why the pull requests carry a hold rather than a merge recommendation. Evicting a session means being able to find it, and the session table is the only index of an account's sessions e107 keeps, so the preference now puts sessions in the database whatever Session Save Method says. That costs a site on file sessions a one-off sign-out of everyone the first time it takes effect, and database queries per page view it was not paying before. The other way to do it, a per-request check that the current session is still the registered one, keeps file sessions as file sessions and costs a lookup on every authenticated request instead. Both are written up on #6413; whichever he prefers, I will build.

What this means for your own site, once one of these lands: if sessions are already on Database, which is what a stock install ships with, nothing changes for you at all. If they are on Files and the preference is on, which is the configuration in which the preference looked broken, everyone signed in at that moment is signed out once when you upgrade, and signs back in normally. Nothing to do in the meantime either way.