Is it possible to prevent concurrent logins in a Dreamweaver Site

In fact, the problem of protecting a connection, whatever it is, will born from the operating flows that your users will have...
If your usability constraint is strong, let's say that only one user can connect simultaneously with the same login, well with the many solutions that exist out there and that are based on a token, there will always be a potential usability, or constraint, problem...

Let me explain...

Case 1 : Bob can connect the system the morning, and Rita will connect the afternnon , both using the same Login... and this will not prevent them from using the same login… so the same login is used by two users.

Well, somes'll say, hey why not filtering connexion by IP address... but doing this,  that do mean that Bob wont be able to use the system from his office, then later on from his home...

Case 2 : let's say Bob logs in from his desktop... the system automatically creates a token and thus no one can log in with that login... perfect... that's also the goal...

now let's say that Bob is still logged in, and he forgets to log out explicitly, he leaves his desk, comes to the meeting room with his laptop and tries to log in to the service... and there, the token being active, he can't...

those case are a simple use cases, but there are many others suituation that could lead to a block.

A few years ago, we had to work for a hospital with a subscription-based online tool that allowed as many user licenses as needed, with the same constraint of only one user per login, and in a single session...
There was an additional layer of locking, namely that the system had to be able to limit the number of simultaneous global users. This was to prevent users from all logging in, and staying logged in continuously.
However, some users was allowed and could still override this restriction and use the system continuously...

I know... you're right, why make it simple when one can make it complicated... but it was anyway, as often,  a justified request, and there are many such cases as it...

Anyway, all that to say, it's quite manageable using HTTP, with sessions, and with some flow logics. On the other hand, it requires a minimum of coding skills, at the JS, REST and DDB (or JSON DB) level.

To answer your question, there is no turnkey solution, one size fits all (will says FZ). Any protection will meet a need, a flow, an expectation that is not necessarily generic, and that you will have to code somehow. Anyway, anyone here, can still assist you , whatever way you will choose.