What is active_users table used for?

I saw that if I am logging with an account in my site from a browser, say IE, and then I am logging in with the same account in another browser in the same time, say FireFox, the second login is possible, and more than that, Modx doesn’t seem to bother about that....

but the problem is that in this way, the user can mess up my session variables, and thats not good....

how can I validate an user if he’s already logged in?, that the user is already in the system?....because I don’y want to permit a second login from any location (same computer or different computers)....

I have looked in the code and in the tables, especially in the active_users and web_user_attributes, but strange anough, in the active_users table, the users still remain after the log out....

so, what is active_users table good for?....

That table is primarily used by the Manager to lock items if the active_user is already editing them. I believe it’s also used for the manager log.

Negative values are for web users; this way you won’t have a conflict between manager user #6 and web user #6.

But you could certainly use it to prevent mulitple logins. Use a query to get the last activity of the user, and if it’s not 8 (logout) then don’t let him log in.

Good info... I have looked in that table with other eyes....

And I founded that Modx (weblogin snippet more exactly) doesn’t update the active_users table with the action=8 when a user logs out (I saw that 8 means logout ... there is a file, manager/includes/actionlist.inc.php which contains all the action codes)

in the weblogin.processor.inc.php file, where the logout portion of the code is, there are just following actions:
1. invoke OnBeforeWebLogout event
2. unset-ing the session
3. invoke OnWebLogout event
4. redirecting to a page with ’REDIRECT_REFRESH’ option...

what am I supposed to do?...write a plugin who updates the active_users table? or update the weblogin.processor.inc.php file??

thank you for feedback anyway:P...that helped

well, that weblogin system was bolted on to Etomite somewhere around 0.6 I believe, and hasn’t really been worked with since then, since we’re working on a whole new user management system. At the time it was a whole lot better than no user login system at all.

I would write a plugin rather than mess with the .php file.

Do you really want to stop login #2, or do you really want to stop there being multiple logins at the same time?

You cannot rely on users logging out, therefore you have to favour login #2 over login #1. I’m not completely sure how other systems handle this, but as a user I have often been asked "There is already an active session. Logging in again will stop the existing session. Is this OK?". The same system also has a session timeout, which is also something you will have to introduce.

What session variables is the user messing up?

hmmmmmmmmmmmmmm.... >:(

If one user can login in the same time twice, he can move around in the pages of my site, and some pages set their custom session variables (meaning my creation) and theese variables influences the behavior of other pages... so I dont want to mess everything up just because one user want to have fun....

So I did the following:
1. I wrote a plugin which updates the active_users table when a users log off.... and it replaces the action field with 8.
2. I verified directly in the weblogin.processor.inc.php, before the $modx->invokeEvent("OnBeforeWebLogin",...) command, if the action field for that username is different from 8, so that means that the login process must stop with a message of error....

I tried to write a plugin for step 2, but I don’t know how to access variables in weblogin.processor.inc.php, from the plugin, cause I wanted to influence form the plugin the route in the weblogin.processor.inc.php, but I failed:P...... so I aborted the idea of the plugin (maybe u can give me an idea...)

...BUT.....

if the user closes the window, or the client shuts down, or some failure appears, the active_users table is not updated, and when the user tries to log back, the server sees that the user is still logged in (because the value of action in the active_users table is, logically , different from 8 ), and this is too much for me.... because I don’t know how to work with sessions, and I dont know where modx receives information that a session has ended when a user closes the window for example.

And... the perfect way it would be to give priority to the new login attempt, and the previous session of that user to disappear in space:P.... but How do I do that?

PS: I dont care about the method, not accepting a second login, login #2 as u say, or not accepting multiple logins from the same user.... the goal is for a user to log once, not multiple times.... so, ofcourse that what I really want is to not permit multiple logins...

Quote from: mishhh at Sep 05, 2006, 06:13 AM

If one user can login in the same time twice, he can move around in the pages of my site, and some pages set their custom session variables (meaning my creation) and theese variables influences the behavior of other pages... so I dont want to mess everything up just because one user want to have fun....

What about if a user opens multiple pages in tabs? It is difficult to expect a savvy user to navigate around in one path.


Quote from: mishhh at Sep 05, 2006, 06:13 AM

if the user closes the window, or the client shuts down, or some failure appears, the active_users table is not updated, and when the user tries to log back, the server sees that the user is still logged in (because the value of action in the active_users table is, logically , different from 8 ), and this is too much for me.... because I don’t know how to work with sessions, and I dont know where modx receives information that a session has ended when a user closes the window for example.

MODx does not actually receive any information. A session simply times out and expires. The user could leave the window open overnight; he would find himself logged out when he came to click on anything the next morning.

Quote from: mishhh at Sep 05, 2006, 06:13 AM

And... the perfect way it would be to give priority to the new login attempt, and the previous session of that user to disappear in space:P.... but How do I do that?

The only way I can see this working is to keep checking whether a user is logged in with the latest session - ie, when a user logs in, store the date & time in a session variable and in the db. If a user session’s session timestamp is different to the one in the db, let them know that they’ve been logged off because they’ve logged in elsewhere.

There may be a better way, I’d have to research it. It has not yet been an issue for me anywhere. If I need multiple sessions to use the same information, then I store it in the db rather than the session.

I am curious as to what session variables you are setting that influence the behaviour of other pages. Is it actually OK that these are reset on each new login? It may be that you too will find benefit in storing page-influencing user variables in the db.

I am investigating sessions in php... I don’t really know what to say right now exactly, but it seems that ur solution is quite suited, and it seems that indeed I cannot rely on logout event.... maybe just for the record, to mentain the status in the active_users table... which is not so bad....but to rely on the logout event is not a good idea...

Anyway thank you very much for enlightenment:P.... I will do something like this:
1. after a succesfully login, I will retain the sessionid in a session variabile say $_SESSION[’current_user_session’]
2. every time when I feel like checking the user status (maybe everytime when I check if the user is logged in for displaying the page he requests), I will check the database sessionid for the user with the $_SESSION[’current_user_session’]
3. if they differ, I kick the user out:)....with a message of course... but that I don’t know how right now but I will manage it (redirect, destroying session like hell:P..etc)

anyway thank u very much and I will write here what happens next...