Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Session question

Posted by bschultz (bschultz), 12 June 2007
Hi.  I have a php script that authenticates users based on a MySQL database, and upon a successful login, will start a session to allow the access for certain pages.  Pretty straightforward, and working just fine.

My question is this:  is it possible to limit user1 from only being able to login once at a time...meaning user1 can't give their username and password to anyone and they both get access at the same time?



Posted by admin (Graham Ellis), 12 June 2007
Brian, the answer is both "yes" and "no".

You could set an extra cookie as the users starts his session and validate every page against that, retaining the cookie value in a database and then releasing it when he logs out.  That would stop concurrent users ... but it would also block people who forgot to log out on one system before transferring to another.

Better to set the cookie and note when it was last accessed, allowing a new user to connect after (say) 15 minutes of inactivity.   But the "no" part of my answer is that it's really impossible to know when someone has left if they've not logged out properly - you're waiting for a non-event.

Posted by bschultz (bschultz), 12 June 2007

There is no log-out function here...the session is active as long as the browser is open.  The session closes, and won't let you back in (unless you login once again) after closing the browser.  I should have been more clear there.

How would that change your answer?

Thanks again!  

Posted by admin (Graham Ellis), 13 June 2007
I would remove the "logout" part of my answer and rely on no activity from the (original) visitor for not the 15 minutes I suggested earlier but - say - 10 minutes. Without a logout function, you have to guess - you can't be sure how long the first visitor will still be watching but with no activity.

Posted by bschultz (bschultz), 13 June 2007
The problem is that this is for subscription access to an audio stream of a sporting event.  The game may take 3 1/2 hours.  The listener may be sitting on the page with the embedded player for that whole time.  I'm starting to think that this may not be possible for what I'm doing.

Thanks Graham!

Posted by admin (Graham Ellis), 13 June 2007
If you can check whether the audio feed is still going out to him / her, that will be a good solution.  If you can't, indeed, you have a problem

Posted by bschultz (bschultz), 13 June 2007
The streaming server (Icecast) writes listener in and listener out to a log file.  If I could grab the IP of the listener during the session start, and then read the log file for the connection closed for that IP, that might work.  But, how to read the log file, and search for the connection closed for that IP...I think that might just be impossible too!

There are professional sports leagues here in the US that offer audio streaming of games and they DO NOT have this authentication that I'm looking for...and now I think I know why.

Posted by admin (Graham Ellis), 14 June 2007
Yes, you may have the "why". Remember that IP addresses may NOT be unique; you get two visitors from the same student accommodation (for example) and they'll share an IP address as far as you are concerned, so even if you manage to track them down in the log file ...

((( But on thinking - it might not all be bad; if you allow a new authorisation because of an IP being closed out, the few failures could be right side ones - i.e. failures to stop unwanted accesses rather than failures to allow valid ones ))).  But a dangerous game - you could right a system that would REALLY put your customers off!

Posted by bschultz (bschultz), 14 June 2007
I was thinking along the same lines last night.  The streaming server has a "kick" feature to remove the stream from a listener.  I could authenticate based on username and write the IP as well to a separate DB as part of the session...then check the DB and "kick" the first listener when someone else logged in via that same username...the usernames would have to be the same to remove the listener...not the IP's.  

The IP's (along with a unique Icecast stream ID) are just used to issue the "kick" to the correct listener .

Now, I just need to figure out how to have PHP tell the streaming server to kick the first listener.

Thanks Graham!

This page is a thread posted to the opentalk forum at and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: • WEB: • SKYPE: wellho