Jump to content

Recommended Posts

Sites such as this one often show the logged on users and guests.

 

post-26806-0-71728600-1419976376.png

 

I have no reason to need to do so, but am curious on how this is accomplished.

 

For users, yes, you've authenticated them and logged them on regardless of IP address, but how do you know they didn't just close their browser?

 

For guests, are they just using IP address?  And still, how do you know when they leave?

 

PS.  How should I include an image in a post like I did?  What I did was first attach a file, and then edit the post to include that file as an image.  Couldn't seem to include an image off my local PC.  Not a better way?

post-26806-0-71728600-1419976376_thumb.png

Edited by NotionCommotion
Link to comment
https://forums.phpfreaks.com/topic/293530-how-to-show-logged-on-users/
Share on other sites

This is a two step process. 

 

a) any time that a user requests for a new page, the database will be updated with the current datetime.

b) to display active users a query will be run that retrieve all the users that has been active for the last xx minutes.

 

Only if users logout the exact time of inactivity can be measured but 90% of all users will never logout so we use a timeout mechanism.

Thanks Frank,

 

Makes sense regarding logged on users being active for a duration of time.

 

Non-users based on IPs?  Maybe not exact, but seems good enough.  Even if a robot hit you, they would only be "active" for a duration of time.

For non logged in users, you would not want to use IP addresses since you can have multiple people behind the same IP address. You would want to use unique sessions. You could then use that functionality for both logged in users and guests.

 

When user requests a page save session ID, User ID (if logged in user) and a timestamp. Then, as Frank_b stated before, you would query the unique users that were active in the last X minutes and do a JOIN out to the user table to get the names for the logged in users.

For non logged in users, you would not want to use IP addresses since you can have multiple people behind the same IP address. You would want to use unique sessions. You could then use that functionality for both logged in users and guests.

 

When user requests a page save session ID, User ID (if logged in user) and a timestamp. Then, as Frank_b stated before, you would query the unique users that were active in the last X minutes and do a JOIN out to the user table to get the names for the logged in users.

 

Ah, session IDs, of course!  Now that has some interesting implications for doing more than just displaying logged users as it is explicitly tied to the client which holds the unique cookie.

 

Would you mind giving me a brief non-code strategy on how this is implemented?

 

I currently have never stored sessions in a database, but have long considered looking into it.  Would this be an occasion to do so?

if you want to track registered users only (read 'after login') there is no need to store the session id into the database because you have the unique user id allready. To track anonymous visitors you only have the unique session id and it will be the only way to keep the visitors seperated.

“Being online” is a fairly vague term, and there are different definitions and techniques.

 

Sure, you can track the activity of a user, but that's “being active”, not “being online”. If I read a longer text on the screen, I'm not gonna click around, so you'd consider me “offline”, even if I have your site right on front of me.

 

My definition of “being online” looks more like this:

  • there's an active session
  • JavaScript is enabled, and there's at least one browser window/tab pointing to your site; or: JavaScript is not enabled, and the last request was less than n minutes ago

This covers both active and passive use, so your users don't have click all the time just to prove that they're still there. To check if there's still an active browser window, you need a heartbeat function which makes an Ajax request every few seconds. If there's a gap in this pattern, it's safe to assume that all windows have been closed. If there's no heartbeat at all, then JavaScript is not enabled.

There are a plethora of GlobalEventHandlers that you can use to track activity using Javascript.

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers

 

 - Clicking

 - Scrolling

 - Window Resizing

 - Scrolling
 - and so on and so on.

 

Javascript is a very powerful language and it will be your best bet for checking authentic activity.  Unfortunately, all of these actions can be overridden, and fake instances of showing activity can be triggered with curl and other site scraping libraries as well as browser plugins.

 

The idea of triggering an AJAX request on every single one of these actions though is a bit daunting.  So you might end up tweaking the your heartbeat script to set Interval times.  You can continue to detail and microengineer what you consider to be the perfect activity checker.

 

 

Then there are those not using JavaScript.  To hell with them.  Unless you're just meandering your way through the dirtiest alleyways of the intertubes, there is no reason to keep Javascript disabled.  For them, I would just set the session expiry time to something small.  Log them out.  Make their experience miserable.

 

Read through the various event handlers provided in the link and you may get some ideas.

 

 

, but how do you know they didn't just close their browser

https://developer.mozilla.org/en-US/docs/WindowEventHandlers.onbeforeunload

 

