#1
Hi all,

Before I go into the depths of writing a module for a per seat licence for one of my projects, has anyone got anything they have done from concept to gotcha's? Im all ears.

Im looking at providing a system of single session or token per user seat. Currently multiple people can log in with the same user credentials and I want it to be able to not allow this to happen. I have a system wide subscription module for an old project in CI3 which I am looking to develop into a TG system and this will run hand in hand.

Thanks in advance

Keith
#2
Hello,

It seems to me that the first issue is login. Have a simple if statement that says if logged in --Display a message saying cannot have more than one user logged in with same credentials-- and then redirect back to the login page.

Dan
#3

The thread creator has indicated that this post solved the problem or provided the best insight.

Members who post winning responses earn points for our leaderboard.
Points mean prizes!
Hi Keith,

I'd separate the licensing logic from the authentication logic.

Rather than trying to determine whether a user is "active", I'd track authenticated sessions in a database table (for example: "user_id", "session_token", "last_activity", "expires_at"). A successful login creates a session, logout removes it, and expired sessions are cleaned up automatically.

If your goal is to prevent account sharing, allow only one active session per user account.

If your goal is a true per-seat licence, simply count active sessions against the purchased seat limit before allowing another login.

I wouldn't rely on frequent heartbeat/ping requests, as they add complexity and can keep abandoned sessions alive. Updating "last_activity" on normal requests, combined with a sensible inactivity timeout, is usually sufficient.

This approach also makes it straightforward to provide an admin page showing active sessions and allowing them to be terminated if required.

Cheers,
Si

P.S. In Trongate V2, an interceptor method could be a simple place to validate the user's licence session and update the last activity timestamp during normal requests, with a sensible interval (for example, only updating once every 60 seconds) to avoid unnecessary database writes.
#4
Hi DaFa

I use interceptor methods already for a database migration module so thats a great shout and be a good method of preflight verification.

All excellent ideas guys, thank you muchly

Keith