PHP cookies
by William Finlayson · in Technical Issues · 04/29/2001 (6:53 pm) · 6 replies
Seeing as this site seems to be coded in PHP there should be a high probability that someonoe knows about it :)
I am trying to use cookie to store a user's username after logging on. It will be used to check permissions for subsequent pages etc. I have been having problems with this. I'm not all together sure how to read from cookies. In the manual it says that cookies are automatically read into variables as soon as a scripts is run, but I'm not quite sure about it all. I know I'm not providing a lot of information, but I's just general info I need really:
-how to write a cookie (not sure if I'm doing it right cos I don't know how to read them :)
-reading from cookies.
At the moment I just need to be able to store a username in a cookie, and then retrive it.
I am trying to use cookie to store a user's username after logging on. It will be used to check permissions for subsequent pages etc. I have been having problems with this. I'm not all together sure how to read from cookies. In the manual it says that cookies are automatically read into variables as soon as a scripts is run, but I'm not quite sure about it all. I know I'm not providing a lot of information, but I's just general info I need really:
-how to write a cookie (not sure if I'm doing it right cos I don't know how to read them :)
-reading from cookies.
At the moment I just need to be able to store a username in a cookie, and then retrive it.
About the author
#2
I have just heard the same things from one of my friends today :) and I've decided to try to do all the user authentification on the server. I'm still interested in cookies though, because I could have an option to use cookies if user's want to.
04/30/2001 (9:58 am)
Thanx for the advice.I have just heard the same things from one of my friends today :) and I've decided to try to do all the user authentification on the server. I'm still interested in cookies though, because I could have an option to use cookies if user's want to.
#3
myInfo[0] --> variable in the cookie and the php var
mydata ----> data you want to store in the cookie
(note: this must be called before any HTML is processed)
setcookie("myInfo[0]",$mydata);
the php var to get the cookie value is $myInfo[0]
Example:
setcookie("myPage","Welcome to my Page");
?>
(on another page)
print $myPage;
-Tim
04/30/2001 (9:26 pm)
To set a cookie do the following.myInfo[0] --> variable in the cookie and the php var
mydata ----> data you want to store in the cookie
(note: this must be called before any HTML is processed)
setcookie("myInfo[0]",$mydata);
the php var to get the cookie value is $myInfo[0]
Example:
setcookie("myPage","Welcome to my Page");
?>
(on another page)
print $myPage;
-Tim
#4
Okay, before you jump on my back.. If you store personal or access data directly in a cookie you are just asking for trouble. That is not a good way to program. Let me show you the model I use for doing cookies.
Cookie->id->15595356263567812
The end is just a 16 slot reference id. It can be dynamically generated from anywhere and anyway you want to handle it. I usually do a random var generate and take what it returns. It should also be noted that i never allow a cookie to exist longer than 3 hours in my system. Okay now on to the explanation.
The first 4 numbers are the actual id of the client in the database. The next 3 usually pertain to table ids that are dynamically generated at the time the cookie is set. This serves two purposes. I can see how many unique clients are generated in a day, as well as hiding the table names preventing a haxor from accessing my database. (Now this is not a perfect system. I am sure that a really dedicated haxor could easily figure out in the end, but hey, it is good for not being an HTTPS setup.)
So basically i have a piece of code that creates 3 seperate entries into a table setup something like below:
table codex,
client_id int(4) not null,
table_id int(4) not null,
table_name varchar(20) not null,
time_entered timestamp,
primary key (table_id)
and in my code I just use the table_id everytime I use a call to the database so I don't ever reveal where the info is stored. I have also gone as far as one time using the same process to create tables with the ids that were then dropped from the db after 3 hours, but that always seemed a little extreme.
As for verifying the 3 hours, the info is removed from the database when the 3 hour limit expires, whether or not the cookie does.
You can always come up with your own system, but just don't ever be afraid to use cookies. There is nothing more irritating the user than to have to constantly re-enter their login information if they left the site only briefly.
Anyways I will step down from my soapbox now. Continue...
Judd Pickell
ePAGE Productions
http://www.deckersds.com/epage
05/06/2001 (1:40 pm)
I would like to respond to the security issue with cookies. I personally love using cookies for storing any and all temporary data. The key is knowing how to communicate the data. Okay, before you jump on my back.. If you store personal or access data directly in a cookie you are just asking for trouble. That is not a good way to program. Let me show you the model I use for doing cookies.
Cookie->id->15595356263567812
The end is just a 16 slot reference id. It can be dynamically generated from anywhere and anyway you want to handle it. I usually do a random var generate and take what it returns. It should also be noted that i never allow a cookie to exist longer than 3 hours in my system. Okay now on to the explanation.
The first 4 numbers are the actual id of the client in the database. The next 3 usually pertain to table ids that are dynamically generated at the time the cookie is set. This serves two purposes. I can see how many unique clients are generated in a day, as well as hiding the table names preventing a haxor from accessing my database. (Now this is not a perfect system. I am sure that a really dedicated haxor could easily figure out in the end, but hey, it is good for not being an HTTPS setup.)
So basically i have a piece of code that creates 3 seperate entries into a table setup something like below:
table codex,
client_id int(4) not null,
table_id int(4) not null,
table_name varchar(20) not null,
time_entered timestamp,
primary key (table_id)
and in my code I just use the table_id everytime I use a call to the database so I don't ever reveal where the info is stored. I have also gone as far as one time using the same process to create tables with the ids that were then dropped from the db after 3 hours, but that always seemed a little extreme.
As for verifying the 3 hours, the info is removed from the database when the 3 hour limit expires, whether or not the cookie does.
You can always come up with your own system, but just don't ever be afraid to use cookies. There is nothing more irritating the user than to have to constantly re-enter their login information if they left the site only briefly.
Anyways I will step down from my soapbox now. Continue...
Judd Pickell
ePAGE Productions
http://www.deckersds.com/epage
#5
That's a pretty good system. However it still does not work if cookies are disabled. My primary machine has cookies disabled, but leaves session-cookies available. This seems to break the fewest sites overall.
Still, it is incredibly anoying to go to a site, log into it, then have it (one page later) say that I'm not loged in. If a site uses cookies to enable logins, they should also use a method to fallback on (either by not using cookies, or https).
The way to do it without cookies is by appending to the URL. Thus if your site was www.fractalscape.org and logged in, you could get to the page "Test" by going to the URL "www.fractalscape.org/Test?id=15595356263567812".
This is terribly unsecure overall, but it does work in a no-cookie environment. And, I would argue that this method is not any less-secure than cookies.
I guess it comes down to site security anyway, I'm not going to do a buisness transaction on a site that uses cookies or URLs for login security, if they don't at least use HTTPS I'll be taking my money elsewhere.
--Bryan
05/06/2001 (5:30 pm)
Judd,That's a pretty good system. However it still does not work if cookies are disabled. My primary machine has cookies disabled, but leaves session-cookies available. This seems to break the fewest sites overall.
Still, it is incredibly anoying to go to a site, log into it, then have it (one page later) say that I'm not loged in. If a site uses cookies to enable logins, they should also use a method to fallback on (either by not using cookies, or https).
The way to do it without cookies is by appending to the URL. Thus if your site was www.fractalscape.org and logged in, you could get to the page "Test" by going to the URL "www.fractalscape.org/Test?id=15595356263567812".
This is terribly unsecure overall, but it does work in a no-cookie environment. And, I would argue that this method is not any less-secure than cookies.
I guess it comes down to site security anyway, I'm not going to do a buisness transaction on a site that uses cookies or URLs for login security, if they don't at least use HTTPS I'll be taking my money elsewhere.
--Bryan
#6
Judd
05/07/2001 (8:57 pm)
I agree with you whole heartedly Bryan. I was just relating to someone who was planning on using cookies. The truest security is a https server, but if you are only using the security on a admin piece not a selling piece the 175 dollar price tag may be a bit much. Anywho's good point about the url.Judd
Torque Owner Bryan Turner
Sorry that I'm not answering your question, but I want to warn you against using cookies for any form of security.
1) Anyone can add any cookie to their system.
2) Anyone can modify cookies from you.
3) It is technically possible to steal cookies from others.
4) Not everyone uses cookies (my main machine has cookies turned off).
If you need (real) security, go with HTTPS. Now on to your regularly-scheduled answers...
--Bryan