Best practices to prevent login sharing on high-ticket B2B plans?

Hi again,

Thanks for the help. Regarding device tracking—Has this feature been added to your development roadmap for the future?
If so, when could we expect it to be available?

Best,
 

I've added a feature ticket for device fingerprinting support in CB AntiSpam. I do not have a timeframe for when it will be implemented.

forge.joomlapolis.com/issues/9876

Hi krileon,

I’ve spent the last couple of days testing and experimenting with the CB AntiSpam login parameters, and I have a few specific questions regarding the logging and duplicate login behaviors.
The documentation is a bit sparse here, so I would love some clarity on how to optimize these three areas:

1. Log Behavior ("Count" vs. Unique Rows)
From my initial testing, it looks like each user gets a single row in the CB AntiSpam logs where a Count value increments, though I might be misunderstanding how it displays.

• My Observation: I'm a bit unclear on what this "Count" value actually represents. I assume it tracks successful logins, but does it also include failed login attempts or other session-based events? Furthermore, if my understanding is correct and it just increments a single number on a single row, it seems like I can only see the total count and the latest login date. If that's the case, it feels like it would be difficult to detect if a user is doing something suspicious, like logging in 10 times in a short span of time.
• The Question: Could you clarify exactly what triggers the "Count" increment and if the log indeed overwrites a single row? If it does, is there a configuration to change the logging behavior so a new row is generated for every single login/login attempt? Lastly, is it possible to log failed login attempts specifically (e.g., when a user is blocked due to a duplicate login)?
  

2. "Logout Current Session" & Missing Notifications
Next, I tested the Duplicate Logins feature using the Logout Current Session block method. The core functionality worked perfectly (logging in on Device B instantly terminated the session on Device A).
However, I ran into an issue with user feedback:

• The Issue: During my testing, I wasn't able to identify where the "Block Reason" message or notifications are actually supposed to be displayed or sent. Even with both Notify User and Notify Moderators enabled in the Log tab, I couldn't locate any on-screen alerts, system messages, emails, or backend log records on either device. I am likely missing a configuration step here, but it appeared completely silent from my end. I want to make sure I can surface a clear message to our users so they understand exactly why they were disconnected, rather than assuming it's a defect in our platform.
• The Question: How are these notifications intended to display or be delivered? What is the best way to ensure a clear message is actually triggered—ideally to both the person starting the new session and the person whose session just got terminated?
  

3. "Deny Login" & Block Duration Formatting
As a backup, I tested the Deny Login method with the allowed active logins set to 1.

• The Issue: I left the Block Duration field empty because I don't want to punish the user with a time-out; I just want them to manually log out of their other device first. However, leaving it empty seemed to result in a permanent block.
• The Question: Is there a way to make the block dynamic so it only denies the login while the other session is actively running? If we are forced to use a time-based duration instead (like a 1-minute timeout), what is the correct formatting syntax for that field? The backend only provides
  Code:

  +1 HOUR
  as an example.

I know this is a lot of questions at once, but any guidance on how to properly configure these settings for a smooth user experience would be incredibly helpful.

Thanks again for the support!

Could you clarify exactly what triggers the "Count" increment and if the log indeed overwrites a single row?

If logging is enabled it logs a unique entry by user id and by ip address. If their ip address didn't change then it just increments count. That's pretty much all there is to it. Logging is not specific to logins.

If it does, is there a configuration to change the logging behavior so a new row is generated for every single login/login attempt?

No.

Lastly, is it possible to log failed login attempts specifically (e.g., when a user is blocked due to a duplicate login)?

That's handled by the Attempts feature. Once enabled it will keep track of all failed attempts (captcha, login, forgot login (if using CBs), and registration). Attempts are used to automate several blocking features. Specifically for login within CB AntiSpam > Parameters > Login > Auto Block, which can automatically block someone for too many failed login attempts.

How are these notifications intended to display or be delivered? What is the best way to ensure a clear message is actually triggered—ideally to both the person starting the new session and the person whose session just got terminated?

A block reason in that case is only going to be displayed for denied login. It's just added to Joomla's message queue so it'll show wherever your Joomla's template displays messages. Logout of current session won't show anything. If their actual account was blocked they'll be seen the message on denied login as well.

Is there a way to make the block dynamic so it only denies the login while the other session is actively running? If we are forced to use a time-based duration instead (like a 1-minute timeout), what is the correct formatting syntax for that field?

Block Duration isn't relevant to deny login or logout current session.

As for the syntax it's PHP relative strtotime syntax, which is basically just natural language (e.g. +1 HOUR means block for 1 hour).