I've searched google intensely on this topic and it seems noone really knows how to approch this.
The goal I don't want clients to give out their usernames and passwords to friends, since the site
relies on subscrption fees.
Sessions ID's are matched between the browser and the server. So a users can login with same
username and password and those sessions are tracked individually.
Some suggest create table fields with the session ID and a time stamp. However my clients can spend
alot of time on a page and I don't want to force them to re-login, would be annoying.
On the other hand, some clients do not logout properly and sessions open active and/or a script that
runs the timestamp does not clear that field. Then the next they login the stamp reads that they are
active and will not allow them to login.
I'm an experienced PHP programmer yet this task has got me going in circles. Everytime I think I
have a method worked out - there is a reason why it won't.
The approach I'm considering now is to grab and loop all the server sessions username values - then
compare those values to a flaged "logged-in" field from the user table. That way if a flag is
negative I will allow the user to login in and create a session and flag that field. If a session
does not exist then the flag is cleared. I would run the cron 10 minute intervals. If I find 2
sessions with same username I unset both - then fire off an email to the client reminding them
multiple logins are a bad thing
Does this sound right? Anyone else have a better idea?
18  3348 
Gleep wrote: Some suggest create table fields with the session ID and a time stamp. However my clients can spend
alot of time on a page and I don't want to force them to re-login, would be annoying.
Sun Microsystems' webpage uses a popup with "your sessions is about
to expire, extend it?". Then you have a couple of minutes to click
"extend" to keep your session alive. If you don't, the session
eventually times out. Perhaps that's one way to go.
If i got it right, what you want is to do that if users dont update
their session e.g. in 20 minutes, the session will be terminated. But
if the session exists in the database, you will simply disalow any
other sessions with the same username, right?
Simply, run cron for each 5 minutes to execute the php script that
would check everything. When user logins and each time they erquest the
server, update the mysql table saying time() + 60*10 ( 10 minutes ).
So if the script that is being executed by cron finds that the
expiration time has ended, the session is destroyed!
They wouldnt need that expiration mesage because the expiration time
would be automatically updates ( + 10 minutes for each request )
Also, there is a big disadvantage in all of this - users can have their
cookies disabled and then you'd get a big amount of sessions created in
your database... so you'd be dead because of that.
Just when users are logging in, in the login page set a cookie
$_COOKIE['do_login'] = true; and when user requests the actual login
page, where all the info is sent - the $_COOKIE['do_login'] should be
checked. If it is not, then simply say that Cookies must be enabled! :)
I might have confused anyone who is reading but figure it out then!
Good luck on your site!
Thanks!
Gleep wrote: I've searched google intensely on this topic and it seems noone really knows how to approch this.
The goal I don't want clients to give out their usernames and passwords to friends, since the site
relies on subscrption fees.
Sessions ID's are matched between the browser and the server. So a users can login with same
username and password and those sessions are tracked individually.
Some suggest create table fields with the session ID and a time stamp. However my clients can spend
alot of time on a page and I don't want to force them to re-login, would be annoying.
On the other hand, some clients do not logout properly and sessions open active and/or a script that
runs the timestamp does not clear that field. Then the next they login the stamp reads that they are
active and will not allow them to login.
I'm an experienced PHP programmer yet this task has got me going in circles. Everytime I think I
have a method worked out - there is a reason why it won't.
The approach I'm considering now is to grab and loop all the server sessions username values - then
compare those values to a flaged "logged-in" field from the user table. That way if a flag is
negative I will allow the user to login in and create a session and flag that field. If a session
does not exist then the flag is cleared. I would run the cron 10 minute intervals. If I find 2
sessions with same username I unset both - then fire off an email to the client reminding them
multiple logins are a bad thing
Does this sound right? Anyone else have a better idea?
Sorry, the email doesn't sound good to me. This would confront the
client with a 'flaw' in the system. I don't have a solution for your
problem, but this solution doesn't solve it, only moves is around. The
user might even not know there are multiple logins ...
Prevent multiple logins on 1 account by not letting more then 1 login.
How about setting a fla in the DB -> userid, session id, and timeasking
them if they want to stay logged in. If no-one answers the popup,
refresh the page at e.g. 15 minutes.
If they do reply reset the flag's timestamp.
If a timeout is after 15 minutes, and user is logged in, but closes the
browser without logging out, the account would be max. 15 minutes
unavailable for the same user. You *could* remind the user (on next
login e.g.) that leaving without logging out is a bad thing ...
Frizzle.
How about scenario like this ..
If user A is login into the system, the database write the use log,
userid, timestamp, blah blah ... and the when user B login with the
same account the system automatically do the logout action for the user
A and tell him what's happened (like "dude, some other user is logging
with your same account") ... then we give the user chance to re-login
and kick user B plus protect user A from kicking ...
Humm ... my english is suck ... I can't give clear explanation ... but
I hope you get the idea ...
About cron, I think that wasn't bad idea ... user should know about the
session expiration in the Term of Service. If they agree with that ...
I think it is OK ... plus, we owned the site and what we do is simply
to protect them, right ...
since preventing 2 or more people to login as a same user is practicaly
mission impossible (since, for instance, i can login to your web from
home or from work, thus having 2 different login locations), i think the
best idea is to force users to logout after the're done browsing, or you
could logout them when they leave the page (onunload event, or
something like that), thus, making it impossible for another person to
login as the user that's already logged in.
I know this is not a revolutionary idea, but I hope it helps You...
alvonsius wrote: How about scenario like this ..
If user A is login into the system, the database write the use log,
userid, timestamp, blah blah ... and the when user B login with the
same account the system automatically do the logout action for the user
A and tell him what's happened (like "dude, some other user is logging
with your same account") ... then we give the user chance to re-login
and kick user B plus protect user A from kicking ...
Humm ... my english is suck ... I can't give clear explanation ... but
I hope you get the idea ...
About cron, I think that wasn't bad idea ... user should know about the
session expiration in the Term of Service. If they agree with that ...
I think it is OK ... plus, we owned the site and what we do is simply
to protect them, right ...
Why not prevent user B from logging in, and not kicking user A?
If i were user A, i wouldn't like being kicked for someone else's
"hacking" attempts.
That's not my problem ...
"frizzle" <ph********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com... alvonsius wrote: How about scenario like this ..
If user A is login into the system, the database write the use log,
userid, timestamp, blah blah ... and the when user B login with the
same account the system automatically do the logout action for the user
A and tell him what's happened (like "dude, some other user is logging
with your same account") ... then we give the user chance to re-login
and kick user B plus protect user A from kicking ...
Humm ... my english is suck ... I can't give clear explanation ... but
I hope you get the idea ...
About cron, I think that wasn't bad idea ... user should know about the
session expiration in the Term of Service. If they agree with that ...
I think it is OK ... plus, we owned the site and what we do is simply
to protect them, right ...
Why not prevent user B from logging in, and not kicking user A?
If i were user A, i wouldn't like being kicked for someone else's
"hacking" attempts.
That's not my problem ...
Exactly - give the user a way to contact the site admin if they believe the
locking-out is incorrect. That way it can be sorted without a
logging-in-war :)
dave
alvonsius wrote: How about scenario like this ..
If user A is login into the system, the database write the use log,
userid, timestamp, blah blah ... and the when user B login with the
same account the system automatically do the logout action for the user
A and tell him what's happened (like "dude, some other user is logging
with your same account") ... then we give the user chance to re-login
and kick user B plus protect user A from kicking ...
Humm ... my english is suck ... I can't give clear explanation ... but
I hope you get the idea ...
About cron, I think that wasn't bad idea ... user should know about the
session expiration in the Term of Service. If they agree with that ...
I think it is OK ... plus, we owned the site and what we do is simply
to protect them, right ...
Actually, I like this way a lot better than refusing to log user B in.
One of the distributors I use for another business does something
similar. If I log in from a second computer (or a different browser),
it logs the first session off. Simple and painless. I can't have two
sessions going at the same time, and I'm not restricted for a period of
time because I didn't log off previously.
I can see another advantage to this, also. You can't stop User "A" from
giving his password to User "B". However, if "B" knocks "A" off enough
times, "A" will change his PW and not give it to "B".
As for being logged off due to a hack - well, if you use any reasonable
password, most likely that won't happen. Remember - it's a successful
login which logs the person off - an unsuccessful login won't do it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Carved in mystic runes upon the very living rock, the last words of
frizzle of comp.lang.php make plain: alvonsius wrote: How about scenario like this ..
If user A is login into the system, the database write the use log,
userid, timestamp, blah blah ... and the when user B login with the
same account the system automatically do the logout action for the
user A and tell him what's happened (like "dude, some other user is
logging with your same account") ... then we give the user chance to
re-login and kick user B plus protect user A from kicking ...
Humm ... my english is suck ... I can't give clear explanation ...
but I hope you get the idea ...
About cron, I think that wasn't bad idea ... user should know about
the session expiration in the Term of Service. If they agree with
that ... I think it is OK ... plus, we owned the site and what we do
is simply to protect them, right ...
Why not prevent user B from logging in, and not kicking user A?
What happens if user A goes to the library, logs in to the site, forgets
to log out, and now wants to log in at home?
--
Alan Little
Phorm PHP Form Processor http://www.phorm.com/
Carved in mystic runes upon the very living rock, the last words of
Gleep of comp.lang.php make plain: I've searched google intensely on this topic and it seems noone really
knows how to approch this.
The goal I don't want clients to give out their usernames and
passwords to friends, since the site relies on subscrption fees.
Add a META refresh or JS refresh to all the pages. When the page refreshes,
refresh the session. The person can sit there as long as they like; if they
leave the site and don't log out, the session eventually expires.
--
Alan Little
Phorm PHP Form Processor http://www.phorm.com/
>Some suggest create table fields with the session ID and a time stamp. However my clients can spend
alot of time on a page and I don't want to force them to re-login, would
be annoying.
On the other hand, some clients do not logout properly and sessions open
active and/or a script that
runs the timestamp does not clear that field. Then the next they login
the stamp reads that they are
active and will not allow them to login.
My suggestion is to keep a database of active sessions. (user name,
session id, timestamp). Well, actually, I'm not sure you really
need the timestamp. If a user logs in, delete all the previous
session records with his user ID and create a new record with his
session ID. When a user tries to access a page, check for the
session record by session ID. If it's not there, redirect him to
the login page. In other words, if the user tries to log in twice,
blow away the *OLD* session(s), so if someone tries to continue
using them, they have to log in again. If the user explicity logs
out, blow away all the session records with his user id.
If the user did not log out properly, this will do no damage, since
he won't use that session ID again. If there are two (or more)
users sharing a login and trying to use it simultaneously, they
will keep bumping each other off. You don't prohibit multiple users
but you make account sharing a real nuisance. It gets even worse
with a dozen users trying to share an account.
I'm an experienced PHP programmer yet this task has got me going
in >circles. Everytime I think I >have a method worked out - there
is a reason why it won't.
You can also use the approach of detecting multiple logins (timestamp
needed here for telling the difference between an abandoned session
and multiple users) and if there are too many too quickly, send a
nasty email. Realize that this might false-trip occasionally so
you only send email if it happens several times in a few days. Oh,
yes, tracking IP addresses might be useful as evidence in case the
user denies sharing his account. Perhaps his password was stolen
(by a family member he shares the computer with?)
Gordon L. Burditt
Gordon Thanks for your tip about tracking the sessions in a db. I did consider that but I wanted to
avoid tracking them with table queries.
Here is what I came up with.....
First I wanted to say thanks to everyone writing in help me with this. I came up with this solution
and it works well I think.
The trick to this situation is collecting current session data and comparing against a client who is
trying to login. Note the goal: I want to prevent clients from sharing thier usernames and
passwords with others since this is a subscription based system.
On the login form, I do the standard thing (query) to see is the username exists and if the password
is correct, blah blah we've all done that a million times. But BEFORE I register a session
"validUser" with thier username - I first loop through existing sessions and see if there is a
match. This is how
$OKtoLogin = true;
$handle = opendir(session_save_path());
while (($file = readdir($handle)) != false) {
if( $file != "." && $file != ".." ) {
$filename= session_save_path()."/".$file;
$fp = @fopen($filename, "r");
$contents = fread($fp, filesize($filename));
if(strstr($contents, $userName)){
// if true then there is multiple login attempt, at this point I
// can send them to a login fail page or email them with note
$OKtoLogin = false;
}
fclose($fp);
}
}
if($OKtoLogin){
// at this point it passes validation
// here i would register thier session and pass them into application
}
Note: occationally some sessions stick around for whatever reason and I would have a cron set up at
3:00am that wipes out all sessions with unset() and session_destroy()
It seems simple now, but this took me hours and hour to figure out. It just reads in all the
existing session files, reads the contents of the session, compares it against the posted value
username (which will always be unique new user will not be able have the same username) if there is
a match then I know it's a multiple login attempt and it fails. If there are no matches everything
is cool and they login normally.
I don't have to track timestamps and SID in tables and run quiers to see if flags have been set and
all that jazz. I hope that this code snip will help someone else solve this issue with preventing
multiple logins.
On Thu, 09 Feb 2006 18:52:08 -0000, go***********@burditt.org (Gordon Burditt) wrote: Some suggest create table fields with the session ID and a time stamp.
However my clients can spend
alot of time on a page and I don't want to force them to re-login, would
be annoying.
On the other hand, some clients do not logout properly and sessions open
active and/or a script that
runs the timestamp does not clear that field. Then the next they login
the stamp reads that they are
active and will not allow them to login.
My suggestion is to keep a database of active sessions. (user name,
session id, timestamp). Well, actually, I'm not sure you really
need the timestamp. If a user logs in, delete all the previous
session records with his user ID and create a new record with his
session ID. When a user tries to access a page, check for the
session record by session ID. If it's not there, redirect him to
the login page. In other words, if the user tries to log in twice,
blow away the *OLD* session(s), so if someone tries to continue
using them, they have to log in again. If the user explicity logs
out, blow away all the session records with his user id.
If the user did not log out properly, this will do no damage, since
he won't use that session ID again. If there are two (or more)
users sharing a login and trying to use it simultaneously, they
will keep bumping each other off. You don't prohibit multiple users
but you make account sharing a real nuisance. It gets even worse
with a dozen users trying to share an account.
I'm an experienced PHP programmer yet this task has got me going
in >circles. Everytime I think I >have a method worked out - there
is a reason why it won't.
You can also use the approach of detecting multiple logins (timestamp
needed here for telling the difference between an abandoned session
and multiple users) and if there are too many too quickly, send a
nasty email. Realize that this might false-trip occasionally so
you only send email if it happens several times in a few days. Oh,
yes, tracking IP addresses might be useful as evidence in case the
user denies sharing his account. Perhaps his password was stolen
(by a family member he shares the computer with?)
Gordon L. Burditt
I think gordon is onto a better solution.
Store the current session id and remote ip address in the database. ip
address also because they could simply modify the session id being
sent.
Additionally, there should only be *one* record per user account,
session id, and remote ip address, ie: unique sid, unique uid, and
unique uid-sid-ip. ip isn't unique unless you want to block different
accounts behind a shared internet connection.
Looping through every session, opening it, and searching for a
substring will take much longer than simply comparing two strings and
destroying a session.
Process:
On user login, destroy the previous session if the old session id
doesn't match the current session id or if the current ip doesn't match
the older ip.
Otherwise, store the new session ID and remote ip address for that
user.
If the user doesn't have a record, create it and allow the login.
Keep track of the last login time, too. If there are requests from
multiple IP's with the same account in a short period of time, then you
can lock the account, send them an email, alert your staff, you know,
raise a red flag of some sort.
This will allow a single user to have multiple windows open for the
website (assuming they 'open link in new window/tab') as the session
id's sent by all those windows will be the same.
It won't prevent sharing of an account if there is a home
gateway/router. But really, if thats the case, they can (and probably
would anyways) share the file over the local network. Either way, they
are still using the same connection and will be fighting for bandwidth.
in code, ala;
$oldid, $oldip = select sessionid, ip from table where user=$user
if($sid != $oldid || $ip != $oldip) {
destroy_session($oldid);
destroy_session($sid);
logout($user);
// do time calculation to flag shared accounts
gotoLogin();
} else {
// proceed with login
}
"Alan Little" <al**@n-o-s-p-a-m-phorm.com> wrote in message
news:Xn**************************@216.196.97.131.. . Carved in mystic runes upon the very living rock, the last words of
Gleep of comp.lang.php make plain:
I've searched google intensely on this topic and it seems noone really
knows how to approch this.
The goal I don't want clients to give out their usernames and
passwords to friends, since the site relies on subscrption fees.
Add a META refresh or JS refresh to all the pages. When the page
refreshes,
refresh the session. The person can sit there as long as they like; if
they
leave the site and don't log out, the session eventually expires.
that makes me shudder almost.
--
Alan Little
Phorm PHP Form Processor
http://www.phorm.com/
"Gleep" <Gl***@Gleep.com> wrote in message
news:9v********************************@4ax.com... I've searched google intensely on this topic and it seems noone really
knows how to approch this.
The goal I don't want clients to give out their usernames and passwords to
friends, since the site
relies on subscrption fees.
Sessions ID's are matched between the browser and the server. So a users
can login with same
username and password and those sessions are tracked individually.
Some suggest create table fields with the session ID and a time stamp.
However my clients can spend
alot of time on a page and I don't want to force them to re-login, would
be annoying.
On the other hand, some clients do not logout properly and sessions open
active and/or a script that
runs the timestamp does not clear that field. Then the next they login the
stamp reads that they are
active and will not allow them to login.
I'm an experienced PHP programmer yet this task has got me going in
circles. Everytime I think I
have a method worked out - there is a reason why it won't.
The approach I'm considering now is to grab and loop all the server
sessions username values - then
compare those values to a flaged "logged-in" field from the user table.
That way if a flag is
negative I will allow the user to login in and create a session and flag
that field. If a session
does not exist then the flag is cleared. I would run the cron 10 minute
intervals. If I find 2
sessions with same username I unset both - then fire off an email to the
client reminding them
multiple logins are a bad thing
Does this sound right? Anyone else have a better idea?
one idea is to get the IP address of the browser. that can help some in
loggin the attempt. but pyou're probably going to have to attach the login
attempt info along with the login info table. things like maybe IP address,
timestamp of successful login. update the timestamp upon every use of a
page. (timestamp is suggestion from an earlier post)
problem. you can have multiple browsers open on the same desktop. one IP
address. multiple logins. opening another browser (one with session, one
without) could cause a ruckus with your code if you don't handle it, but it
could be an indicator of a new browser and how to handle it is up to you)
drawback to using IP address: dialup users get disconnected a lot and have
to change addresses.
IP addresses behind a proxy/firewall on some ISPs will appear to be the same
for all of their users.
Carved in mystic runes upon the very living rock, the last words of Jim
Michaels of comp.lang.php make plain: "Alan Little" <al**@n-o-s-p-a-m-phorm.com> wrote in message
news:Xn**************************@216.196.97.131.. .
Carved in mystic runes upon the very living rock, the last words of
Gleep of comp.lang.php make plain:
I've searched google intensely on this topic and it seems noone
really knows how to approch this.
The goal I don't want clients to give out their usernames and
passwords to friends, since the site relies on subscrption fees.
Add a META refresh or JS refresh to all the pages. When the page
refreshes, refresh the session. The person can sit there as long as
they like; if they leave the site and don't log out, the session
eventually expires.
that makes me shudder almost.
OK; I admit I'm not the greatest on security. Could you elaborate?
--
Alan Little
Phorm PHP Form Processor http://www.phorm.com/
Carved in mystic runes upon the very living rock, the last words of Jim
Michaels of comp.lang.php make plain: drawback to using IP address: dialup users get disconnected a lot and
have to change addresses. IP addresses behind a proxy/firewall on some
ISPs will appear to be the same for all of their users.
And some ISPs still use different IPs per request. I know AOL used to do
that; I don't know if they still do, but I know there are some, as I
occasionally run into problems with it.
--
Alan Little
Phorm PHP Form Processor http://www.phorm.com/
Jim Michaels wrote:
one idea is to get the IP address of the browser. that can help some in
loggin the attempt. but pyou're probably going to have to attach the login
attempt info along with the login info table. things like maybe IP address,
timestamp of successful login. update the timestamp upon every use of a
page. (timestamp is suggestion from an earlier post)
problem. you can have multiple browsers open on the same desktop. one IP
address. multiple logins. opening another browser (one with session, one
without) could cause a ruckus with your code if you don't handle it, but it
could be an indicator of a new browser and how to handle it is up to you)
drawback to using IP address: dialup users get disconnected a lot and have
to change addresses.
IP addresses behind a proxy/firewall on some ISPs will appear to be the same
for all of their users.
Another drawback - some companies use multiple proxies, and the same
user may come in with different IP addresses - even if they aren't dialup.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chris Hall |
last post by:
Hello,
Any one got any good ideas or where to look for solutions how to stop
multiple log ins with the same username? I am using mysql database if that
makes a difference.
Cheers
Chris...
|
by: John Davis |
last post by:
I put a little login (username and password textfields) in a web page, and
once the user able to login, I want the username and password textfields
will disappear, and replace with text " has...
|
by: Robert Mens |
last post by:
Hi,
My compiler/linker gives me the strangest error:
process.o(.text+0x0): In function `login_user_login':
: multiple definition of `login_user_login'
login.o(.text+0x0): first defined here...
|
by: Conformix Sales |
last post by:
Any thought about how can I stop a user from logging into the application
multiple times. I am using forms authentication.
|
by: thomson |
last post by:
Hi All,
i do hae a solution in which i do have mulitple projects
including Web Projects,, Depending on the functionality it gets
redirected to different web projects and it is working fine,
...
|
by: Bhavini |
last post by:
Hi All,
I have to prevent multiple logins for the same user accessing at same time.
i.e. if xyz user is active, no other login should be allowed for the same
user ID.
I thought of saving...
|
by: dylanhughes |
last post by:
I'm looking for an example of a login system that has multiple fields
(2 to be exact) + password. e.g username, company name and password,
the user, company and password are checked against a mysql...
|
by: shankhar |
last post by:
Hi all,
In my project there is a requirement. If a user logged in at a time
since he/she logged out others are not allowed to loggin using the
same user name. That is to avoid multiple logins...
|
by: Fareast Adam |
last post by:
I want to make sure all users those login are different in a time either on the same or different computer or web browser. Following are sample of my program which consist 4 different pages;
...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
