Web Software Architecture and Engineering – Life on the Bleeding Edge

I was wondering if anyone has done this successfully, but how would you restrict concurrent logins in a CF app?
Ideally, you could tie username to a live session, and on log out or timeout, drop that username/session combo, and allow further logins. But this type of solution is unreliable in my experience.
Is there any 3rd-party tool, framework plugin, or CF app, that can do this well?
We could have several options:

  • Deny additional logins while one session is active
  • Allow 2nd login, logout 1st
  • Etc



Comments on: "Restrict Concurrent Logins – Help Needed" (9)

  1. i wonder if the cf sessiontracker could help:


  2. We use a token key that’s passed to each page to track unique logins. When a user tries to re-login, we expire the previous token and issue a new one.

  3. @Marc,

    I’ve tried session tracker a while back with no luck in CF7 days. Maybe I’ll give it a try again.


    So with each page load, you check if your token still exists? If a new login occurs, it deletes the old one, and thus you are forced out? Was this a lot of work? And its reliable under load, etc? Developed as part of a framework or code in App.cfc? (Curious!)

  4. How many users do you have logged in at one time? If it is not that big of a number you could always keep a list of logged in users and search the array for a match.

  5. Phillip Gomer said:

    I use a CFC in the application scope that manages all active sessions. I currently track by sessionID and keep track of the users last request and session start. Email me if you want the code.

  6. @Dan,

    The number can be large, peak hours can be in the hundreds, and we’ve only just begun, so it must be scalable.


    Love to see your code.


  7. Christopher Bradford said:

    One more challenge to add: if it needs to be scalable, it should probably also work throughout a cluster, so application scope is not sufficient.

  8. At a past job for a very large public company, we decided that the only way for us to use session management which would work for all of our complex security scenarios, clustering (this was during the time of CFMX 6.. before CFC clustering), etc, we would have to roll our own session management from scratch.

    Long story short, at the start of each page request our application would check a session db to see if it could find a matching session based on a number of keys stored in a clients browser. If someone logged in again with that username but was still considered logged in, we’d just kill their old session and use the new one. All sessions were unique so the old user would be booted out of the system if their session id stuff did not match the current session for that user.

    Sorry to be vague, it was something I wrote to protect very sensitive data and I don’t think it’s something I should go into detail about. But basically it’s a custom session implementation which is shared via a session db. It was scalable.. last I knew it was running on about 20 app servers which typically supported 1800-2000 concurrent sessions a piece, multiple applications, etc.

  9. Slight correction– if an old session was found during a page request, the user would be logged out immediately and redirected to a login screen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: