Forum Moderators: coopster
Among the users this isn't a problem at all, and takes a heck of a burden from you. BTW if this is a company people still would take over their colleagues seat and write something in their name, so don't worry.
I would really stick to the idea of the distinct user names.
Best regards
Michal Cibor
But if you really want, the user's IP is in $_SERVER['REMOTE_ADDR'] - add that to user table in your db (where you store username and hash of a password)
If you want to prevent users from handing out usernames and passwords you'll have to put something a little more dynamic in place. A suggestion would be to have a regularly changing 'token' that is supplied to the user via email. In order to login they must supply their username and their token. If it changes each week, and they hand out their username and token, then that will only be good for a little while before a new one is generated.
Another idea might be that the user is forced to enter personal information periodically. That will probably discourage most users from handing out login details as they'd have to supply their personal details as well.
One more idea... Use the user's email as the login name. If they are going to hand it out publicly then there they will likely receive a flood of spam as well.
It's likely to annoy users if it's too hard a system to use, but if there is a need to be concientious about access then a continuously changing login information, challenging the user or forcing the use of personal information in a login might be the way to go.
However I'm a student myself, and I know that if you put some restricted access, then still most of the people might take what you have there - simply save and then distribute.
You cannot make the page completely pirate proof.
Best regards
Michal Cibor
What about users on a network, their external ip will all be the same anyway.
what about AOL, there are far more users than there are ips.
even high speed users, sure their ips seldom change, but they still change.
auth by ip is just a bad idea, you will need other criteria and then unfortunately if people share their personal information then they share their information, not much you can do.
One thing ip is good for is to make sure a user doesn't switch ip's on an active session, if so, force them to re auth.
And thanks Jatar K. What you say it's true, because ip's restriction has many limitations and definetely could give some annoys to users, but what other ideas are possible? The MCibor's one is good and maybe there are a bit more. If people wants to share info after got it, nothing I can do, but what I would like -if it is possible with programming- is to avoid that the same user can revel his/her login user/password to many people with and continue normally login, he/she and the other people. Thanks for your ideas, and thanks a lot.-Percy
One thing ip is good for is to make sure a user doesn't switch ip's on an active session, if so, force them to re auth.How would that affect AOL users where one page can be requested by multiple IP Addresses?
mcibor: There may be a way - with assigning cookie, eg after user authentification by email. I mean: send user an email with a link, then while he's visiting the page set a cookie on his pc.
This is quite a good method, and I've made one myself that works pretty well. Initially, it's computer-specific because of the cookie, but the registered user could access the content from another computer by sending to it the original email and clicking the link again. Of course this doesn't prevent the registrant sending that same email to others, so an option is to limit the registration to a single computer and price accordingly, and if they want to access from another one you can provide a suitable routine.
In the end, anyone can mimic someone else.
1. User pays you the price, says his email, username (pass by user, or you generate - that doesn't matter).
2. Create db record with id, username, pass, email, authorisation code (may be a random number/ascii), ip
3. You send an email to that user with url to authorise (url has authorisation code and id)
4. When user clicks on the url you check the ip and if valid you create a 1year/more year cookie with authorisation code
5. On login you check the username, pass and authorisation code from cookie. If the cookie's missing, but the ip is correct you create it, otherwise you restrict access.
Hope this helps!
Michal Cibor
PS. This way if the ip changes, but the cookie is still there, there won't be problem of logging in.
I've used it more for banning members than validating members. And yes, AOL is still a problem, but at least I ban only a portion instead of the entire AOL block.
When a user starts a session I insert a row into the OnlineNow table in my database. When their session ends I delete the row. If anyone else tries to use the same account while it's already in the OnlineNow table I redirect them to a page with a message telling them only one session at a time is allowed.
As to setting the auth code to a cookie it's fairly simple:
<?php
//create a random number
function rnd_no($length)
{
$chars = "abcdefghijklmnopqrstuvwxyz";
$chars .= "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$chars .= "1234567890";$char_length = strlen($chars) - 1;
for($i = 0; $i < $length; $i++)
{
$pass .= $chars{rand(0, $char_length)};
}
return $pass;
}//authentization code here
if($authentic){
$authcode = rnd_no(20);//20 chars random auth code
setcookie("user", $user.":".$rndpass, time() + 60*60*24*365);//valid one year. In one cookie I store username and authcode, not just authcode
//connect to db (not earlier, because you may have problems with setting the cookie)
mysql_query("INSERT INTO users (user, pass, authcode) VALUES('$username', '".md5($password)."', $authcode)") or die(mysql_error());//never store plain password, only it's hash
}?>
