Re: [PHP] Cookies sessions
On Thu, 21 Jan 2010 08:43:58 +1100, clanc...@cybec.com.au wrote: When you are working with sessions, provided you start your program with session_id(), you can then do anything you like with session variables at any point in your program. In my original question I asked if there was a cookie equivalent. The HTTP spec allows cookies to be sent after the content, in trailing headers, but it's not usable practically. Few browsers support it, and PHP certainly doesn't. You'd have to write a CGI to get away with it. The only user agents I know of that support trailers are the WC3 and WDG validators, and Opera(!). Trailer test: http://luden.se/http/test/trailer/ Some results: http://browsershots.org/http://luden.se/http/test/trailer/?p=63 /Nisse -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Mon, 2010-01-25 at 22:13 +0100, Nisse Engström wrote: On Thu, 21 Jan 2010 08:43:58 +1100, clanc...@cybec.com.au wrote: When you are working with sessions, provided you start your program with session_id(), you can then do anything you like with session variables at any point in your program. In my original question I asked if there was a cookie equivalent. The HTTP spec allows cookies to be sent after the content, in trailing headers, but it's not usable practically. Few browsers support it, and PHP certainly doesn't. You'd have to write a CGI to get away with it. The only user agents I know of that support trailers are the WC3 and WDG validators, and Opera(!). Trailer test: http://luden.se/http/test/trailer/ Some results: http://browsershots.org/http://luden.se/http/test/trailer/?p=63 /Nisse I didn't even know that that was possible. I'm glad in a way that the other browsers and PHP don't support it, as it would make a lot of things more difficult if not impossible to accomplish! Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Cookies sessions
On Mon, 25 Jan 2010 21:26:05 +, Ashley Sheridan wrote: On Mon, 2010-01-25 at 22:13 +0100, Nisse Engström wrote: The HTTP spec allows cookies to be sent after the content, in trailing headers, but it's not usable practically. Few browsers support it, and PHP certainly doesn't. You'd have to write a CGI to get away with it. The only user agents I know of that support trailers are the WC3 and WDG validators, and Opera(!). [...and one (and a half) of my own tools...] I didn't even know that that was possible. I'm glad in a way that the other browsers and PHP don't support it, as it would make a lot of things more difficult if not impossible to accomplish! What do you have in mind? It would certainly make Clancy's job easier. Imagine... ?php header (Trailer: Cookie); /* PHP takes notice! */ echo '!DOCTYPE HTML PUBLIC...and so on and so forth...'; setcookie (...); echo 'pSome more stuff...'; ? * If the program exits before the headers have been sent (eg. output buffering), PHP sends the headers as usual, with Content-Length: and Set-Cookie:, but skips the Trailer:. * If the headers have to be sent before the program has exited, PHP sends Content-Encoding: chunked and Trailer:, and buffers any further header() or setcookie() calls. When the program does exit, PHP sends all the buffered headers, and perhaps logs warnings for any headers that are not allowed in the trailers or has not been announced in the Trailer: header. Ah, it could have worked. It would have been great fun writing the code to do it. (Writing output filters that switch between Content-Length and chunked, and HTTP 1.0 and 1.1 was interesting). Actually, now that I think about it, I don't think I have actually tested the above in PHP. I'd be very surprised if it worked though. :-) /Nisse -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
clanc...@cybec.com.au wrote: On Sat, 23 Jan 2010 09:32:37 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au wrote: but I would be grateful for any suggestions how I could make this procedure more secure. We have given you advice that you should NOT use Cookies in any fashion to secure your site, but you remain steadfast that you know better -- so, what else can we say other than good luck. BUT you have told me to use sessions, and sessions use a Cookie! If the Cookie I use contains random data, the only difference in security is in the time that it remains valid. Neither contains any useful information, but while they are valid both will enable you to bypass security. Using only sessions means you have the tried and true php session handling to manage the cookie, rather than re-inventing the wheel yourself by using your own random string to do the same thing that a session cookie already does. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Sun, 24 Jan 2010 17:44:16 +1100, clanc...@cybec.com.au wrote: On Sat, 23 Jan 2010 15:10:11 +, nrix...@gmail.com (Nathan Rixham) wrote: To answer your specific questions though - what can be done to make this process more secure - no matter what approach you take, when working via http and needing logged in / secure functionality; you need the client to identify themselves with a key of some sort - no matter how you make the key it's always going to be passed via http (GET/POST/COOKIE) - if some hacker passes the same key then your system is going to think it's the original user and give them access. To make it trickier you can store information such as the users IP address, user agent string etc in session and compare it on each request; if it changes log the user out and destroy the session data - however your never going to protect against the most common form of hacking, a nosy co-worker / person in the same house having a nosey while the user is at the toilet / making a brew. This is why many sites re-request password confirmation for potentially sensitive actions like transferring money, changing personal details and so forth (and send email confirmations to tell the user what changed - just in case). It must be pointed out though that non of this is worth even considering if you have sensitive ports (like ftp/ssh/mysql) open to the outside world as it's these back doors people will use to hack the whole server, not just one users personal account on a single site. Also protect against SQL injection attacks by sanitizing your data and so forth. Thank you for your thoughtful suggestions. I totally agree. If someone goes sniffing, or the like, they might be able to get somewhat limited access to the domain. On the other hand if they can crack the FTP, and get into the master server, they can download the whole site. Finally, view it as your responsibility to never store anything personal or identifying (or in fact anything) on the client side in a cookie - one simple key (session_id) in the cookie and everything on the safe secure server is the way to go. I have thought of storing customising information for a particular user in a cookie, but it would simply consist of a set of parameter values. As they would be processed in exactly the same way as if they had been entered as parameters they would presumably represent no more, or less, threat than the parameters which are essential to the operation of the site (and which can readily be read, or bookmarked -- or, on reflection, experimented with). Well! My reflection above cast a completely different light on the situation. It turns out that from a security point of view the multiple domains of Quadra Hosting's scheme should all be regarded as a single domain. In this system each domain has a separate directory under the site root directory. I suspect that any browser access to any of the domains is treated as user group 'other' (with the site owner being owner). This means that any program operating in any domain can read any file in any of the other domains, or in any other directory in the site. This is a bad enough security hole, but in my system I have a separate directory 'Engine' containing the logic to display any of the pages in any of the domains. Each domain has a separate copy of index.php, which sets up a few variables, and then invokes the engine. The individual pages are displayed by a call to index.php, followed by a series of parameters. I have one 'secure' site which is password protected, and engine won't do anything until the user has logged in. However the parameter system can handle indirect paths, and I discovered this morning that if I opened a page on one of the other domains, and then passed the appropriate parameters, I could get into the secure domain, and navigate normally through it. Images are not displayed, as the path is not calculated correctly, but everything else is, and you can read the image properties, and from this work out their correct path. Even worse, if you know their addresses, you can download any of the images or data files simply by typing the address into a browser. I could prevent the cross coupling trick by blocking any path referring to the secure directory, and I could put the data files in a separate directory off to the side, so that they could not be directly downloaded, but as the browser has to be able to download the images (and any documents or spreadsheets) directly I cannot see any easy way to protect them. So much for worrying about the relative virtues of cookies and sessions! Clancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au wrote: but I would be grateful for any suggestions how I could make this procedure more secure. We have given you advice that you should NOT use Cookies in any fashion to secure your site, but you remain steadfast that you know better -- so, what else can we say other than good luck. tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
clanc...@cybec.com.au wrote: On Thu, 21 Jan 2010 22:00:30 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Fri, 2010-01-22 at 08:58 +1100, clanc...@cybec.com.au wrote: On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 12:15 PM +1100 1/21/10, clanc...@cybec.com.au wrote: On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy One last thing. I use sessions for the storage of variables I need between pages, but I use cookies to leave data on the user's computer in case they come back to my site and want to pick up where they left off. Both operations store variables, but are for different purposes. Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy Don't use cookies, use sessions for this. Information stored in cookies is susceptible to being read by pretty much anyone, hence the scare of using cookies that people get. Cookies in themselves are not the problem, but using them for anything you want to keep safe, like login details, etc, is a bad idea. Generally, a session ID is stored in the cookie, which gives nothing away to anyone trying to read it. Thank you all for your comments. My reasoning in using a cookie for user recognition, rather than relying on the session ID, was that with a cookie I could ensure that the connection effectively lasted for some specified period, whereas the session ID lifetime seems to be somewhat short and ill-defined. In this way I can be sure that the user will not be logged out unexpectedly. The actual value of the cookie I use is an MD5 hash of some user information with an additional random component, so that it would be extremely difficult to extract anything useful from it. It could equally be a random number, as it is verified by matching with a value stored on the server. I am also considering changing it every so often (every hour?) while the user is logged in, so that an old value would be useless to a hacker. At present I am using a normal text window for the user to log in, and I suspect that this is by far the weakest link in the system. The website is relatively obscure, and there is nothing particularly valuable on it, but I would be grateful for any suggestions how I could make this procedure more secure. session_id's are (normally) saved in the cookie; and serve as a key to identify a user; so you store all your session based data for a user (such as the fact they are logged in) server side; then assign that info a key; then give that key to the users client so you can recognise them; this *is* what sessions do, session_id is that key, done automatically, via a cookie - to replicate this functionality with your own version is frankly a waste of time. It appears the problem here is that your sessions are timing out too quickly, two simple approaches would be to boost the session lifetime to last longer OR create a quick (ajax) request every X minutes to keep the user logged in when inactive (which they may not want). To answer your specific questions though - what can be done to make this process more secure - no matter what approach you take, when working via http and needing logged in / secure functionality; you need the client to identify themselves with a key of some sort - no matter how you make the key it's always going to be passed via http (GET/POST/COOKIE) - if some hacker passes the same key then your system is going to think it's the original user and give them access. To make it trickier you can store information such as the users IP address, user agent string etc in session and compare it on each request; if it changes log the user out and destroy the session data - however your never going to protect against the most common form of hacking, a nosy co-worker / person in the same house having a nosey while the user is at the toilet / making a brew. This is why many sites re-request password confirmation for potentially sensitive actions like transferring money, changing personal details and so forth (and send email confirmations to tell the user what changed - just in case). It must be pointed out though that non of this is worth even considering if you have sensitive ports (like ftp/ssh/mysql) open to the outside world as it's these back doors people will use to hack the whole server, not just one users personal account on a single site. Also protect against SQL injection attacks by sanitizing your data and so forth. Finally, view it as your responsibility to never store anything personal or identifying (or in fact anything) on the client side in a cookie - one simple
Re: [PHP] Cookies sessions
tedd wrote:
At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au wrote:
but I would be grateful for any suggestions how I
could make this procedure more secure.
We have given you advice that you should NOT use Cookies in any fashion
to secure your site, but you remain steadfast that you know better --
so, what else can we say other than good luck.
tedd
These are my basic guidelines - what I like to do.
It may not be the best thing for every type od web site.
1) I have a user database that has username and a password hash. The
password itself is never stored.
The password hash is sha1sum(strtolower($username) . $salt . $password)
The salt is something like 5dgudsdgh5673g and should be stored as a
private variable in your user authentication class.
The reason I have the username there to is because some passwords are
very popular, using the username when generating the hash ensures that
two users with identical password will have different hashes. This is
important if an sql injection attack ever manages to get a dump of your
user database.
You should protect against sql injection by using prepared statements
for any database query that involves user submitted data (such as
username and password) but you still want to make sure that hashes are
unique, and you do that by adding the username to the salt.
When a user successfully logs in, the unique id of the user is then
stored as a session variable.
For administrative tasks, in addition to requiring that the user be
logged in to an account with admin privileges, all administrative tasks
are in a directory that is protected by apache authentication.
So to get to those kind of pages, the user has to have a
username/password that is stored in a .htpasswd file for Apache to let
them in AND they have to be logged in as a user that has been
authenticated as an administrative user.
I personally do all login via https so that username/password combos are
never sent plain text. That's more expensive because you need to
purchase a SSL certificate. You can use self-signed but it is better to
use an SSL certificate from a certificate authority.
For session security, I have the following directives set in my php.ini
file:
session.use_only_cookies = 1
- That prevents the session id from being sent via get.
session.cookie_lifetime = 0
- That instructs the browser to delete the cookie when the browsing
session ends.
session.cookie_httponly = 1
- That theoretically denies access to the cookie from scripting
languages. I say theoretically because when testing my site for XSS
security, I was initially able to get some XSS attacks to display my
session id (tested in firefox 2 w/o noscript - noscript blocked it even
with the domain allowed), so they were getting it somehow.
Since I have secure login which is a different domain from main domain,
in my web app itself I set
if (file_exists('/srv/path/DEVEL')) {
ini_set(session.cookie_domain,.mydomain.devel);
} else {
ini_set(session.cookie_domain,.mydomain.org);
}
That way, secure.mydomain.org (which is used for login) uses the same
session variable as www.mydomain.org (used for rest of site) so that
when the user logs in, the session variable that specifies the user on
the non secure domain gets updated when the user logs in on the secure
domain.
There are several good php books that discuss session security and php
web applications. I don't remember which books I used when learning my
technique, but it would be a good idea to buy or borrow some recent
books on php web application design.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Sat, 23 Jan 2010 09:32:37 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au wrote: but I would be grateful for any suggestions how I could make this procedure more secure. We have given you advice that you should NOT use Cookies in any fashion to secure your site, but you remain steadfast that you know better -- so, what else can we say other than good luck. BUT you have told me to use sessions, and sessions use a Cookie! If the Cookie I use contains random data, the only difference in security is in the time that it remains valid. Neither contains any useful information, but while they are valid both will enable you to bypass security. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Sat, 23 Jan 2010 15:10:11 +, nrix...@gmail.com (Nathan Rixham) wrote: To answer your specific questions though - what can be done to make this process more secure - no matter what approach you take, when working via http and needing logged in / secure functionality; you need the client to identify themselves with a key of some sort - no matter how you make the key it's always going to be passed via http (GET/POST/COOKIE) - if some hacker passes the same key then your system is going to think it's the original user and give them access. To make it trickier you can store information such as the users IP address, user agent string etc in session and compare it on each request; if it changes log the user out and destroy the session data - however your never going to protect against the most common form of hacking, a nosy co-worker / person in the same house having a nosey while the user is at the toilet / making a brew. This is why many sites re-request password confirmation for potentially sensitive actions like transferring money, changing personal details and so forth (and send email confirmations to tell the user what changed - just in case). It must be pointed out though that non of this is worth even considering if you have sensitive ports (like ftp/ssh/mysql) open to the outside world as it's these back doors people will use to hack the whole server, not just one users personal account on a single site. Also protect against SQL injection attacks by sanitizing your data and so forth. Thank you for your thoughtful suggestions. I totally agree. If someone goes sniffing, or the like, they might be able to get somewhat limited access to the domain. On the other hand if they can crack the FTP, and get into the master server, they can download the whole site. Finally, view it as your responsibility to never store anything personal or identifying (or in fact anything) on the client side in a cookie - one simple key (session_id) in the cookie and everything on the safe secure server is the way to go. I have thought of storing customising information for a particular user in a cookie, but it would simply consist of a set of parameter values. As they would be processed in exactly the same way as if they had been entered as parameters they would presumably represent no more, or less, threat than the parameters which are essential to the operation of the site (and which can readily be read, or bookmarked -- or, on reflection, experimented with). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
At 8:58 AM +1100 1/22/10, clanc...@cybec.com.au wrote: On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 12:15 PM +1100 1/21/10, clanc...@cybec.com.au wrote: On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy One last thing. I use sessions for the storage of variables I need between pages, but I use cookies to leave data on the user's computer in case they come back to my site and want to pick up where they left off. Both operations store variables, but are for different purposes. Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy Clancy: My advise -- don't use Cookies to control access for anything. Cookies are client-side and you should never trust anything coming from the client. If you want to protect access to a private portion of your site, then require a user id and password. Using Cookies to do that is vary dangerous. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Thu, 21 Jan 2010 22:00:30 +, a...@ashleysheridan.co.uk (Ashley Sheridan) wrote: On Fri, 2010-01-22 at 08:58 +1100, clanc...@cybec.com.au wrote: On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 12:15 PM +1100 1/21/10, clanc...@cybec.com.au wrote: On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy One last thing. I use sessions for the storage of variables I need between pages, but I use cookies to leave data on the user's computer in case they come back to my site and want to pick up where they left off. Both operations store variables, but are for different purposes. Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy Don't use cookies, use sessions for this. Information stored in cookies is susceptible to being read by pretty much anyone, hence the scare of using cookies that people get. Cookies in themselves are not the problem, but using them for anything you want to keep safe, like login details, etc, is a bad idea. Generally, a session ID is stored in the cookie, which gives nothing away to anyone trying to read it. Thank you all for your comments. My reasoning in using a cookie for user recognition, rather than relying on the session ID, was that with a cookie I could ensure that the connection effectively lasted for some specified period, whereas the session ID lifetime seems to be somewhat short and ill-defined. In this way I can be sure that the user will not be logged out unexpectedly. The actual value of the cookie I use is an MD5 hash of some user information with an additional random component, so that it would be extremely difficult to extract anything useful from it. It could equally be a random number, as it is verified by matching with a value stored on the server. I am also considering changing it every so often (every hour?) while the user is logged in, so that an old value would be useless to a hacker. At present I am using a normal text window for the user to log in, and I suspect that this is by far the weakest link in the system. The website is relatively obscure, and there is nothing particularly valuable on it, but I would be grateful for any suggestions how I could make this procedure more secure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
clanc...@cybec.com.au wrote: My reasoning in using a cookie for user recognition, rather than relying on the session ID, was that with a cookie I could ensure that the connection effectively lasted for some specified period, whereas the session ID lifetime seems to be somewhat short and ill-defined. Shouldn't be. You can tell sessions to last as long or short as you want. As far as login goes, there are many ways to do it and the best way depends upon what you are doing. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 12:15 PM +1100 1/21/10, clanc...@cybec.com.au wrote: On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy One last thing. I use sessions for the storage of variables I need between pages, but I use cookies to leave data on the user's computer in case they come back to my site and want to pick up where they left off. Both operations store variables, but are for different purposes. Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Fri, 2010-01-22 at 08:58 +1100, clanc...@cybec.com.au wrote: On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 12:15 PM +1100 1/21/10, clanc...@cybec.com.au wrote: On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy One last thing. I use sessions for the storage of variables I need between pages, but I use cookies to leave data on the user's computer in case they come back to my site and want to pick up where they left off. Both operations store variables, but are for different purposes. Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy Don't use cookies, use sessions for this. Information stored in cookies is susceptible to being read by pretty much anyone, hence the scare of using cookies that people get. Cookies in themselves are not the problem, but using them for anything you want to keep safe, like login details, etc, is a bad idea. Generally, a session ID is stored in the cookie, which gives nothing away to anyone trying to read it. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Cookies sessions
clanc...@cybec.com.au wrote: Yes; I'm doing that too. I am setting up a private website, and using cookies to control access to it. Clancy The only variable I store in a cookie is the session id. Everything else is stored in the session database. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Wed, 2010-01-20 at 15:45 +1100, clanc...@cybec.com.au wrote:
On Tue, 19 Jan 2010 22:45:14 -0500, phps...@gmail.com (Phpster) wrote:
The first setcookie call is empty which produces the errors that cause
the second cookie to fail.
I'm afraid not. I modified the program started to read:
?php //;V;;; Cypalda/Index.php Printed: 21/3/09
session_start ();
setcookie ('Try_1', 'Works', time()+3600);
echo 'nbsp;';
setcookie ('Try_2', 'Doesnt', time()+3600);
With the result
Warning: Cannot modify header information - headers already sent by (output
started at
D:\Websites\cypalda.com\index.php:6) in D:\Websites\cypalda.com\index.php on
line 7
And cookie 'Try_2' is not set.
I suspect you have been running with output buffering on, but I had left it
in the default
state, which is off.
Well the problem here is obvious, you just changed the line that was
causing the error to another line that causes another error! Why do you
need to echo a space character? Remove that line and you will get rid of
this new error.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Cookies sessions
On Wed, 20 Jan 2010 13:19:03 +, a...@ashleysheridan.co.uk (Ashley Sheridan)
wrote:
On Wed, 2010-01-20 at 15:45 +1100, clanc...@cybec.com.au wrote:
On Tue, 19 Jan 2010 22:45:14 -0500, phps...@gmail.com (Phpster) wrote:
The first setcookie call is empty which produces the errors that cause
the second cookie to fail.
I'm afraid not. I modified the program started to read:
?php //;V;;;Cypalda/Index.php Printed:
21/3/09
session_start ();
setcookie ('Try_1', 'Works', time()+3600);
echo 'nbsp;';
setcookie ('Try_2', 'Doesnt', time()+3600);
With the result
Warning: Cannot modify header information - headers already sent by (output
started at
D:\Websites\cypalda.com\index.php:6) in D:\Websites\cypalda.com\index.php on
line 7
And cookie 'Try_2' is not set.
I suspect you have been running with output buffering on, but I had left it
in the default
state, which is off.
Well the problem here is obvious, you just changed the line that was
causing the error to another line that causes another error! Why do you
need to echo a space character? Remove that line and you will get rid of
this new error.
When you are working with sessions, provided you start your program with
session_id(), you
can then do anything you like with session variables at any point in your
program. In my
original question I asked if there was a cookie equivalent.
Someone said there was, but the above is simply demonstrating that their
suggested
solution doesn't work. It appears there is no solution, but that the workaround
is to turn
on output buffering, at least until you finish setting cookies, so that you can
be certain
that no output is generated before this point.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Thu, 2010-01-21 at 08:43 +1100, clanc...@cybec.com.au wrote:
On Wed, 20 Jan 2010 13:19:03 +, a...@ashleysheridan.co.uk (Ashley
Sheridan) wrote:
On Wed, 2010-01-20 at 15:45 +1100, clanc...@cybec.com.au wrote:
On Tue, 19 Jan 2010 22:45:14 -0500, phps...@gmail.com (Phpster) wrote:
The first setcookie call is empty which produces the errors that cause
the second cookie to fail.
I'm afraid not. I modified the program started to read:
?php //;V;;; Cypalda/Index.php Printed:
21/3/09
session_start ();
setcookie ('Try_1', 'Works', time()+3600);
echo 'nbsp;';
setcookie ('Try_2', 'Doesnt', time()+3600);
With the result
Warning: Cannot modify header information - headers already sent by
(output started at
D:\Websites\cypalda.com\index.php:6) in D:\Websites\cypalda.com\index.php
on line 7
And cookie 'Try_2' is not set.
I suspect you have been running with output buffering on, but I had left
it in the default
state, which is off.
Well the problem here is obvious, you just changed the line that was
causing the error to another line that causes another error! Why do you
need to echo a space character? Remove that line and you will get rid of
this new error.
When you are working with sessions, provided you start your program with
session_id(), you
can then do anything you like with session variables at any point in your
program. In my
original question I asked if there was a cookie equivalent.
Someone said there was, but the above is simply demonstrating that their
suggested
solution doesn't work. It appears there is no solution, but that the
workaround is to turn
on output buffering, at least until you finish setting cookies, so that you
can be certain
that no output is generated before this point.
Cookies behave very differently from sessions. With sessions, you can
modify and use the values immediately, but with cookies, the values you
save are only then usable the next time the browser sends them back with
the header request. This basically means that the cookie information is
only available to your scripts if it existed in the client-side cookie
when the user made the request for the page your script is on.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Cookies sessions
2010/1/20 clanc...@cybec.com.au: When you are working with sessions, provided you start your program with session_id(), you can then do anything you like with session variables at any point in your program. Hi, You meant session_start() instead of session_id(), right? But yes, once you started a session (before any output is sent to the browser, that includes echo and print statements, empty space chars, etc) you can do anything you like with the $_SESSION array, being able to read the stored values in other requests / scripts of your app, as long as the session is started. In my original question I asked if there was a cookie equivalent. As far as I know, yes, there is. You set a cookie using the setcookie() function. This function, in the same way as session_start(), must be called before any output is sent to the browser. Once a cookie is set in the client, you can read the $_COOKIE array in any subsequent request of your client, in any point of your app, just like session. Someone said there was, but the above is simply demonstrating that their suggested solution doesn't work. It appears there is no solution, but that the workaround is to turn on output buffering, at least until you finish setting cookies, so that you can be certain that no output is generated before this point. You don't need to use output buffering at all. You only need this mechanism if your script needs to output stuff before the session_start() or setcookie() functions get executed. Well, I hope this information is helpful. Cheers, Bruno. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
Bruno Fajardo wrote: You don't need to use output buffering at all. You only need this mechanism if your script needs to output stuff before the session_start() or setcookie() functions get executed. Output buffering is also used if you need to output something before the headers are sent either by the header() function or simply using echo or print(). Joseph -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Wed, 20 Jan 2010 20:05:42 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote: 2010/1/20 clanc...@cybec.com.au: When you are working with sessions, provided you start your program with session_id(), you can then do anything you like with session variables at any point in your program. Hi, You meant session_start() instead of session_id(), right? Yes; Oops! But yes, once you started a session (before any output is sent to the browser, that includes echo and print statements, empty space chars, etc) you can do anything you like with the $_SESSION array, being able to read the stored values in other requests / scripts of your app, as long as the session is started. In my original question I asked if there was a cookie equivalent. As far as I know, yes, there is. You set a cookie using the setcookie() function. This function, in the same way as session_start(), must be called before any output is sent to the browser. Once a cookie is set in the client, you can read the $_COOKIE array in any subsequent request of your client, in any point of your app, just like session. It is not equivalent if you can't set a cookie after you have generated any output. Someone said there was, but the above is simply demonstrating that their suggested solution doesn't work. It appears there is no solution, but that the workaround is to turn on output buffering, at least until you finish setting cookies, so that you can be certain that no output is generated before this point. You don't need to use output buffering at all. You only need this mechanism if your script needs to output stuff before the session_start() or setcookie() functions get executed. I don't NEED output buffering if I put the cookie handling logic right at the start of the program, and don't ever want to put any diagnostics into it. But there is a logical place for it much later in my program, and I often want to put diagnostics into even the simplest bit of code, and life is much easier if this doesn't disable the cookie handler. Well, I hope this information is helpful. Yes, thanks to everyone who contributed. I now have a better understanding of what cookies are, and have turned on output buffering, enabling me to put the handler where I want, and still be able to debug it. Clancy Cheers, Bruno. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Cookies sessions
I am trying for the first time to use cookies. The manual contains the statement Cookies are part of the HTTP header, so setcookie() must be called before any output is sent to the browser. When I first started using sessions, I was alarmed to read a very similar statement about sessions, but I soon found that if I started my program with the statement session_start(); I could then set up, access, modify or clear any session variable at any time in my program. This is enormously useful, as I can put the session handling at any convenient point in my program, and can precede them with diagnostics if I need to. However I have almost immediately found that while I appear to be able to read cookies at any time, I cannot set them when I would like to. Is there any similar trick which will work with cookies? If I really have to work out what they should be, and then set them up, before issuing any diagnostics, etc, it will make life decidely more complicated. (I assume that I can set several cookies using successive calls to setcookie()?) I was also somewhat surprised to find that a cookie is used to implement sessions. Does this place any limitations on using both sessions and cookies in the same program? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
2010/1/19 clanc...@cybec.com.au: I am trying for the first time to use cookies. The manual contains the statement Cookies are part of the HTTP header, so setcookie() must be called before any output is sent to the browser. When I first started using sessions, I was alarmed to read a very similar statement about sessions, but I soon found that if I started my program with the statement session_start(); I could then set up, access, modify or clear any session variable at any time in my program. This is enormously useful, as I can put the session handling at any convenient point in my program, and can precede them with diagnostics if I need to. However I have almost immediately found that while I appear to be able to read cookies at any time, I cannot set them when I would like to. Is there any similar trick which will work with cookies? The only trick is that you have to call setcookie() before any output is sent to the browser, just like the session_start() behavior. If I really have to work out what they should be, and then set them up, before issuing any diagnostics, etc, it will make life decidely more complicated. (I assume that I can set several cookies using successive calls to setcookie()?) Yes, each one with a differente name. I was also somewhat surprised to find that a cookie is used to implement sessions. Does this place any limitations on using both sessions and cookies in the same program? No. The cookie in PHP that implements session is by default called PHPSESSID. As long as your other cookies are named differently, you should be fine. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
When I first started using sessions, I was alarmed to read a very similar statement about sessions, but I soon found that if I started my program with the statement session_start(); I could then set up, access, modify or clear any session variable at any time in my program. This is enormously useful, as I can put the session handling at any convenient point in my program, and can precede them with diagnostics if I need to. are you looking for ob_* functions ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
Hi, However I have almost immediately found that while I appear to be able to read cookies at any time, I cannot set them when I would like to. Is there any similar trick which will work with cookies? Keep in mind that cookies are set by sending an HTTP header as part of the response, so until you do that they can't be sent back to you by the client (and subsequently appear in $_COOKIE). (I assume that I can set several cookies using successive calls to setcookie()?) Sure. Not that I've done it. I was also somewhat surprised to find that a cookie is used to implement sessions. Does this place any limitations on using both sessions and cookies in the same program? No (give them a different name though). You can also use sessions by putting the session ID on the URL, but this, I believe, is called a ball ache. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 16th January) Follow me on Twitter: http://twitter.com/_rgraph Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
Be aware that there is a limit of 20 cookies per domain Bastien Sent from my iPod On Jan 19, 2010, at 6:12 AM, Bruno Fajardo bsfaja...@gmail.com wrote: 2010/1/19 clanc...@cybec.com.au: I am trying for the first time to use cookies. The manual contains the statement Cookies are part of the HTTP header, so setcookie() must be called before any output is sent to the browser. When I first started using sessions, I was alarmed to read a very similar statement about sessions, but I soon found that if I started my program with the statement session_start(); I could then set up, access, modify or clear any session variable at any time in my program. This is enormously useful, as I can put the session handling at any convenient point in my program, and can precede them with diagnostics if I need to. However I have almost immediately found that while I appear to be able to read cookies at any time, I cannot set them when I would like to. Is there any similar trick which will work with cookies? The only trick is that you have to call setcookie() before any output is sent to the browser, just like the session_start() behavior. If I really have to work out what they should be, and then set them up, before issuing any diagnostics, etc, it will make life decidely more complicated. (I assume that I can set several cookies using successive calls to setcookie()?) Yes, each one with a differente name. I was also somewhat surprised to find that a cookie is used to implement sessions. Does this place any limitations on using both sessions and cookies in the same program? No. The cookie in PHP that implements session is by default called PHPSESSID. As long as your other cookies are named differently, you should be fine. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Tue, 19 Jan 2010 09:12:17 -0200, bsfaja...@gmail.com (Bruno Fajardo) wrote:
2010/1/19 clanc...@cybec.com.au:
I am trying for the first time to use cookies. The manual contains the
statement Cookies
are part of the HTTP header, so setcookie() must be called before any output
is sent to
the browser.
When I first started using sessions, I was alarmed to read a very similar
statement about
sessions, but I soon found that if I started my program with the statement
session_start(); I could then set up, access, modify or clear any session
variable at
any time in my program. This is enormously useful, as I can put the session
handling at
any convenient point in my program, and can precede them with diagnostics if
I need to.
However I have almost immediately found that while I appear to be able to
read cookies at
any time, I cannot set them when I would like to. Is there any similar trick
which will
work with cookies?
The only trick is that you have to call setcookie() before any output
is sent to the browser, just like the session_start() behavior.
..
Thank you all for your suggestions. Unfortunately I have already tried this,
and it
doesn't work for me (I am running PHP: 5.1.6). I have only tested this on my
own PC, but
if it doesn't work here, I would be very surprised if it would work on the
remote server.
Index.php starts:
?php //;V;;; Cypalda/Index.php Printed:
session_start ();
setcookie ();
setcookie ('user_id', 'Wilma*Witgenstein', time()+3600);
And this produces the following output:
Warning: setcookie() expects at least 1 parameter, 0 given in
D:\Websites\cypalda.com\index.php on line 4
Warning: Cannot modify header information - headers already sent by (output
started at
D:\Websites\cypalda.com\index.php:4) in D:\Websites\cypalda.com\index.php on
line 5
It is interesting to note that the second diagnostic is generated because the
first
diagnostic is taken to have initiated the headers. I think I can live with this
limitation, but this diagnostic is a warning of the hassles I am likely to face
if I
cannot find a way around it.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
The first setcookie call is empty which produces the errors that cause
the second cookie to fail.
Bastien
Sent from my iPod
On Jan 19, 2010, at 10:16 PM, clanc...@cybec.com.au wrote:
On Tue, 19 Jan 2010 09:12:17 -0200, bsfaja...@gmail.com (Bruno
Fajardo) wrote:
2010/1/19 clanc...@cybec.com.au:
I am trying for the first time to use cookies. The manual contains
the statement Cookies
are part of the HTTP header, so setcookie() must be called before
any output is sent to
the browser.
When I first started using sessions, I was alarmed to read a very
similar statement about
sessions, but I soon found that if I started my program with the
statement
session_start(); I could then set up, access, modify or clear
any session variable at
any time in my program. This is enormously useful, as I can put
the session handling at
any convenient point in my program, and can precede them with
diagnostics if I need to.
However I have almost immediately found that while I appear to be
able to read cookies at
any time, I cannot set them when I would like to. Is there any
similar trick which will
work with cookies?
The only trick is that you have to call setcookie() before any output
is sent to the browser, just like the session_start() behavior.
..
Thank you all for your suggestions. Unfortunately I have already
tried this, and it
doesn't work for me (I am running PHP: 5.1.6). I have only tested
this on my own PC, but
if it doesn't work here, I would be very surprised if it would work
on the remote server.
Index.php starts:
?php //;V;;;Cypalda/Index.php Printed:
session_start ();
setcookie ();
setcookie ('user_id', 'Wilma*Witgenstein', time()+3600);
And this produces the following output:
Warning: setcookie() expects at least 1 parameter, 0 given in
D:\Websites\cypalda.com\index.php on line 4
Warning: Cannot modify header information - headers already sent by
(output started at
D:\Websites\cypalda.com\index.php:4) in D:\Websites\cypalda.com
\index.php on line 5
It is interesting to note that the second diagnostic is generated
because the first
diagnostic is taken to have initiated the headers. I think I can
live with this
limitation, but this diagnostic is a warning of the hassles I am
likely to face if I
cannot find a way around it.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Tue, 19 Jan 2010 16:45:37 +0530, kranthi...@gmail.com (kranthi) wrote: When I first started using sessions, I was alarmed to read a very similar statement about sessions, but I soon found that if I started my program with the statement session_start(); I could then set up, access, modify or clear any session variable at any time in my program. This is enormously useful, as I can put the session handling at any convenient point in my program, and can precede them with diagnostics if I need to. are you looking for ob_* functions ? Yes, thank you; I was! I read this, and said what the hell are they?, before I tried Bruno's setcookie() again, and verified it didn't work. Then I noticed a textbook buried on my desk opened to the section on cookies, saw output buffering, and realised what you were talking about. And, yes, they do seem to let me do what I want. Unfortunately they don't do one thing I would have liked them to, which is to enable me to see diagnostics buried in CSS code. The only way to discover these is to use the Explorer 'View source' option, and examine the HTML very carefully. While I was fiddling with the setcookie suggestion some diagnostics went missing (because I was running the wrong version), and when I looked at the HTML I found some error messages relating to an undefined variable in the CSS, which I fear have been there for a long time. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies sessions
On Tue, 19 Jan 2010 22:45:14 -0500, phps...@gmail.com (Phpster) wrote:
The first setcookie call is empty which produces the errors that cause
the second cookie to fail.
I'm afraid not. I modified the program started to read:
?php //;V;;; Cypalda/Index.php Printed: 21/3/09
session_start ();
setcookie ('Try_1', 'Works', time()+3600);
echo 'nbsp;';
setcookie ('Try_2', 'Doesnt', time()+3600);
With the result
Warning: Cannot modify header information - headers already sent by (output
started at
D:\Websites\cypalda.com\index.php:6) in D:\Websites\cypalda.com\index.php on
line 7
And cookie 'Try_2' is not set.
I suspect you have been running with output buffering on, but I had left it in
the default
state, which is off.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
It brings up another question, though. Let's say that I have a session_start() call at the beginning of a bunch of pages. So that each time one of these pages is called, the call is made to session_start(). It seems like it would screw things up royally if each call to session_start() generated a new SID. The browser sends an SID cookie to the server on page request. And if the page has a session_start() call at the beginning of it, is it reasonable to assume that the server will not generate a new SID, but instead use the one sent in the HTTP request to find its session information? (Assuming the timeout hasn't expired, the user is still using the same instance of the browser, etc.) Similarly, if an SID *isn't* sent by the browser, then a call to session_start() at the beginning of the page *will* generate a completely new SID, right? Correct. Easy test: ?php session_start(); echo sess id: . session_id(); visit the page in your browser, refresh a couple of times (id will be the same). Clear the cookies in your browser, refresh - new id. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
Paul M Foster wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? The browser sends all cookie information as part of the request. You can see this by creating a dummy page that does not call seesion_start() that includes an XSS attack that reads the cookie and displays the session ID in an alert. Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? session stuff is stored server side, only the session ID is stored in the cookie. It is still a bad idea to store username and password in the session because if you are on a shared server and you are not using a DB for session management (default is not to) another user on the server can read your cookies. Even if you are using a database for session management, storing username/password in the session is a risk in case there is an sql injection attack that succesfully dumps your session database (which is bad enough w/o it exposing passwords). I store a user id in the session and get the username from a db lookup if/when I need the username (but storing the username itself isn't really dangerous and would save an sql lookup in some cases). There's no need to store password. If the user is not logged in, the session userid is set to 0. Anything that requires authentication in my code requires a session userid 0 - and the userid can only be changed to a positive value via login. -=- A gotcha - changing a session variable doesn't actually happen until the script exits. So if you set a session variable and then use the session variable later in the script, it will use the OLD value and not the new value, because the new value hasn't yet been written to the session. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Cookies/Sessions and how they work
This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
Paul M Foster wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Yep (afaik). Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? When a page request comes in, the browser sends a cookie - but it's only the session id. No other info is stored in the cookie or browser. PHP then looks for that session id in a specified location (session.save_path) and then loads that data from the server. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
On Mon, Mar 9, 2009 at 10:26 PM, Paul M Foster pa...@quillandmouse.com wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php When a website sends the Cookie: in a HTTP header, the browser decides what to do with it (or not to do). Generally, it saves the cookie name and contents into a file. Although, various browsers handle cookies differently, and some browsers ignore them completely (or have options to). Within the cookie data are various things, such as the domain and expiration. When you point the browser to a website, the browser checks all it's cookies and see if the website matches the domain field in any of the cookies. If so, it sends the name/content of the cookie/cookies to the site in a/an HTTP header automatically. A very useful tool in monitoring all this and viewing what your browser does behind the scenes is the Firefox extension Live HTTP Headers. https://addons.mozilla.org/en-US/firefox/addon/3829 PHP sessions use cookies. When you call session_start() for the first time, php randomly generates a unique hash ID for that session. It sends it to the browser as a cookie with the name PHPSESSID (this is customizable in php.ini). The server keeps a list of all the sessions on the HDD (and expires them when needed, of course). When you store any variable into the $_SESSION superglobal var, it stores the data ON THE SERVER - nothing is sent to the browser. The browser only sends the session ID cookie, which tells the server hey, get the $_SESSION data for this session ID. So it's up to the browser to send the session cookie each time, else all the $_SESSION data is lost. Help clear it up for ya? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Cookies/Sessions and how they work
Hi I don't think PHP stores Session information in Cookies. However It dose store the sessionId (a unique alphanumeric string) in cookies. This SessionId is used to identify the requests sent from one user. The Session information is by default stored in the /tmp directory on your system in a flat file. Chetan Dattaram Rane | Software Engineer | Persistent Systems chetan_r...@persistent.co.in | Cell: +91 94033 66714 | Tel: +91 (0832) 30 79014 Innovation in software product design, development and delivery- www.persistentsys.com -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: Tuesday, March 10, 2009 7:57 AM To: php-general@lists.php.net Subject: [PHP] Cookies/Sessions and how they work This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
On Mon, Mar 09, 2009 at 11:35:57PM -0400, APseudoUtopia wrote: On Mon, Mar 9, 2009 at 10:26 PM, Paul M Foster pa...@quillandmouse.com wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php When a website sends the Cookie: in a HTTP header, the browser decides what to do with it (or not to do). Generally, it saves the cookie name and contents into a file. Although, various browsers handle cookies differently, and some browsers ignore them completely (or have options to). Within the cookie data are various things, such as the domain and expiration. When you point the browser to a website, the browser checks all it's cookies and see if the website matches the domain field in any of the cookies. If so, it sends the name/content of the cookie/cookies to the site in a/an HTTP header automatically. A very useful tool in monitoring all this and viewing what your browser does behind the scenes is the Firefox extension Live HTTP Headers. https://addons.mozilla.org/en-US/firefox/addon/3829 PHP sessions use cookies. When you call session_start() for the first time, php randomly generates a unique hash ID for that session. It sends it to the browser as a cookie with the name PHPSESSID (this is customizable in php.ini). The server keeps a list of all the sessions on the HDD (and expires them when needed, of course). When you store any variable into the $_SESSION superglobal var, it stores the data ON THE SERVER - nothing is sent to the browser. The browser only sends the session ID cookie, which tells the server hey, get the $_SESSION data for this session ID. So it's up to the browser to send the session cookie each time, else all the $_SESSION data is lost. Help clear it up for ya? Yes, this essentially echoes what Chis said. Thanks. It brings up another question, though. Let's say that I have a session_start() call at the beginning of a bunch of pages. So that each time one of these pages is called, the call is made to session_start(). It seems like it would screw things up royally if each call to session_start() generated a new SID. The browser sends an SID cookie to the server on page request. And if the page has a session_start() call at the beginning of it, is it reasonable to assume that the server will not generate a new SID, but instead use the one sent in the HTTP request to find its session information? (Assuming the timeout hasn't expired, the user is still using the same instance of the browser, etc.) Similarly, if an SID *isn't* sent by the browser, then a call to session_start() at the beginning of the page *will* generate a completely new SID, right? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Cookies, Sessions and Login Process
Hi there, I'm new to php coming from an asp background and would like to know the easiest way to automate a login process. I have one page called 'index.php' and it contains a form with 2 elements, username and password. This page is posted to th 'login.php' and here I do a check against the database to see if the person is who they say they are. This where I came across a problem...I would like to set a cookie on the user's machine once I know they are who they say they are. So I attempted to create a cookie to hold their username and password upon successful login..I received the following error...Warning: Cannot add header information - headers already sent by (output started at E:\ez\codesnipits\login.php:16) in E:\ez\codesnipits\login.php on line 66. So I looked up in the manual and found that I can't do it this way. I can't send header info after the header has been sent for obvious reasons. So how the heck do I manage to do this? What I would to do is have the user login once, and each subsequent time they visit , skip the login process via their username and password in the cookie. Any insight to this type of process would greatly be appreciated. Thx Joe p.s Sorry about the bold font ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Cookies, Sessions and Login Proceess
Just do your authentication before you send any HTML (including any whitespace). I actually recommend not sending ANY HTML from your authentication script. Authenticate them, set your cookie, and redirect the visitor to an appropriate next page, based on whether or not they've successfully authenticated. BTW - storing the username/password in the cookie makes no sense They've already authenticated ... just store a user-is-logged-in cookie which expires after X minutes/hours/etc. It's a good practice for when you'll have to deal with privacy security concerns. ~Chris /\ \ / September 11, 2001 X We Are All New Yorkers / \ rm -rf /bin/laden On Mon, 12 Nov 2001, Joe Van Meer wrote: Hi there, I'm new to php coming from an asp background and would like to know the easiest way to automate a login process. I have one page called 'index.php' and it contains a form with 2 elements, username and password. This page is posted to th 'login.php' and here I do a check against the database to see if the person is who they say they are. This where I came across a problem...I would like to set a cookie on the user's machine once I know they are who they say they are. So I attempted to create a cookie to hold their username and password upon successful login..I received the following error...Warning: Cannot add header information - headers already sent by (output started at E:\ez\codesnipits\login.php:16) in E:\ez\codesnipits\login.php on line 66. So I looked up in the manual and found that I can't do it this way. I can't send header info after the header has been sent for obvious reasons. So how the heck do I manage to do this? What I would to do is have the user login once, and each subsequent time they visit , skip the login process via their username and password in the cookie. Any insight to this type of process would greatly be appreciated. Thx Joe p.s Sorry about the bold font ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Cookies, Sessions and Login Proceess
Thx Christopher for replying. Ok, let me see if I understand you correctly... The user enters username and password on index.php, this is posted to login.php. On login.php after I verify the user is who he/she says they are I set a cookie called accessedbefore to yes and redirect them to the main page. Am I allowed to set a cookie and redirect them after determining who the user is? How would I redirect them after setting the cookie? Header function or is there a better way? Thx Joe :) Christopher William Wesley [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Just do your authentication before you send any HTML (including any whitespace). I actually recommend not sending ANY HTML from your authentication script. Authenticate them, set your cookie, and redirect the visitor to an appropriate next page, based on whether or not they've successfully authenticated. BTW - storing the username/password in the cookie makes no sense They've already authenticated ... just store a user-is-logged-in cookie which expires after X minutes/hours/etc. It's a good practice for when you'll have to deal with privacy security concerns. ~Chris /\ \ / September 11, 2001 X We Are All New Yorkers / \ rm -rf /bin/laden On Mon, 12 Nov 2001, Joe Van Meer wrote: Hi there, I'm new to php coming from an asp background and would like to know the easiest way to automate a login process. I have one page called 'index.php' and it contains a form with 2 elements, username and password. This page is posted to th 'login.php' and here I do a check against the database to see if the person is who they say they are. This where I came across a problem...I would like to set a cookie on the user's machine once I know they are who they say they are. So I attempted to create a cookie to hold their username and password upon successful login..I received the following error...Warning: Cannot add header information - headers already sent by (output started at E:\ez\codesnipits\login.php:16) in E:\ez\codesnipits\login.php on line 66. So I looked up in the manual and found that I can't do it this way. I can't send header info after the header has been sent for obvious reasons. So how the heck do I manage to do this? What I would to do is have the user login once, and each subsequent time they visit , skip the login process via their username and password in the cookie. Any insight to this type of process would greatly be appreciated. Thx Joe p.s Sorry about the bold font ;) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Cookies, Sessions and Login Proceess
header(); function is fine. Another option is javascript which is dependent on the client software. But you get the picture about the login process. I just have to agree with Chris, something name 'is_logged' is better than 'accessedbefore'. -- Julio Nobrega A hora está chegando: http://toca.sourceforge.net Joe Van Meer [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Thx Christopher for replying. Ok, let me see if I understand you correctly... The user enters username and password on index.php, this is posted to login.php. On login.php after I verify the user is who he/she says they are I set a cookie called accessedbefore to yes and redirect them to the main page. Am I allowed to set a cookie and redirect them after determining who the user is? How would I redirect them after setting the cookie? Header function or is there a better way? Thx Joe :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Cookies, Sessions and Login Proceess
On Mon, 12 Nov 2001, Joe Van Meer wrote:
Thx Christopher for replying. Ok, let me see if I understand you
correctly...
The user enters username and password on index.php, this is posted to
login.php. On login.php after I verify the user is who he/she says they are
I set a cookie called accessedbefore to yes and redirect them to the
Exactly.
main page. Am I allowed to set a cookie and redirect them after determining
who the user is? How would I redirect them after setting the cookie? Header
You can set a cookie any time before any standard output is sent to the
browser (and before you send a new Location header).
Your login.php can look something like this (with pseudo-ish code) ...
?php
$input_ok = validate_user_input( $username, $password );
if( $input_ok ){
$user_ok = authenticate_user( $username, $password );
if( $user_ok ){
setcookie( myuser, ok, time()+7200, / );
header( Location: congratulations.html );
} else {
header( Location: go_away.html );
}
} else {
header( Location: go_away.html );
}
?
~Chris /\
\ / September 11, 2001
X We Are All New Yorkers
/ \ rm -rf /bin/laden
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Cookies, Sessions and Login Proceess
Thanx a bunch you guys! Got my login process going the way I wanted it. I
appreciate your help, as I['m new to php. The first of many questions I
suppose :)
Cheers Joe
Christopher William Wesley [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Mon, 12 Nov 2001, Joe Van Meer wrote:
Thx Christopher for replying. Ok, let me see if I understand you
correctly...
The user enters username and password on index.php, this is posted to
login.php. On login.php after I verify the user is who he/she says they
are
I set a cookie called accessedbefore to yes and redirect them to the
Exactly.
main page. Am I allowed to set a cookie and redirect them after
determining
who the user is? How would I redirect them after setting the cookie?
Header
You can set a cookie any time before any standard output is sent to the
browser (and before you send a new Location header).
Your login.php can look something like this (with pseudo-ish code) ...
?php
$input_ok = validate_user_input( $username, $password );
if( $input_ok ){
$user_ok = authenticate_user( $username, $password );
if( $user_ok ){
setcookie( myuser, ok, time()+7200, / );
header( Location: congratulations.html );
} else {
header( Location: go_away.html );
}
} else {
header( Location: go_away.html );
}
?
~Chris /\
\ / September 11, 2001
X We Are All New Yorkers
/ \ rm -rf /bin/laden
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
