PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
Hello,
I need to set a cookie with an ID value (I have user system, each user have unique ID) for each user that log into the system.
but, im afraid that people will change their value to other id and will log into other people account, here an example :
<?php
#check the cookie
if(!isset($_COOKIEїid]))
die("only for members !!!! please login");
#get the user data
$user_data = mysql_query("SELECT * FROM users WHERE id='$_COOKIEїid]'");
?>
the problem is that when a hacker will see this, he will change the cookie value to something else and will log into other people account
Can I somehow encrypte cookies so people wont be able to change their content ?
<?php
srand((double)microtime()*1000000);
$id_cookie = md5(rand(0,9999999));
# $id_unique is the unique id for each user from the databse
if( login info is OK )
{
setcookie("$id_cookie","$id_unique",time()+3600,"/",$SERVER_NAME);
}
?>
Now, is it safe ? I want to do something like this :
why do you have to do this at all?
after a user logged in with name/password you can read the ID from the database and store it in $_SESSION.
If you want to achieve a 'long-term' login (until the user manually logs out) you may store a login-id for a user in the database. This login-id has to be generated when a user logged in, sent as cookie and erased from the database when the user logged out.
Whenever you do a login check, check against the session data and the cookie data to be valid. Only if both fail deny access.
I think it's no good to store vital, long-term data (like the user id) crypted/hashed or not on the client side.
You should have the encrpted ID in the database then have the un-encripted ID stored in the cookie.
Ok, thanx...
why do you have to do this at all?
after a user logged in with name/password you can read the ID from the database and store it in $_SESSION.
If you want to achieve a 'long-term' login (until the user manually logs out) you may store a login-id for a user in the database. This login-id has to be generated when a user logged in, sent as cookie and erased from the database when the user logged out.
Whenever you do a login check, check against the session data and the cookie data to be valid. Only if both fail deny access.
I think it's no good to store vital, long-term data (like the user id) crypted/hashed or not on the client side.
Sessions is bad ! why ?
read this :
Hello,
I have very wierd problem :
I use session to manage users and I have this structure of the page :
-----
include("db.php");
include("header.php");
bla bla
include("footer.php");
-----
in the db.php I have :
----
session_start();
#some mysql connect stuff
----
I use session with the $_SESSION array (cheking if registered[isset($_S...)]
and registering...)
and all work fine....
but sometimes the page loading is very very very slow (and its a really
really fast host) and when I removing session_start(); from the top of the
page, the page load normaly.
the PHP version is 4.1.1, someone have an idea ?
thanks in advance,
Dima.
this was sent to the PHP mail list, people tried to help but no one solve the problem
hmmm...perhaps because no one else experienced the problem?
it slows down a bit if you set session.save_path = /dev/fd0
ok ok, then forget about the session - it's unnecessary. Use the cookie data and reject access if the login-id is unset or unequal to the id in the database.
Probably we're speaking about the same thing but I just wanted to emphasize that the field 'id' in the database should be volatile if it is the only mechanism for login purposes.
Think about it (at least twice) before you store login data that never changes client-side.
fatal wrote:You should have the encrpted ID in the database then have the un-encripted ID stored in the cookie.
Would it not be the other way round? Lets say a user has a simple ID of '212' and this was stored in a cookie a hacker could easily change his cookie ID from say '211' to '212' and would have access to that users records. If stored in the cookie as an encrypted ID it may look something like '$hf8*7623!4' or whatever, the hacker without knowing how this was created would have a more difficult time trying to change it.
So..
Encrypted ID in the cookie and un-encrypted ID in the database, get the users cookie, decrypt it and compare against the database, that would be my guess.
OK, thank you all people !!
someone replied me in the mail list, here is the solution for the session problem
Hi
PHP's sessions are blocking, i.e. until a session is closed, all other calls to
session_start() are pending. If you don't close a session explicitely, it
remains opened until the script is terminated.
The solution is to close a session as soon as possible (session_write_close) or
use non-blocking read-only sessions (session_readonly instead of session_start)
in case you don't need to modify registered variables.