Phishing enthusiast tend to take advantage of all of these events which is why I mentioned digging through the dark and lonely alleys of the internet.  It's also the perfect marketing tool.  You can tell where people are clicking, how many times, the standard deviation of scrolls and hovers over texts.  The possibilities are endless.

 

Technically, you could also grab the users permission to "view" through their webcams and "listen" through their microphones.

 

Open up facebook, open the network inspector by pressing F12, scroll through the page, hit buttons, click around, chat with someone, you will instantly see all of the AJAX requests firing away.  Keep in mind though that Facebook has a massive massive userbase and therefore an even more massive server infrastructure.  In other words... Facebook's servers can handle that many requests while others may succomb to DDOS problems.

Hey, my post got moved without notification.  Is this normal?

 

Thank you all for the insightful and interesting discussion.

 

Then there are those not using JavaScript.  To hell with them.  Unless you're just meandering your way through the dirtiest alleyways of the intertubes, there is no reason to keep Javascript disabled.  For them, I would just set the session expiry time to something small.  Log them out.  Make their experience miserable.

 

Maybe a little harsh, but then again, I don't necessarily disagree.  I've always been a bit of a libertarian, and believe it is okay for others not to enable JavaScript, but then again, okay not to cater to their needs unless we benefit by doing so.

 

 

I moved it.  Your question had nothing to do with code, I assume.  You were asking a systematic question, in other words... application design.

 

No it didn't.  I never new hypothetical questions belonged somewhere else.  Good to know!

Then there are those not using JavaScript.  To hell with them.  Unless you're just meandering your way through the dirtiest alleyways of the intertubes, there is no reason to keep Javascript disabled.  For them, I would just set the session expiry time to something small.  Log them out.  Make their experience miserable.

 

Are you drunk? I hope so.

:intoxicated: Why would you hope so?

 

Because a programmer who proudly announces that he punishes users who care about their security and privacy is either drunk or out of his mind. I was hoping for the former.

 

Well, or maybe you simply have no idea why people choose to restrict script execution. So let me try to explain.

 

As much as we like to think of web applications as great pieces of software, they rarely are. Many developers have never heard of basic security features like escaping. And even the ones who do understand the concept still don't always get it right. As if that wasn't bad enough, site owners also love to clutter their pages with questionable tracking snippets, fishy third-party ads and plain nonsense.

 

You don't have to go to “the dirtiest alleyways of the intertubes” to realize this. Just read a few threads on this forum. Or some code on GitHub. Or the security announcements of your favorite framework. Or the CVE. The top vulnerability right next to SQL injections is cross-site scripting.

 

It's the right of every user to protect themselves against this with tools like NoScript. Sure, not everybody exercises this right, because they aren't aware of the problem, or maybe they just don't care. That's OK. But users who do value their security and privacy deserve respect.

 

Does that mean we can never use JavaScript again? Of course not. If it's required for a certain feature, go ahead. Most script blockers allow the user to whitelist specific scripts. But enforcing JavaScript only to punish security-oriented clients and “make their experience miserable” (WTF?) is incredibly ignorant and says a lot about the general attitude towards users.

Edited by Jacques1

There are also several plugins that more people are aware of than

If you like to make big, exaggerated statements, then don't complain about getting a response.

 

I actually did believe you were having a blackout, because you're usually smarter than that. And indeed your revised opinion sounds a lot more like you. So now it boils down to “too much effort for too few users”? Well, in this specific case (I'm not interested in hypothetical situations), we're talking about one if statement. That should be doable.

 

I have to idea what the reference to HealthCare.gov is supposed to tell us. While I don't have first hand experience, it seems the whole project was a disaster. Is that an argument for their JavaScript policy? Is it the new standard of web programming. I don't think so.

Was just pointing out that it isn't uncommon for websites to block users with Javascript disabled.  I provided the healthcare site because it is a government website; a site that should be accessible by all, on anything.  Especially for $6M. 

@Zane  Don't give in!  We must remain united against the non-JavaScript infidels!  In my father's day and his father before him, they new how do deal with these people.  We must give them what they deserve, make their experience as bad as possible, and purge their existence once and for all!

  • Like 1

Especially for $6M. 

 

Um, no. The figure was $600MM. But, it is now at $840MM. (http://www.cbsnews.com/news/healthcare-gov-has-already-cost-840-million-report/)

 

It is things like this that really piss me off as a tax payer. The $6MM figure you quoted would still have been more than adequate to build what they ended up with.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.