Re: [PHP] Cookies sessions

2010-01-25 Thread Nisse Engström
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

2010-01-25 Thread Ashley Sheridan
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

2010-01-25 Thread Nisse Engström
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

2010-01-24 Thread Michael A. Peters

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

2010-01-24 Thread clancy_1
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

2010-01-23 Thread tedd

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

2010-01-23 Thread Nathan Rixham
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

2010-01-23 Thread Michael A. Peters

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

2010-01-23 Thread clancy_1
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

2010-01-23 Thread clancy_1
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

2010-01-22 Thread tedd

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

2010-01-22 Thread clancy_1
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

2010-01-22 Thread Michael A. Peters

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

2010-01-21 Thread clancy_1
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

2010-01-21 Thread Ashley Sheridan
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

2010-01-21 Thread Michael A. Peters

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

2010-01-20 Thread Ashley Sheridan
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

2010-01-20 Thread clancy_1
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

2010-01-20 Thread Ashley Sheridan
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-01-20 Thread Bruno Fajardo
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

2010-01-20 Thread Joseph Thayne

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

2010-01-20 Thread clancy_1
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

2010-01-19 Thread clancy_1
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-01-19 Thread Bruno Fajardo
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

2010-01-19 Thread kranthi
 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

2010-01-19 Thread Richard
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

2010-01-19 Thread Phpster

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

2010-01-19 Thread clancy_1
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

2010-01-19 Thread Phpster
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

2010-01-19 Thread clancy_1
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

2010-01-19 Thread clancy_1
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 and carts

2009-12-08 Thread Jochem Maas
Allen McCabe schreef:
 I have a shopping cart type system set up which keeps track of the cart
 contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
 equal to the quantity, so the name/value pair is all the information I need.
 
 But sessions are unreliable on the free server I am currently using for this
 website (not my choice), so I had start using cookies because users were
 being sporadically logged out, sometimes just on a page refresh.
 
 I want to find a way to set a cookie to remember the cart items as well, and
 I thought setting a cookie for each item/quantity pair was the way to go
 until I started trying to figure out how to unset all those cookies if the
 user empties their cart.
 
 Is there any way to set cookies with an array for the name? Intead of
 $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
 SESSION?

1. use one cookie for this (and other data)
2. DO NOT USE serialize()/unserialize() to pack/extract the data

using unserialize() opens you up to alsorts of potential hacks (IMHO), keep the 
data
structure simple and revalidate it's entire contents everytime you read it in
(assuming your article ids are INTs, all the data should be [valid] INTs - 
anything
else and the cookie should be deleted).

here is some code to play with: (written directly in my email client, no 
garantees is
parses or works as is)

?php

function buildCookieCartStr(array $data)
{
$out = array();
foreach ($data as $artId = $quant)
$out[] = $artId.':'.$quant;

return join('|', $out);
}

function parseCookieCartStr($s)
{
$data  = array();
$items = explode('|', $s);

if (!is_array($items))
return killCookieCart();

if (count($items)) foreach ($items as $item) {
$item = explode(':', $item);

if (is_array($item) || count($item) !== 2)
return killCookieCart();

foreach ($item as $v)
if (!$v || ($v != (int)$v))
return killCookieCart();

if (!isValidArtId($item[0]) || ($item[1]  1)
return killCookieCart();

if (isset($data[ $item[0] ]))
return killCookieCart();

$data[ $item[0] ] = $item[1];
}

return $data;
}

function killCookieCart()
{
// TODO: delete cookie
}

function isValidArtId($id)
{
return true; // TODO: valid article id
}

?

you can secure your code further by using the filter extension in combination
with a regexp filter in order to retrieve the cookie data from the request,
here's a regexp that matches only non empty strings with digit, colon and pipe 
chars:

#^[\d:\|]+$#




PS - hello again list.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] cookies and carts

2009-12-08 Thread Michael A. Peters

Allen McCabe wrote:

I have a shopping cart type system set up which keeps track of the cart
contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
equal to the quantity, so the name/value pair is all the information I need.

But sessions are unreliable on the free server I am currently using for this
website (not my choice), so I had start using cookies because users were
being sporadically logged out, sometimes just on a page refresh.


Have access to a database?
If yes, then run your own session management in the database.

This is what I use.
You don't want to use APC on a multiuser system, but this works without 
APC as well.


?php
//require_once(sessions_apc.php);
//$sess = new SessionManager($mdb2);
//session_start();

// from :
//  http://www.devshed.com/c/a/PHP/Storing-PHP-Sessions-in-a-Database/
//  Rich Smith - 2007-05-02
//
// Modified by mpet...@mac.com to use mdb2 w/ prepared statements
//  and attempt to use caching

class SessionManager {
   public  $sesstable = 'new_sessions';
   private $life_time;
   private $mdb2;
   // CHANGE THE SALT BEFORE USING
   private $apcSalt = '2d8lyds45a@0KLybafz';
   private $apcMaxLife = 1500; // delete from cache after that many seconds
// even if session still active
   function SessionManager($mdb2) {
  // constructor function
  // Read the maxlifetime setting from PHP
  $this-life_time = get_cfg_var(session.gc_maxlifetime);
  $this-mdb2 = $mdb2;

  // Register this object as the session handler
  session_set_save_handler(
 array( $this, open ),
 array( $this, close ),
 array( $this, read ),
 array( $this, write),
 array( $this, destroy),
 array( $this, gc )
 );
  }

   function open($save_path,$session_name) {
  global $sess_save_path;
  $sess_save_path = $save_path;
  // Don't need to do anything. Just return TRUE.
  return true;
  }

   function close() {
  return true;
  }

   function read($id) {
  // Set empty result
  $data = '';
  $myreturn = $this-wrap_fetch($id);
  if (! $myreturn) {
 // Fetch session data from the selected database
 $time = time();
 $types = Array('text','integer');
 $q = 'SELECT session_data FROM ' . $this-sesstable . ' WHERE 
session_id=? AND expires  ?';

 $sql = $this-mdb2-prepare($q,$types,MDB2_PREPARE_RESULT);
  //   if(PEAR::isError($sql)) {
  //  die('Failed to make prepared 58: ' . $sql-getMessage() . 
', ' . $sql-getDebugInfo());

  //  }
 $args = Array($id,$time);
 $rs = $sql-execute($args);
  //   if(PEAR::isError($rs)) {
  //  die('Failed to issue query 63: ' . $rs-getMessage() . ', 
' . $rs-getDebugInfo());

  //  }
 if ($rs-numRows()  0) {
$row = $rs-fetchRow(MDB2_FETCHMODE_OBJECT);
$myreturn = $row-session_data;
} else {
$myreturn = '';
}
 }
  return $myreturn;
  }

   function write($id,$data) {
  // Build query
  $time = time() + $this-life_time;

  // see if a session exists
  $sessTest = wrap_fetch($id);
  if (! $sessTest) {
 $types = Array('text');
 $q = 'SELECT COUNT(session_id) from ' . $this-sesstable . ' 
WHERE session_id=?';

 $sql = $this-mdb2-prepare($q,$types,MDB2_PREPARE_RESULT);
 //if (PEAR::isError($sql)) {
 //   die('Failed to make prepared 86: ' . $sql-getMessage() . 
', ' . $sql-getDebugInfo());

 //   }
 $args = Array($id);
 $rs = $sql-execute($args);
  //if(PEAR::isError($rs)) {
  //   die('Failed to issue query 91: ' . $rs-getMessage() . ', ' 
. $rs-getDebugInfo());

  //   }
 $row = $rs-fetchRow(MDB2_FETCHMODE_ORDERED);
 $count = $row[0];
 } else {
 $count = 1;
 }

 if ($count  0) {
 // update the session
 $types = Array('text','integer','text');
 $q = 'UPDATE ' . $this-sesstable . ' SET session_data=?, 
expires=? WHERE session_id=?';

 $args = Array($data,$time,$id);
 } else {
 $types = Array('text','text','integer');
 $q = 'INSERT INTO ' . $this-sesstable . ' 
(session_id,session_data,expires) VALUES (?,?,?)';

 $args = Array($id,$data,$time);
 }
  $sql = $this-mdb2-prepare($q,$types,MDB2_PREPARE_MANIP);
  //if(PEAR::isError($sql)) {
  //   die('Failed to make prepared 111: ' . $sql-getMessage() . 
', ' . $sql-getDebugInfo());

  //   }
  $rs = $sql-execute($args);
  //if(PEAR::isError($rs)) {
  //   die('Failed to issue query 115: ' . $rs-getMessage() . ', ' 
. $rs-getDebugInfo());

  //   }
  $this-wrap_store($id,$data);
  return TRUE;
  }

   function destroy($id) {
  // Build query
  $this-wrap_delete($id);
  $types = Array('text');
  $args  = Array($id);
   

[PHP] cookies and carts

2009-12-07 Thread Allen McCabe
I have a shopping cart type system set up which keeps track of the cart
contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
equal to the quantity, so the name/value pair is all the information I need.

But sessions are unreliable on the free server I am currently using for this
website (not my choice), so I had start using cookies because users were
being sporadically logged out, sometimes just on a page refresh.

I want to find a way to set a cookie to remember the cart items as well, and
I thought setting a cookie for each item/quantity pair was the way to go
until I started trying to figure out how to unset all those cookies if the
user empties their cart.

Is there any way to set cookies with an array for the name? Intead of
$_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
SESSION?


Re: [PHP] cookies and carts

2009-12-07 Thread Ashley Sheridan
On Mon, 2009-12-07 at 14:39 -0800, Allen McCabe wrote:

 I have a shopping cart type system set up which keeps track of the cart
 contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
 equal to the quantity, so the name/value pair is all the information I need.
 
 But sessions are unreliable on the free server I am currently using for this
 website (not my choice), so I had start using cookies because users were
 being sporadically logged out, sometimes just on a page refresh.
 
 I want to find a way to set a cookie to remember the cart items as well, and
 I thought setting a cookie for each item/quantity pair was the way to go
 until I started trying to figure out how to unset all those cookies if the
 user empties their cart.
 
 Is there any way to set cookies with an array for the name? Intead of
 $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
 SESSION?


What about storing a unique ID in the cookie, and matching it up with
information for that user in a database. It's sort of simulating a
sessions, but without the session handler getting involved, which looks
slightly messed up from what you've said.

Thanks,
Ash
http://www.ashleysheridan.co.uk




Re: [PHP] cookies and carts

2009-12-07 Thread Philip Thompson
On Dec 7, 2009, at 4:39 PM, Allen McCabe wrote:

 I have a shopping cart type system set up which keeps track of the cart
 contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
 equal to the quantity, so the name/value pair is all the information I need.
 
 But sessions are unreliable on the free server I am currently using for this
 website (not my choice), so I had start using cookies because users were
 being sporadically logged out, sometimes just on a page refresh.
 
 I want to find a way to set a cookie to remember the cart items as well, and
 I thought setting a cookie for each item/quantity pair was the way to go
 until I started trying to figure out how to unset all those cookies if the
 user empties their cart.
 
 Is there any way to set cookies with an array for the name? Intead of
 $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
 SESSION?

Don't do it this way. At some point (don't know if it's still true), IE had a 
limit of 20 cookies per domain - this includes cookie arrays. The proper way to 
do this would be to hold some sort of key in a cookie:

user_cart = 'some unique value for this user'

Then, in your PHP code, grab the value of $_COOKIE['user_cart'] to reference 
data in a database. Then, you pull the information from the database with this 
unique key and use it to display the appropriate items. This is the most secure 
way to do it (with the proper security measures ;) and it doesn't put 100's of 
needless cookies on the user's machine.

Hope this helps.
~Philip
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] cookies and carts

2009-12-07 Thread Philip Thompson
On Dec 7, 2009, at 4:40 PM, Ashley Sheridan wrote:

 On Mon, 2009-12-07 at 14:39 -0800, Allen McCabe wrote:
 
 I have a shopping cart type system set up which keeps track of the cart
 contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
 equal to the quantity, so the name/value pair is all the information I need.
 
 But sessions are unreliable on the free server I am currently using for this
 website (not my choice), so I had start using cookies because users were
 being sporadically logged out, sometimes just on a page refresh.
 
 I want to find a way to set a cookie to remember the cart items as well, and
 I thought setting a cookie for each item/quantity pair was the way to go
 until I started trying to figure out how to unset all those cookies if the
 user empties their cart.
 
 Is there any way to set cookies with an array for the name? Intead of
 $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
 SESSION?
 
 
 What about storing a unique ID in the cookie, and matching it up with
 information for that user in a database. It's sort of simulating a
 sessions, but without the session handler getting involved, which looks
 slightly messed up from what you've said.
 
 Thanks,
 Ash
 http://www.ashleysheridan.co.uk

Blast your speedier typing!! =P

~Philip


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] cookies and carts

2009-12-07 Thread Ashley Sheridan
On Mon, 2009-12-07 at 16:48 -0600, Philip Thompson wrote:

 On Dec 7, 2009, at 4:40 PM, Ashley Sheridan wrote:
 
  On Mon, 2009-12-07 at 14:39 -0800, Allen McCabe wrote:
  
  I have a shopping cart type system set up which keeps track of the cart
  contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
  equal to the quantity, so the name/value pair is all the information I 
  need.
  
  But sessions are unreliable on the free server I am currently using for 
  this
  website (not my choice), so I had start using cookies because users were
  being sporadically logged out, sometimes just on a page refresh.
  
  I want to find a way to set a cookie to remember the cart items as well, 
  and
  I thought setting a cookie for each item/quantity pair was the way to go
  until I started trying to figure out how to unset all those cookies if the
  user empties their cart.
  
  Is there any way to set cookies with an array for the name? Intead of
  $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have 
  the
  SESSION?
  
  
  What about storing a unique ID in the cookie, and matching it up with
  information for that user in a database. It's sort of simulating a
  sessions, but without the session handler getting involved, which looks
  slightly messed up from what you've said.
  
  Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 Blast your speedier typing!! =P
 
 ~Philip
 


By the power of Kenco!

Thanks,
Ash
http://www.ashleysheridan.co.uk




Re: [PHP] cookies and carts

2009-12-07 Thread Philip Thompson
On Dec 7, 2009, at 4:46 PM, Ashley Sheridan wrote:

 On Mon, 2009-12-07 at 16:48 -0600, Philip Thompson wrote:
 
 On Dec 7, 2009, at 4:40 PM, Ashley Sheridan wrote:
 
  On Mon, 2009-12-07 at 14:39 -0800, Allen McCabe wrote:
  
  I have a shopping cart type system set up which keeps track of the cart
  contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
  equal to the quantity, so the name/value pair is all the information I 
  need.
  
  But sessions are unreliable on the free server I am currently using for 
  this
  website (not my choice), so I had start using cookies because users were
  being sporadically logged out, sometimes just on a page refresh.
  
  I want to find a way to set a cookie to remember the cart items as well, 
  and
  I thought setting a cookie for each item/quantity pair was the way to go
  until I started trying to figure out how to unset all those cookies if the
  user empties their cart.
  
  Is there any way to set cookies with an array for the name? Intead of
  $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have 
  the
  SESSION?
  
  
  What about storing a unique ID in the cookie, and matching it up with
  information for that user in a database. It's sort of simulating a
  sessions, but without the session handler getting involved, which looks
  slightly messed up from what you've said.
  
  Thanks,
  Ash
  http://www.ashleysheridan.co.uk
 
 Blast your speedier typing!! =P
 
 ~Philip
 
 
 By the power of Kenco!
 
 Thanks,
 Ash
 http://www.ashleysheridan.co.uk
 

I hope you don't kiss your mother with that mouth!!



Re: [PHP] cookies and carts

2009-12-07 Thread Ashley Sheridan
On Mon, 2009-12-07 at 16:53 -0600, Philip Thompson wrote:

 On Dec 7, 2009, at 4:46 PM, Ashley Sheridan wrote:
 
  On Mon, 2009-12-07 at 16:48 -0600, Philip Thompson wrote:
  
  On Dec 7, 2009, at 4:40 PM, Ashley Sheridan wrote:
  
   On Mon, 2009-12-07 at 14:39 -0800, Allen McCabe wrote:
   
   I have a shopping cart type system set up which keeps track of the cart
   contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
   equal to the quantity, so the name/value pair is all the information I 
   need.
   
   But sessions are unreliable on the free server I am currently using for 
   this
   website (not my choice), so I had start using cookies because users were
   being sporadically logged out, sometimes just on a page refresh.
   
   I want to find a way to set a cookie to remember the cart items as 
   well, and
   I thought setting a cookie for each item/quantity pair was the way to go
   until I started trying to figure out how to unset all those cookies if 
   the
   user empties their cart.
   
   Is there any way to set cookies with an array for the name? Intead of
   $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I 
   have the
   SESSION?
   
   
   What about storing a unique ID in the cookie, and matching it up with
   information for that user in a database. It's sort of simulating a
   sessions, but without the session handler getting involved, which looks
   slightly messed up from what you've said.
   
   Thanks,
   Ash
   http://www.ashleysheridan.co.uk
  
  Blast your speedier typing!! =P
  
  ~Philip
  
  
  By the power of Kenco!
  
  Thanks,
  Ash
  http://www.ashleysheridan.co.uk
  
 
 I hope you don't kiss your mother with that mouth!!
 


Not a coffee man? :p

Thanks,
Ash
http://www.ashleysheridan.co.uk




Re: [PHP] cookies and carts

2009-12-07 Thread Paul M Foster
On Mon, Dec 07, 2009 at 02:39:28PM -0800, Allen McCabe wrote:

 I have a shopping cart type system set up which keeps track of the cart
 contents using a SESSION variable, where $_SESSION['cart'][$item_id'] is
 equal to the quantity, so the name/value pair is all the information I need.
 
 But sessions are unreliable on the free server I am currently using for this
 website (not my choice), so I had start using cookies because users were
 being sporadically logged out, sometimes just on a page refresh.
 
 I want to find a way to set a cookie to remember the cart items as well, and
 I thought setting a cookie for each item/quantity pair was the way to go
 until I started trying to figure out how to unset all those cookies if the
 user empties their cart.
 
 Is there any way to set cookies with an array for the name? Intead of
 $_COOKIE['item_number'] have $_COOKIE['cart']['item_number'] like I have the
 SESSION?

First, don't use multiple cookies; already covered elsewhere. Second,
you can serialize/unserialize array data and store it compactly in a
cookie. See the serialize() and unserialize() functions on php.net.

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

2009-03-10 Thread Chris



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

2009-03-10 Thread Michael A. Peters

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

2009-03-09 Thread Paul M Foster
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

2009-03-09 Thread Chris

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

2009-03-09 Thread APseudoUtopia
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

2009-03-09 Thread Chetan Rane
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

2009-03-09 Thread Paul M Foster
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



Re: [PHP] Cookies are now driving me crazy....

2007-11-28 Thread Brady Mitchell
On Nov 28, 2007 12:08 PM, Jason Pruim [EMAIL PROTECTED] wrote:
 if ($res) {
   // now see if user's id exists in database
 if (mysql_num_rows($res,0) {
You need another ) on that last line:

if (mysql_num_rows($res,0)) {

You might want to consider getting an editor/ide that will higlight
parse errors for you, makes life much easier. :)

My ide of choice is EasyEclipse for PHP (
http://www.easyeclipse.org/site/distributions/php.html ), and there
are lots of other great editors out there too. This is not meant to
start another my editor is better than yours thread, just a
suggestion.

Brady

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies are now driving me crazy....

2007-11-28 Thread Daniel Brown
On Nov 28, 2007 3:19 PM, Brady Mitchell [EMAIL PROTECTED] wrote:
 On Nov 28, 2007 12:08 PM, Jason Pruim [EMAIL PROTECTED] wrote:
  if ($res) {
// now see if user's id exists in database
  if (mysql_num_rows($res,0) {
 You need another ) on that last line:

 if (mysql_num_rows($res,0)) {

 You might want to consider getting an editor/ide that will higlight
 parse errors for you, makes life much easier. :)

 My ide of choice is EasyEclipse for PHP (
 http://www.easyeclipse.org/site/distributions/php.html ), and there
 are lots of other great editors out there too. This is not meant to
 start another my editor is better than yours thread, just a
 suggestion.

 Brady


 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php



Should go without saying that I noticed the problem immediately
after I sent the message before.  I had commented out the MySQL stuff
and the function call to get it to run without kicking out errors on
there.  My goof.

-- 
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies are now driving me crazy....

2007-11-28 Thread Jason Pruim


On Nov 28, 2007, at 3:19 PM, Brady Mitchell wrote:


On Nov 28, 2007 12:08 PM, Jason Pruim [EMAIL PROTECTED] wrote:

if ($res) {
 // now see if user's id exists in database
   if (mysql_num_rows($res,0) {

You need another ) on that last line:

if (mysql_num_rows($res,0)) {

You might want to consider getting an editor/ide that will higlight
parse errors for you, makes life much easier. :)

My ide of choice is EasyEclipse for PHP (
http://www.easyeclipse.org/site/distributions/php.html ), and there
are lots of other great editors out there too. This is not meant to
start another my editor is better than yours thread, just a
suggestion.



Thanks for spotting it! I think I may need something other then  
dreamweaver to code in... All I use it for is it's syntax  
highlighting... I do all my coding by hand...  But I think I'll start  
looking at others :)


Off to google! :)


--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
[EMAIL PROTECTED]


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies are now driving me crazy....

2007-11-28 Thread Daniel Brown
On Nov 28, 2007 3:08 PM, Jason Pruim [EMAIL PROTECTED] wrote:
 I have some code which I'll paste at the end of the e-mail that is
 throwing an error and I can't seem to find where the error is... Here
 is the error: [Wed Nov 28 15:03:19 2007] [error] PHP Parse error:
 syntax error, unexpected '{' in /Volumes/RAIDer/webserver/Documents/
 OLDB/customer/test/detectuser.php on line 27

 Now... I realize that it's not expecting a '{' on line 27... But I
 checked the brackets, and from what I can tell, they all look
 balanced...Any help is appreciated!



 ?php
 include('defaults.php');
 include('dbconnect.php');
   //see if detectuser.php has been required, not URL'd.
 if ($legal_require_php!=1234) exit;
   // setup global variable $global_user_id, set it to 0, which means
 no user as auto_increment IDs in MySQL begin with 1
   $global_user_id= 0;
   // now, check if user's computer has the cookie set
 if (isset($_COOKIE['cookiename'])) {
 $cookieval= $_COOKIE['cookiename'];
 //now parse the ID:LOGCODE value in cooke via explode() function
 $cookieparsed= explode (:, $cookieval);
 // $cookie_uid will hold user's id
 // $cookie_code will hold user's last reported logcode
 $cookie_uid= $cookieparsed[0];
 $cookie_code= $cookieparsed[1];
// ensure that ID from cookie is a numeric value
 if (is_numeric($cookie_uid)) {
 //now, find the user via his ID
 $res= mysql_query(SELECT logcode FROM MainLogin WHERE id=$cookie_uid);
 // no die() this time, we will redirect if error occurs
 if ($res) {
   // now see if user's id exists in database
 if (mysql_num_rows($res,0) {
$logcode_in_base= mysql_result($res, 0);
// now compare LOGCODES in cookie against the one in database
if ($logcode_in_base == $cookie_code) {
 // if valid, generate new logcode and update database
 $newcode= md5(func_generate_string());
 $res= mysql_query(UPDATE MainLogin SET logcode='$newcode' WHERE
 id=$cookie_uid);
 // setup new cookie (replace the old one)
 $newval= $cookie_uid:$newcode;
 setcookie(cookiename, $newval, time() + 300, /oldb/,
 .raoset.com);
 // finally, setup global var to reflect user's id
 $global_user_id= $cookie_uid;
} else {
 // redirect if logcodes are not equal
 echo Logcodes are not equal;
}
   } else {
// redirect if user ID does not exist in database
echo User not in database;
   }
   } else {
// redirect in case of database error
echo database error;
   }
 } else {
   // redirect if user ID in cookie not numeric
   echo Cookie not numeric;
 }
   }
 ?
 --

 Jason Pruim
 Raoset Inc.
 Technology Manager
 MQC Specialist
 3251 132nd ave
 Holland, MI, 49424
 www.raoset.com
 [EMAIL PROTECTED]

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




Jason,

That generally means you forgot to close out a closing param.
However, I ran your code just fine.  Is the name of that script
`detectuser.php` or is that somehow else included?

-- 
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies are now driving me crazy....

2007-11-28 Thread Jason Pruim
I have some code which I'll paste at the end of the e-mail that is  
throwing an error and I can't seem to find where the error is... Here  
is the error: [Wed Nov 28 15:03:19 2007] [error] PHP Parse error:   
syntax error, unexpected '{' in /Volumes/RAIDer/webserver/Documents/ 
OLDB/customer/test/detectuser.php on line 27


Now... I realize that it's not expecting a '{' on line 27... But I  
checked the brackets, and from what I can tell, they all look  
balanced...Any help is appreciated!




?php
include('defaults.php');
include('dbconnect.php');
 //see if detectuser.php has been required, not URL’d.
if ($legal_require_php!=1234) exit;
 // setup global variable $global_user_id, set it to 0, which means  
no user as auto_increment IDs in MySQL begin with 1

 $global_user_id= 0;
 // now, check if user’s computer has the cookie set
if (isset($_COOKIE['cookiename'])) {
$cookieval= $_COOKIE['cookiename'];
//now parse the ID:LOGCODE value in cooke via explode() function
$cookieparsed= explode (:, $cookieval);
// $cookie_uid will hold user’s id
// $cookie_code will hold user’s last reported logcode
$cookie_uid= $cookieparsed[0];
$cookie_code= $cookieparsed[1];
  // ensure that ID from cookie is a numeric value
if (is_numeric($cookie_uid)) {
//now, find the user via his ID
$res= mysql_query(SELECT logcode FROM MainLogin WHERE id=$cookie_uid);
// no die() this time, we will redirect if error occurs
if ($res) {
 // now see if user’s id exists in database
   if (mysql_num_rows($res,0) {
  $logcode_in_base= mysql_result($res, 0);
  // now compare LOGCODES in cookie against the one in database
  if ($logcode_in_base == $cookie_code) {
   // if valid, generate new logcode and update database
   $newcode= md5(func_generate_string());
   $res= mysql_query(UPDATE MainLogin SET logcode='$newcode' WHERE  
id=$cookie_uid);

   // setup new cookie (replace the old one)
   $newval= $cookie_uid:$newcode;
   setcookie(cookiename, $newval, time() + 300, /oldb/,  
.raoset.com);

   // finally, setup global var to reflect user’s id
   $global_user_id= $cookie_uid;
  } else {
   // redirect if logcodes are not equal
   echo Logcodes are not equal;
  }
 } else {
  // redirect if user ID does not exist in database
  echo User not in database;
 }
 } else {
  // redirect in case of database error
  echo database error;
 }
} else {
 // redirect if user ID in cookie not numeric
 echo Cookie not numeric;
}
 }
?
--

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
[EMAIL PROTECTED]

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-20 Thread Wouter van Vliet / Interpotential
On 20/08/07, tedd [EMAIL PROTECTED] wrote:

 At 10:40 PM +0200 8/19/07, Wouter van Vliet / Interpotential wrote:
 What you're proposing, is to actually display some content on another
 page
 then were the content is originally intended? I'm sorry, but I would
 consider that 'bad practice'. To me, it makes perfect sense that you
 don't
 want to leave the user on the page where login was originally handled.
 For
 various reasons. One very obvious would be the 'refresh thing', where
 your
 browser asks the user if they want to send the form again. Quite
 annoying.
 Then, what about bookmarks? ...


 No, what I had proposed was an alternate method to accomplish what
 you said you wanted. But, it appears that my efforts and the demo did
 not receive sufficient attention for you to understand what wass
 being presented. Instead, you tell me that what I've shown you is bad
 practice -- interesting.


First of all - I didn't ask the initial question ;-). Other than that, I
think our philosophies our basically the same. But when you say that you are
redirecting the user to another page, while you are actually including a php
script - that's not my understanding of redirecting.

You said that you wanted to remove login from the browser history,
 which is screwing around with the user's browser and is clearly bad
 practice.


Generally yes, removing a page from the browser's history would be
considered bad practice. However, we are not really talking about a page
here. What I understood from the initial question is as follows:

 - http://www.site.com/ contains some login form, action of that form is
(for example) /login.php
 - The user is sent to /login.php where the login is checked
 - From there, the user either gets to a content page where it would
typically show welcome {user} or something, or back to the index page when
login failed
 - As you see, login.php is not really a page but more of a 'pseudo page'
and therefore I cannot see any reason not to send a proper 303 header. see:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

My method simply stops the user from visiting the same page more than
 once during a session and leaves their browser data alone -- nothing
 bad practice about that!

 AFTER my demo runs, if you repeatedly refresh the page you are
 directed to, then certainly that would become annoying. But that
 wasn't the intent, nor part of the demo, which you clearly didn't
 read and obviously didn't understand.

 As far as bookmarking the page, but of course you can bookmark the
 page! Did you even try?

 Oh well, so much for trying to help someone understand sessions. As
 my mother often said No good deed ever goes unpunished.


I've got another one, There is no selfless good deed.

If you had simply said, I don't understand, please explain; or asked
 a question or two; or said thanks, but no thanks, I'm going to do it
 another way, then that would have been fine. But to say that the demo
 I prepared for you exhibited bad practice, especially when you are
 absolutely friggen clueless as to what it is doing, is a bit too much
 -- I'll be sure to pass over your post in the future.


I don't think there wasn't anybody who didn't appriciate your suggestion.
Only thing I was trying to do was chip in my two cents. Again, I wasn't the
one who originally asked the question and I certainly am not friggen
clueless. I just came to think about what the teacher at my Flex course
from a couple of months ago said about good and bad practice. He said
there is none. If your solution works good for you, that's your good
practice. And if mine doesn't work for you, it's your bad practice - while
it is still my good practice.

Something however I am trying to fight against, if you let me put it like
that - is people approaching scripts as if they are pages. When you are
including a script that is usually called as a page into another script
you should be very aware for any clashes between variables. Another reason
why it may be easier to just put in a Location: header and call your script
as it was originally intended.

Wouter

tedd

 ---

 
 I would definately go for the Location: header solution!
 
 On 19/08/07, tedd [EMAIL PROTECTED] wrote:
 
   At 8:52 AM +0200 8/19/07, Otto Wyss wrote:
   In my case I could easilly do without redirection but just exit and
   fall back on the calling page. Yet I want to remove the login page
   from the browser history. Does the header function have the same
   effect?
   
 
   O. Wyss:
 
   Instead of messing with the user's browser (not good IMO), why not
   use $_SESSION and make it such that if the user selects the log-on
   page again, they are redirected to another page? You don't even need
   header() to do that.
 
   Here's an example:
 
http://webbytedd.com/bb/one-time
 
   You will only see that page only once -- unless you find a way to
   clear the session.
 
   The process is simply to set a session variable and allow the user to
   see the page once. Upon 

Re: [PHP] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-20 Thread tedd

At 12:42 PM +0200 8/20/07, Wouter van Vliet / Interpotential wrote:
Only thing I was trying to do was chip in my two cents. Again, I 
wasn't the one who originally asked the question and I certainly am 
not friggen clueless.


Maybe not, but you made some pretty clueless remarks -- like if you 
could book-mark the page, the annoying refresh remark, and saying the 
demo displayed bad practice. None were germane to the intent of the 
demo, let alone valid.



I just came to think about what the teacher at my Flex course from a 
couple of months ago said about good and bad practice. He said 
there is none. If your solution works good for you, that's your good 
practice. And if mine doesn't work for you, it's your bad practice - 
while it is still my good practice.


That's just an excuse to do what you want and call it good -- but, 
there are good and bad practices.


Something however I am trying to fight against, if you let me put 
it like that - is people approaching scripts as if they are 
pages. When you are including a script that is usually called as 
a page into another script you should be very aware for any clashes 
between variables. Another reason why it may be easier to just put 
in a Location: header and call your script as it was originally 
intended.


Now, I'm clueless as to what you're talking about.

I think most people agree as to what a web page is and if we are 
using web languages to communicate with the user, then that is our 
medium. There are many ways to use web pages and Location: is only 
one of them. Limit yourself as you see fit.


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 and sent headers

2007-08-19 Thread Otto Wyss

M. Sokolewicz wrote:
On a sidenote, 99% of the world never calls ob_flush (or any such 
function) since PHP flushes the buffer automatically at the end of its 
execution.


I'll keep the ob_end_flush just for showing what's going on, but thanks 
for the hint.


The reason why setting cookies for you doesn't work is because of the 
way a HTTP response is structured. It consists of 2 parts: header and 
body separated by 2 new lines (\n\n). It is _required_ that _all_ 
headers come _before_ the body. Cookies are actually headers (a 
set-cookie: [...] header) aswell as any headers set via php's header() 
function. Any output made by the script (be it a single whitespace, a 
bunch of text, etc.) will automatically flush the headers, followed by 
the separator (\n\n) followed by the specified output. After that has 
been sent, everything outputted will be dumped into the body of the 
response (simply because you can't go back to the headers which were 
already sent earlier), so you can't set cookies (which are headers 
themselves).



Thanks, now it's understandable.

So, why does output buffering help here? Simply put, instead of dumping 
headers and any other output directly to the client, PHP buffers it all 
into memory. As such, since it hasn't been sent yet, PHP can still 
alter/add headers even though it also has body-output. Once it receives 
the command, PHP will send all headers, the separator and the output to 
the client. This is done when PHP encounters an ob_flush or ob_end_flush 
call, _and_ when the script has finished execution automatically.


The documentation seems pretty clear to me, however, if you feel it 
should be clarified better, feel free to send a patch to the 
[EMAIL PROTECTED] list.


- Tul


O. Wyss

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-19 Thread Otto Wyss

M. Sokolewicz wrote:

emits). Now, I'm not going to go into how redirecting that way won't
work (or at least shouldn't), but a hint would be to do it properly
using header('Location: [...]') instead.


I'm aware that using Javascript within a PHP code block doesn't seems
logical yet I haven't known header ('Location...). In my case I could 
easilly do without redirection but just exit and fall back on the 
calling page. Yet I want to remove the login page from the browser 
history. Does the header function have the same effect?


O. Wyss

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies and sent headers

2007-08-19 Thread Nisse Engström
On Sat, 18 Aug 2007 17:03:35 +0200, M. Sokolewicz wrote:

 The reason why setting cookies for you doesn't work is because of the 
 way a HTTP response is structured. It consists of 2 parts: header and 
 body separated by 2 new lines (\n\n). It is _required_ that _all_ 
 headers come _before_ the body. Cookies are actually headers (a 

   Actually, it is perfectly possible (in theory) to
send most headers _after_ the body. See RFC 2616,
sections 14.40, 3.6.1 and 14.39. I don't think it is
possible with (non-nph) PHP though.


/Nisse

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-19 Thread tedd

At 8:52 AM +0200 8/19/07, Otto Wyss wrote:
In my case I could easilly do without redirection but just exit and 
fall back on the calling page. Yet I want to remove the login page 
from the browser history. Does the header function have the same 
effect?




O. Wyss:

Instead of messing with the user's browser (not good IMO), why not 
use $_SESSION and make it such that if the user selects the log-on 
page again, they are redirected to another page? You don't even need 
header() to do that.


Here's an example:

http://webbytedd.com/bb/one-time

You will only see that page only once -- unless you find a way to 
clear the session.


The process is simply to set a session variable and allow the user to 
see the page once. Upon returning, the session variable is checked 
and if it is not null, then the user is redirected to another page 
like so:


if($visit != null)
{
ob_clean();
include('a.php');
exit(0);
}

Very simple.

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] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-19 Thread Wouter van Vliet / Interpotential
What you're proposing, is to actually display some content on another page
then were the content is originally intended? I'm sorry, but I would
consider that 'bad practice'. To me, it makes perfect sense that you don't
want to leave the user on the page where login was originally handled. For
various reasons. One very obvious would be the 'refresh thing', where your
browser asks the user if they want to send the form again. Quite annoying.
Then, what about bookmarks? ...

I would definately go for the Location: header solution!

On 19/08/07, tedd [EMAIL PROTECTED] wrote:

 At 8:52 AM +0200 8/19/07, Otto Wyss wrote:
 In my case I could easilly do without redirection but just exit and
 fall back on the calling page. Yet I want to remove the login page
 from the browser history. Does the header function have the same
 effect?
 

 O. Wyss:

 Instead of messing with the user's browser (not good IMO), why not
 use $_SESSION and make it such that if the user selects the log-on
 page again, they are redirected to another page? You don't even need
 header() to do that.

 Here's an example:

 http://webbytedd.com/bb/one-time

 You will only see that page only once -- unless you find a way to
 clear the session.

 The process is simply to set a session variable and allow the user to
 see the page once. Upon returning, the session variable is checked
 and if it is not null, then the user is redirected to another page
 like so:

 if($visit != null)
 {
 ob_clean();
 include('a.php');
 exit(0);
 }

 Very simple.

 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




-- 
Interpotential.com
Phone: +31615397471


Re: [PHP] Redirection with header (was Re: [PHP] Cookies and sent headers)

2007-08-19 Thread tedd

At 10:40 PM +0200 8/19/07, Wouter van Vliet / Interpotential wrote:

What you're proposing, is to actually display some content on another page
then were the content is originally intended? I'm sorry, but I would
consider that 'bad practice'. To me, it makes perfect sense that you don't
want to leave the user on the page where login was originally handled. For
various reasons. One very obvious would be the 'refresh thing', where your
browser asks the user if they want to send the form again. Quite annoying.
Then, what about bookmarks? ...



No, what I had proposed was an alternate method to accomplish what 
you said you wanted. But, it appears that my efforts and the demo did 
not receive sufficient attention for you to understand what wass 
being presented. Instead, you tell me that what I've shown you is bad 
practice -- interesting.


You said that you wanted to remove login from the browser history, 
which is screwing around with the user's browser and is clearly bad 
practice.


My method simply stops the user from visiting the same page more than 
once during a session and leaves their browser data alone -- nothing 
bad practice about that!


AFTER my demo runs, if you repeatedly refresh the page you are 
directed to, then certainly that would become annoying. But that 
wasn't the intent, nor part of the demo, which you clearly didn't 
read and obviously didn't understand.


As far as bookmarking the page, but of course you can bookmark the 
page! Did you even try?


Oh well, so much for trying to help someone understand sessions. As 
my mother often said No good deed ever goes unpunished.


If you had simply said, I don't understand, please explain; or asked 
a question or two; or said thanks, but no thanks, I'm going to do it 
another way, then that would have been fine. But to say that the demo 
I prepared for you exhibited bad practice, especially when you are 
absolutely friggen clueless as to what it is doing, is a bit too much 
-- I'll be sure to pass over your post in the future.


tedd

---



I would definately go for the Location: header solution!

On 19/08/07, tedd [EMAIL PROTECTED] wrote:


 At 8:52 AM +0200 8/19/07, Otto Wyss wrote:
 In my case I could easilly do without redirection but just exit and
 fall back on the calling page. Yet I want to remove the login page
 from the browser history. Does the header function have the same
 effect?
 

 O. Wyss:

 Instead of messing with the user's browser (not good IMO), why not
 use $_SESSION and make it such that if the user selects the log-on
 page again, they are redirected to another page? You don't even need
 header() to do that.

 Here's an example:


  http://webbytedd.com/bb/one-time


 You will only see that page only once -- unless you find a way to
 clear the session.

 The process is simply to set a session variable and allow the user to
 see the page once. Upon returning, the session variable is checked
 and if it is not null, then the user is redirected to another page
 like so:

 if($visit != null)
 {
 ob_clean();
 include('a.php');
 exit(0);
 }

 Very simple.

 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





--
Interpotential.com
Phone: +31615397471



--
---
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



[PHP] Cookies and sent headers

2007-08-18 Thread Otto Wyss
If built a simple login page and store any information within 
$_SESSION's. Yet I'd like to move these into cookies but I always get an 
error about sent headers. Is there a way to circumvent this problem 
without changing too much in the page?


The setting of the cookies happens just at the end of the page.

  if (!$errortext and $Anmelden) {
if (!empty($Permanent)) {
  $expires = time()+ 365 * 86400;  // 365 days
  setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
  setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
  setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
  setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
}
echo script type=\text/javascript\
  parent.location.replace('$index_php;
  /script;
exit;
  }

O. Wyss

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies and sent headers

2007-08-18 Thread Kelvin Park

Kelvin Park wrote:

Otto Wyss wrote:
If built a simple login page and store any information within 
$_SESSION's. Yet I'd like to move these into cookies but I always get 
an error about sent headers. Is there a way to circumvent this 
problem without changing too much in the page?


The setting of the cookies happens just at the end of the page.

  if (!$errortext and $Anmelden) {
if (!empty($Permanent)) {
  $expires = time()+ 365 * 86400;  // 365 days
  setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
  setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
  setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
  setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
}
echo script type=\text/javascript\
  parent.location.replace('$index_php;
  /script;
exit;
  }

O. Wyss


ob_start() might help



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies and sent headers

2007-08-18 Thread Wouter van Vliet / Interpotential
You best option would be to go through all of your include'd or require'd
files and make sure there is no whitespace before and after you open your
php tags. Those are often the cause for such problems. The easy way would
indeed be to use output buffering. In that case, put the call to ob_start();
on the first line of the file you're calling. You will still have to make
sure to not have any whitespace before your ?php opening.

To even bypass that, the output_buffering ini setting might be useful. Alter
it in your php.ini if you can, otherwise try your apache vhost configuration
or .htaccess. The syntax there is:

 php_flag output_buffering On

Good luck!

On 18/08/07, Kelvin Park [EMAIL PROTECTED] wrote:

 Kelvin Park wrote:
  Otto Wyss wrote:
  If built a simple login page and store any information within
  $_SESSION's. Yet I'd like to move these into cookies but I always get
  an error about sent headers. Is there a way to circumvent this
  problem without changing too much in the page?
 
  The setting of the cookies happens just at the end of the page.
 
if (!$errortext and $Anmelden) {
  if (!empty($Permanent)) {
$expires = time()+ 365 * 86400;  // 365 days
setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
  }
  echo script type=\text/javascript\
parent.location.replace('$index_php;
/script;
  exit;
}
 
  O. Wyss
 
  ob_start() might help
 

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Interpotential.com
Phone: +31615397471


RE: [PHP] Cookies and sent headers

2007-08-18 Thread Bastien Koert

sessions and cookies either need to be set at the beginning of the page, or you 
can look into the ob_start(), ob_flush() functions to use output buffering


bastien


 To: php-general@lists.php.net
 Date: Sat, 18 Aug 2007 11:25:54 +0200
 From: [EMAIL PROTECTED]
 Subject: [PHP] Cookies and sent headers
 
 If built a simple login page and store any information within 
 $_SESSION's. Yet I'd like to move these into cookies but I always get an 
 error about sent headers. Is there a way to circumvent this problem 
 without changing too much in the page?
 
 The setting of the cookies happens just at the end of the page.
 
if (!$errortext and $Anmelden) {
  if (!empty($Permanent)) {
$expires = time()+ 365 * 86400;  // 365 days
setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
  }
  echo ;
  exit;
}
 
 O. Wyss
 
 -- 
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php
 

_
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+worldmkt=en-USform=QBRE
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies and sent headers

2007-08-18 Thread Otto Wyss
ob_start() at the beginning and ob_end_flush() at the end of the PHP 
section seems to do the trick albeit I've still problems to understand 
why. The description in the manual is rather sparse unfortunately. Is 
there any more information about what's going on?


O. Wyss

Wouter van Vliet / Interpotential wrote:

You best option would be to go through all of your include'd or require'd
files and make sure there is no whitespace before and after you open your
php tags. Those are often the cause for such problems. The easy way would
indeed be to use output buffering. In that case, put the call to ob_start();
on the first line of the file you're calling. You will still have to make
sure to not have any whitespace before your ?php opening.

To even bypass that, the output_buffering ini setting might be useful. Alter
it in your php.ini if you can, otherwise try your apache vhost configuration
or .htaccess. The syntax there is:

 php_flag output_buffering On

Good luck!

On 18/08/07, Kelvin Park [EMAIL PROTECTED] wrote:

Kelvin Park wrote:

Otto Wyss wrote:

If built a simple login page and store any information within
$_SESSION's. Yet I'd like to move these into cookies but I always get
an error about sent headers. Is there a way to circumvent this
problem without changing too much in the page?

The setting of the cookies happens just at the end of the page.

  if (!$errortext and $Anmelden) {
if (!empty($Permanent)) {
  $expires = time()+ 365 * 86400;  // 365 days
  setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
  setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
  setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
  setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
}
echo script type=\text/javascript\
  parent.location.replace('$index_php;
  /script;
exit;
  }

O. Wyss


ob_start() might help


--
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 and sent headers

2007-08-18 Thread Bastien Koert


The commands start and use an output buffer, a chunk of memory that stores all 
the output on the server until the ob_flush, the buffer flush, function is 
called. You need to be aware that in high load situations this may adversly 
affect performance since it loads the servers memory, also be aware that you 
may hit a memory limit for large pages. This is server / OS depandant so you 
may want to read up on server documentation

bastien




 To: php-general@lists.php.net; [EMAIL PROTECTED]
 Date: Sat, 18 Aug 2007 16:39:29 +0200
 From: [EMAIL PROTECTED]
 CC: [EMAIL PROTECTED]; php-general@lists.php.net
 Subject: Re: [PHP] Cookies and sent headers
 
 ob_start() at the beginning and ob_end_flush() at the end of the PHP 
 section seems to do the trick albeit I've still problems to understand 
 why. The description in the manual is rather sparse unfortunately. Is 
 there any more information about what's going on?
 
 O. Wyss
 
 Wouter van Vliet / Interpotential wrote:
  You best option would be to go through all of your include'd or require'd
  files and make sure there is no whitespace before and after you open your
  php tags. Those are often the cause for such problems. The easy way would
  indeed be to use output buffering. In that case, put the call to ob_start();
  on the first line of the file you're calling. You will still have to make
  sure to not have any whitespace before your   
  To even bypass that, the output_buffering ini setting might be useful. Alter
  it in your php.ini if you can, otherwise try your apache vhost configuration
  or .htaccess. The syntax there is:
  
   php_flag output_buffering On
  
  Good luck!
  
  On 18/08/07, Kelvin Park  wrote:
  Kelvin Park wrote:
  Otto Wyss wrote:
  If built a simple login page and store any information within
  $_SESSION's. Yet I'd like to move these into cookies but I always get
  an error about sent headers. Is there a way to circumvent this
  problem without changing too much in the page?
 
  The setting of the cookies happens just at the end of the page.
 
if (!$errortext and $Anmelden) {
  if (!empty($Permanent)) {
$expires = time()+ 365 * 86400;  // 365 days
setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
  }
  echo ;
  exit;
}
 
  O. Wyss
 
  ob_start() might help
 
  --
  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
 

_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies and sent headers

2007-08-18 Thread M. Sokolewicz
On a sidenote, 99% of the world never calls ob_flush (or any such 
function) since PHP flushes the buffer automatically at the end of its 
execution.


The reason why setting cookies for you doesn't work is because of the 
way a HTTP response is structured. It consists of 2 parts: header and 
body separated by 2 new lines (\n\n). It is _required_ that _all_ 
headers come _before_ the body. Cookies are actually headers (a 
set-cookie: [...] header) aswell as any headers set via php's header() 
function. Any output made by the script (be it a single whitespace, a 
bunch of text, etc.) will automatically flush the headers, followed by 
the separator (\n\n) followed by the specified output. After that has 
been sent, everything outputted will be dumped into the body of the 
response (simply because you can't go back to the headers which were 
already sent earlier), so you can't set cookies (which are headers 
themselves).


So, why does output buffering help here? Simply put, instead of dumping 
headers and any other output directly to the client, PHP buffers it all 
into memory. As such, since it hasn't been sent yet, PHP can still 
alter/add headers even though it also has body-output. Once it receives 
the command, PHP will send all headers, the separator and the output to 
the client. This is done when PHP encounters an ob_flush or ob_end_flush 
call, _and_ when the script has finished execution automatically.


The documentation seems pretty clear to me, however, if you feel it 
should be clarified better, feel free to send a patch to the 
[EMAIL PROTECTED] list.


- Tul


Bastien Koert wrote:


The commands start and use an output buffer, a chunk of memory that stores all 
the output on the server until the ob_flush, the buffer flush, function is 
called. You need to be aware that in high load situations this may adversly 
affect performance since it loads the servers memory, also be aware that you 
may hit a memory limit for large pages. This is server / OS depandant so you 
may want to read up on server documentation

bastien





To: php-general@lists.php.net; [EMAIL PROTECTED]
Date: Sat, 18 Aug 2007 16:39:29 +0200
From: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]; php-general@lists.php.net
Subject: Re: [PHP] Cookies and sent headers

ob_start() at the beginning and ob_end_flush() at the end of the PHP 
section seems to do the trick albeit I've still problems to understand 
why. The description in the manual is rather sparse unfortunately. Is 
there any more information about what's going on?


O. Wyss

Wouter van Vliet / Interpotential wrote:

You best option would be to go through all of your include'd or require'd
files and make sure there is no whitespace before and after you open your
php tags. Those are often the cause for such problems. The easy way would
indeed be to use output buffering. In that case, put the call to ob_start();
on the first line of the file you're calling. You will still have to make
sure to not have any whitespace before your   
To even bypass that, the output_buffering ini setting might be useful. Alter

it in your php.ini if you can, otherwise try your apache vhost configuration
or .htaccess. The syntax there is:

 php_flag output_buffering On

Good luck!

On 18/08/07, Kelvin Park  wrote:

Kelvin Park wrote:

Otto Wyss wrote:

If built a simple login page and store any information within
$_SESSION's. Yet I'd like to move these into cookies but I always get
an error about sent headers. Is there a way to circumvent this
problem without changing too much in the page?

The setting of the cookies happens just at the end of the page.

  if (!$errortext and $Anmelden) {
if (!empty($Permanent)) {
  $expires = time()+ 365 * 86400;  // 365 days
  setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
  setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
  setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
  setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
}
echo ;
exit;
  }

O. Wyss


ob_start() might help


--
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



_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Cookies and sent headers

2007-08-18 Thread Sanjeev N
Hi,
Its not the problem of cookies. Its problem of redirection or the
parent.location.replace function. I mean if you already output something on
the page and tries to redirect then this problem happens.

Redirect before outputting anything on the page.. like space is also an
output.

Warm Regards,
Sanjeev
http://www.sanchanworld.com/
http://webdirectory.sanchanworld.com - Submit your website URL
http://webhosting.sanchanworld.com - Choose your best web hosting plan
-Original Message-
From: Otto Wyss [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 18, 2007 2:56 PM
To: php-general@lists.php.net
Subject: [PHP] Cookies and sent headers

If built a simple login page and store any information within 
$_SESSION's. Yet I'd like to move these into cookies but I always get an 
error about sent headers. Is there a way to circumvent this problem 
without changing too much in the page?

The setting of the cookies happens just at the end of the page.

   if (!$errortext and $Anmelden) {
 if (!empty($Permanent)) {
   $expires = time()+ 365 * 86400;  // 365 days
   setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
   setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
   setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
   setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
 }
 echo script type=\text/javascript\
   parent.location.replace('$index_php;
   /script;
 exit;
   }

O. Wyss

-- 
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 and sent headers

2007-08-18 Thread M. Sokolewicz

bullshit,

what he sees is a warning emitted by PHP, his redirect is done using 
JavaScript (which is clientside and has no, 0.0 effect on what PHP 
emits). Now, I'm not going to go into how redirecting that way won't 
work (or at least shouldn't), but a hint would be to do it properly 
using header('Location: [...]') instead.


- Tul


Sanjeev N wrote:

Hi,
Its not the problem of cookies. Its problem of redirection or the
parent.location.replace function. I mean if you already output something on
the page and tries to redirect then this problem happens.

Redirect before outputting anything on the page.. like space is also an
output.

Warm Regards,
Sanjeev
http://www.sanchanworld.com/
http://webdirectory.sanchanworld.com - Submit your website URL
http://webhosting.sanchanworld.com - Choose your best web hosting plan
-Original Message-
From: Otto Wyss [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 18, 2007 2:56 PM

To: php-general@lists.php.net
Subject: [PHP] Cookies and sent headers

If built a simple login page and store any information within 
$_SESSION's. Yet I'd like to move these into cookies but I always get an 
error about sent headers. Is there a way to circumvent this problem 
without changing too much in the page?


The setting of the cookies happens just at the end of the page.

   if (!$errortext and $Anmelden) {
 if (!empty($Permanent)) {
   $expires = time()+ 365 * 86400;  // 365 days
   setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
   setcookie (l.Firstname, $_SESSION['l_Firstname'], $expires);
   setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
   setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
 }
 echo script type=\text/javascript\
   parent.location.replace('$index_php;
   /script;
 exit;
   }

O. Wyss



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Fwd: [PHP] Cookies and sent headers

2007-08-18 Thread Kelvin Park
-- Forwarded message --
From: Kelvin Park [EMAIL PROTECTED]
Date: Aug 18, 2007 4:34 PM
Subject: Re: [PHP] Cookies and sent headers
To: M. Sokolewicz [EMAIL PROTECTED]

the javascript code can definitely change to head(location: whatever.php)
for redirection, if that's the solution, that would be the way to go, but if
you're encountering quite similar problems later you can try ob_start() or
whatever that was recommended in the comments before M. Sokolewicz's
bullshitting comment.

On 8/18/07, M. Sokolewicz [EMAIL PROTECTED] wrote:

 bullshit,

 what he sees is a warning emitted by PHP, his redirect is done using
 JavaScript (which is clientside and has no, 0.0 effect on what PHP
 emits). Now, I'm not going to go into how redirecting that way won't
 work (or at least shouldn't), but a hint would be to do it properly
 using header('Location: [...]') instead.

 - Tul


 Sanjeev N wrote:
  Hi,
  Its not the problem of cookies. Its problem of redirection or the
  parent.location.replace function. I mean if you already output something
 on
  the page and tries to redirect then this problem happens.
 
  Redirect before outputting anything on the page.. like space is also an
  output.
 
  Warm Regards,
  Sanjeev
  http://www.sanchanworld.com/
  http://webdirectory.sanchanworld.com - Submit your website URL
  http://webhosting.sanchanworld.com - Choose your best web hosting plan
  -Original Message-
  From: Otto Wyss [mailto:[EMAIL PROTECTED]
  Sent: Saturday, August 18, 2007 2:56 PM
  To: php-general@lists.php.net
  Subject: [PHP] Cookies and sent headers
 
  If built a simple login page and store any information within
  $_SESSION's. Yet I'd like to move these into cookies but I always get an

  error about sent headers. Is there a way to circumvent this problem
  without changing too much in the page?
 
  The setting of the cookies happens just at the end of the page.
 
 if (!$errortext and $Anmelden) {
   if (!empty($Permanent)) {
 $expires = time()+ 365 * 86400;  // 365 days
 setcookie (l.Lastname, $_SESSION['l_Lastname'], $expires);
 setcookie ( l.Firstname, $_SESSION['l_Firstname'], $expires);
 setcookie (l.Email1, $_SESSION['l_Email1'], $expires);
 setcookie (l.Email2, $_SESSION['l_Email2'], $expires);
   }
   echo script type=\text/javascript\
 parent.location.replace('$index_php;
 /script;
   exit;
 }
 
  O. Wyss
 

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] Cookies page refresh

2006-12-17 Thread Chris Shiflett
Richard Lynch wrote:
 A cookie is sent BACK to the server after the server sends
 it to the browser. Period.
 
 It's kind of like when you go to a movie, and you buy your
 ticket from one person, and then you hand it to another,
 and they hand it back, and then you have to be prepared to
 show it to prove you aren't sitting through a second movie.
 
 Walking back out front to the ticket sales window, you don't
 show them your ticket again...
 
 Maybe that's not such a good analogy...

You could fix it by explaining that no one should check to see whether
you have a ticket before you've had a chance to buy one. The timing just
doesn't make sense.

Developers sometimes make the mistake of checking $_COOKIE (a convenient
representation of the Cookie header from the previous request) before a
Set-Cookie header has been sent to the browser. The browser can't return
something it has never received.

Chris

-- 
Chris Shiflett
http://shiflett.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies page refresh

2006-12-15 Thread Richard Lynch
A cookie is sent BACK to the server after the server sends it to the
browser.  Period.

It's kind of like when you go to a movie, and you buy your ticket from
one person, and then you hand it to another, and they hand it back,
and then you have to be prepared to show it to prove you aren't
sitting through a second movie.

Walking back out front to the ticket sales window, you don't show them
your ticket again...

Maybe that's not such a good analogy...

Anyway, when you hit the back button, back to the first page, there is
no cookie, because there was no cookie in that request, because you
hadn't sent it.

If you reload, you get back the cookie, because the browser has it, so
it can send it now.

On Tue, December 12, 2006 9:28 am, William Stokes wrote:
 Hello,

 I have a page that uses session cookies for deciding what content to
 show to
 a visitor. User also has 2 form objecks to apply filters to the
 content SQL
 queries. So at the beginning of the script I set 2 cookies based on
 user
 selections(or defaults) and after that make DB query based on user
 selections. I wanted to use cookies because there also back - up -
 forward links for pagination.

 Problem is that in order to get the cookie based system to work the
 page
 needs a refresh to read the cookies and display content corretly. Is
 this
 because the page loads faster than the server set's the cookies to
 client
 browser? If so what's the corrert / best way to implement the
 filters and
 page navigation if there's 2 form select lists and 3 links to navigate
 the
 page.

 Thanks
 -Will

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies page refresh

2006-12-12 Thread William Stokes
Hello,

I have a page that uses session cookies for deciding what content to show to 
a visitor. User also has 2 form objecks to apply filters to the content SQL 
queries. So at the beginning of the script I set 2 cookies based on user 
selections(or defaults) and after that make DB query based on user 
selections. I wanted to use cookies because there also back - up - 
forward links for pagination.

Problem is that in order to get the cookie based system to work the page 
needs a refresh to read the cookies and display content corretly. Is this 
because the page loads faster than the server set's the cookies to client 
browser? If so what's the corrert / best way to implement the filters and 
page navigation if there's 2 form select lists and 3 links to navigate the 
page.

Thanks
-Will

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] Cookies page refresh

2006-12-12 Thread Peter Lauri
Hi,

I think it says somewhere in the documentation that the cookie values will
not be available until next request/response...

/Peter


-Original Message-
From: William Stokes [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 12, 2006 5:28 PM
To: php-general@lists.php.net
Subject: [PHP] Cookies  page refresh

Hello,

I have a page that uses session cookies for deciding what content to show to

a visitor. User also has 2 form objecks to apply filters to the content SQL 
queries. So at the beginning of the script I set 2 cookies based on user 
selections(or defaults) and after that make DB query based on user 
selections. I wanted to use cookies because there also back - up - 
forward links for pagination.

Problem is that in order to get the cookie based system to work the page 
needs a refresh to read the cookies and display content corretly. Is this 
because the page loads faster than the server set's the cookies to client 
browser? If so what's the corrert / best way to implement the filters and 
page navigation if there's 2 form select lists and 3 links to navigate the 
page.

Thanks
-Will

-- 
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 page refresh

2006-12-12 Thread Chris

William Stokes wrote:

Hello,

I have a page that uses session cookies for deciding what content to show to 
a visitor. User also has 2 form objecks to apply filters to the content SQL 
queries. So at the beginning of the script I set 2 cookies based on user 
selections(or defaults) and after that make DB query based on user 
selections. I wanted to use cookies because there also back - up - 
forward links for pagination.


Problem is that in order to get the cookie based system to work the page 
needs a refresh to read the cookies and display content corretly. Is this 
because the page loads faster than the server set's the cookies to client 
browser? If so what's the corrert / best way to implement the filters and 
page navigation if there's 2 form select lists and 3 links to navigate the 
page.


Use a session variable instead. Otherwise I could modify the cookie and 
change the query / queries being run really easily... causing sql 
injection and a bunch of other issues.


--
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 page refresh

2006-12-12 Thread William Stokes
Thanks.

It seems that I tested the right things but in a wrong order...

-Will

Chris [EMAIL PROTECTED] kirjoitti 
viestissä:[EMAIL PROTECTED]
 William Stokes wrote:
 Hello,

 I have a page that uses session cookies for deciding what content to show 
 to a visitor. User also has 2 form objecks to apply filters to the 
 content SQL queries. So at the beginning of the script I set 2 cookies 
 based on user selections(or defaults) and after that make DB query based 
 on user selections. I wanted to use cookies because there also back - 
 up - forward links for pagination.

 Problem is that in order to get the cookie based system to work the page 
 needs a refresh to read the cookies and display content corretly. Is this 
 because the page loads faster than the server set's the cookies to client 
 browser? If so what's the corrert / best way to implement the filters 
 and page navigation if there's 2 form select lists and 3 links to 
 navigate the page.

 Use a session variable instead. Otherwise I could modify the cookie and 
 change the query / queries being run really easily... causing sql 
 injection and a bunch of other issues.

 -- 
 Postgresql  php tutorials
 http://www.designmagick.com/ 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies https

2006-05-22 Thread Michael Satterwhite
I have a site that is using a shared ssl certificate. When running on 
the site, the host is of the form host.com. When running in ssl mode, 
the domain is of the form host.certhost.com. ping shows that both 
resolve to the same ip address.


Is there a way to create a cookie in the unsecured area and have it 
available when going through the ssl certificate?


tia
---Michael
--
Fight software piracy!
Don't pirate MS Office - that's theft.
Instead, use ours - it's legal and free
 www.openoffice.org

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies https

2006-05-22 Thread Stut

Michael Satterwhite wrote:

I have a site that is using a shared ssl certificate. When running on 
the site, the host is of the form host.com. When running in ssl 
mode, the domain is of the form host.certhost.com. ping shows that 
both resolve to the same ip address.


Is there a way to create a cookie in the unsecured area and have it 
available when going through the ssl certificate?



Short answer: No

Long answer: N

Seriously though, for security reasons you cannot set cookies from one 
domain for another domain. You'll need to come up with another way to 
pass a secure token or just leave them on the secure site.


-Stut

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies https

2006-05-22 Thread chris smith

On 5/22/06, Michael Satterwhite [EMAIL PROTECTED] wrote:

I have a site that is using a shared ssl certificate. When running on
the site, the host is of the form host.com. When running in ssl mode,
the domain is of the form host.certhost.com. ping shows that both
resolve to the same ip address.

Is there a way to create a cookie in the unsecured area and have it
available when going through the ssl certificate?


Nope. They are different domains.

If they were on the same basic domain, you could (see
http://wp.netscape.com/newsref/std/cookie_spec.html specifically the
domain section) but completely different domains isn't an option.

PHP sessions would work though. Explicitly pass the session across and
it should work (well, I think!).

--
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 https

2006-05-22 Thread Eric Butera

On 5/22/06, Michael Satterwhite [EMAIL PROTECTED] wrote:

I have a site that is using a shared ssl certificate. When running on
the site, the host is of the form host.com. When running in ssl mode,
the domain is of the form host.certhost.com. ping shows that both
resolve to the same ip address.

Is there a way to create a cookie in the unsecured area and have it
available when going through the ssl certificate?

tia
---Michael
--
Fight software piracy!
Don't pirate MS Office - that's theft.
Instead, use ours - it's legal and free
  www.openoffice.org

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



If by cookie you mean your PHPSESSION cookie, this is sort-of
possible.  My work has a shared certificate for those whom don't wish
to purchase their own.  This only works if http and https servers are
on the same machine.

- on regular page (cart) make link to another regular page (checkout)
that should become secure
- save session id to db, fetch last returned id.
- create ssl href with ?id=last returned id
- load session from the DB using the key
- delete session id from DB since it is now shared between domains
- call session_regenerate_id

...becomes...
http://www.example.com/cart.php
http://www.example.com/checkout.php
https://ssl.example.com/example/checkout.php

I'm not really sure how important the whole hide the session id thing
is considering I regenerate the ID.  But better safe than sorry I
guess. :)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies https

2006-05-22 Thread Richard Lynch
On Mon, May 22, 2006 6:49 am, Michael Satterwhite wrote:
 I have a site that is using a shared ssl certificate. When running on
 the site, the host is of the form host.com. When running in ssl
 mode,
 the domain is of the form host.certhost.com. ping shows that both
 resolve to the same ip address.

 Is there a way to create a cookie in the unsecured area and have it
 available when going through the ssl certificate?

No.

You'll have to transmit the Cookie through your web application
interface in some fashion.

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies in non-frame sites

2006-02-26 Thread emil

Hello,

Most sites today seems to be based on this style:

include(top);
include(current_page);
include(bottom);

If one wants to set cookies from current_page, how should that be handled with 
as clean source as possible?
Before I had the top and bottom output as functions that are called from each 
page, so I can call header stuff before it's executed. But it's not a very good 
looking approach.

I did it like this in every page:
include(top_bottom_lib);
// cookie stuff
echo getTopPage();
// page stuff
echo getBottomPage();

I hope you understand my problem.

Thanks

Best regards Emil

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies in non-frame sites

2006-02-26 Thread chris smith
 Most sites today seems to be based on this style:

 include(top);
 include(current_page);
 include(bottom);

 If one wants to set cookies from current_page, how should that be handled 
 with as clean source as possible?

From the php manual:

Like other headers, cookies must be sent before any output from your
script (this is a protocol restriction). This requires that you place
calls to this function prior to any output, including html and
head tags as well as any whitespace. If output exists prior to
calling this function, setcookie() will fail and return FALSE.

So it has to go before ALL output otherwise it will fail. You're stuck
with putting it in the 'top' file or at least before you echo any
output.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies

2005-11-17 Thread Ben Miller
Is there a way to test if a user has cookies turned on or not so that I can
use cookies if the user allows them and use the URL if the user does not
allow them?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies

2005-11-17 Thread Dan McCullough
Tried and true is to set a cookie and then attempt to read it, if you
cant read it then cookies are not on.

On 11/17/05, Ben Miller [EMAIL PROTECTED] wrote:
 Is there a way to test if a user has cookies turned on or not so that I can
 use cookies if the user allows them and use the URL if the user does not
 allow them?

 --
 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

2005-11-17 Thread Richard Davey
Hi Ben,

Thursday, November 17, 2005, 3:26:04 PM, you wrote:

 Is there a way to test if a user has cookies turned on or not so
 that I can use cookies if the user allows them and use the URL if
 the user does not allow them?

Set one? :)

Then check if it exists or not.

This of course will not catch those sneaky buggers who disable cookies
part way through your site just to see what effect it will have.

Cheers,

Rich
-- 
Zend Certified Engineer
PHP Development Services
http://www.corephp.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies

2005-11-17 Thread Robert Cummings
On Thu, 2005-11-17 at 10:33, Richard Davey wrote:
 Hi Ben,
 
 Thursday, November 17, 2005, 3:26:04 PM, you wrote:
 
  Is there a way to test if a user has cookies turned on or not so
  that I can use cookies if the user allows them and use the URL if
  the user does not allow them?
 
 Set one? :)
 
 Then check if it exists or not.
 
 This of course will not catch those sneaky buggers who disable cookies
 part way through your site just to see what effect it will have.

*lol* I do that sometimes... with Javascript too.

Cheers,
Rob.
-- 
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for   |
| creating re-usable components quickly and easily.  |
`'

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re[2]: [PHP] Cookies

2005-11-17 Thread Richard Davey
Hi Robert,

Thursday, November 17, 2005, 3:39:43 PM, you wrote:

 *lol* I do that sometimes... with Javascript too.

:) it's amazing what you can break by doing that!

Cheers,

Rich
-- 
Zend Certified Engineer
PHP Development Services
http://www.corephp.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies

2005-11-17 Thread Dan McCullough
You can check on every page load, but I'm sure thats over kill for
most public facing sites to catch some Yahoos who have too much time
on their hands.

On 11/17/05, Richard Davey [EMAIL PROTECTED] wrote:
 Hi Ben,

 Thursday, November 17, 2005, 3:26:04 PM, you wrote:

  Is there a way to test if a user has cookies turned on or not so
  that I can use cookies if the user allows them and use the URL if
  the user does not allow them?

 Set one? :)

 Then check if it exists or not.

 This of course will not catch those sneaky buggers who disable cookies
 part way through your site just to see what effect it will have.

 Cheers,

 Rich
 --
 Zend Certified Engineer
 PHP Development Services
 http://www.corephp.co.uk

 --
 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[2]: [PHP] Cookies

2005-11-17 Thread Richard Davey
Hi Dan,

Thursday, November 17, 2005, 3:56:43 PM, you wrote:

 You can check on every page load, but I'm sure thats over kill for
 most public facing sites to catch some Yahoos who have too much time
 on their hands.

Is that a new technical term for 'hacker' ? :)

Cheers,

Rich
-- 
Zend Certified Engineer
PHP Development Services
http://www.corephp.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: Re[2]: [PHP] Cookies

2005-11-17 Thread Dan McCullough
:) why of course

On 11/17/05, Richard Davey [EMAIL PROTECTED] wrote:
 Hi Dan,

 Thursday, November 17, 2005, 3:56:43 PM, you wrote:

  You can check on every page load, but I'm sure thats over kill for
  most public facing sites to catch some Yahoos who have too much time
  on their hands.

 Is that a new technical term for 'hacker' ? :)

 Cheers,

 Rich
 --
 Zend Certified Engineer
 PHP Development Services
 http://www.corephp.co.uk

 --
 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

2005-11-17 Thread Ben Miller
Hi Ben,

Thursday, November 17, 2005, 3:26:04 PM, you wrote:

 Is there a way to test if a user has cookies turned on or not so
 that I can use cookies if the user allows them and use the URL if
 the user does not allow them?

Set one? :)

Then check if it exists or not.

This of course will not catch those sneaky buggers who disable cookies
part way through your site just to see what effect it will have.

Cheers,

Rich
--
Zend Certified Engineer
PHP Development Services
http://www.corephp.co.uk

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

In order to set one and then check if it exists or not, I have to set it on
one page, and then test it on the next page load - In this case, I don't
figure out how I need to send information from page to page until they have
already gone to another page, at which point, the test is no longer needed.
I was hoping there might be a browser variable or something like that that
would tell right away if cookies are turned on or not.  If there is not,
perhaps this is something we should lobby the browsers to get?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re[2]: [PHP] Cookies

2005-11-17 Thread Richard Davey
Hi Ben,

Thursday, November 17, 2005, 4:24:11 PM, you wrote:

 In order to set one and then check if it exists or not, I have to
 set it on one page, and then test it on the next page load - In this
 case, I don't figure out how I need to send information from page to
 page until they have already gone to another page, at which point,
 the test is no longer needed.

You don't have to set / test one on a *PAGE* at all, just from a PHP
script (these are not always the same thing).

Cheers,

Rich
-- 
Zend Certified Engineer
PHP Development Services
http://www.corephp.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] cookies problem

2005-09-15 Thread Ross
I am very close to getting this sorted.Thanks for all the help on 
'variable variables' and var_dump. Two useful techniques.

My function works but throws up a cookie problem

if (isset($add)){


${$add} = intval($_COOKIE['cookie'][$add]);
$new= $$add+1;
setcookie(cookie[$add], $new $add);
echo var_dump($_COOKIE['cookie'][$add]);

}

At the beginining of my page I have...

session_start();
require_once('init_cookies.php');

Init_cookies is jus a for loop to initialise the cookies...

$dishes= array (pakora, haggis_fritter);
for ($i=0; $i  2; $i++){
setcookie(cookie[$dishes[$i]], 0 $dishes[$i]);

when I leave it in it resets the cookies when they are sent to the page. 
When I take it out the headers already sent error occurs. I do not know if 
this is my lack of undertanding of require_once/include_once.

I need a way to initialise the cookies one time only. I have tried an 'if 
(isset)' but that doesn't work.


thanks again


Ross 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies.

2005-08-30 Thread Nancy Ferracutti Kincaide

Hi,

I am trying to install a web application that tests if cookies are enabled 
the following way:


 $this-usesCookies =
   (isset($_COOKIE[session_name()]) 
@strlen($_COOKIE[session_name()])
== 32);

As it gives as a result, that cookies are NOT ENABLED, I can't go on with 
the SETUP phase.


The responsible of the FALSE result, in the sentence above, is the LENGTH of 
the string $_COOKIE[session_name()]. Its actual value is 26 instead of 32, 
as expected. ¿Could anyone tell me if that LENGTH should be 32? ¿Is this 
value mandatory to admit that cookies are enabled?


Thanks!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies.

2005-08-30 Thread Jasper Bryant-Greene

Nancy Ferracutti Kincaide wrote:
I am trying to install a web application that tests if cookies are 
enabled the following way:


 $this-usesCookies =
   (isset($_COOKIE[session_name()]) 
@strlen($_COOKIE[session_name()])
== 32);

As it gives as a result, that cookies are NOT ENABLED, I can't go on 
with the SETUP phase.


The responsible of the FALSE result, in the sentence above, is the 
LENGTH of the string $_COOKIE[session_name()]. Its actual value is 26 
instead of 32, as expected. ¿Could anyone tell me if that LENGTH should 
be 32? ¿Is this value mandatory to admit that cookies are enabled?


That would depend on what the session hash function was set to. Normally 
it should be 32 or 40 depending on whether MD5 or SHA1 was selected.


Just the fact that $_COOKIE[session_name()] is set would indicate that 
cookies are enabled, but the application may be performing some sort of 
sanity check, which is obviously failing...


Put a die($_COOKIE[session_name()]); just before that line, and tell us 
what it shows.


--
Jasper Bryant-Greene
Freelance web developer
http://jasper.bryant-greene.name/

If you find my advice useful, please consider donating to a poor
student! You can choose whatever amount you think my advice was
worth to you. http://tinyurl.com/7oa5s

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Cookies.

2005-08-30 Thread Nancy Ferracutti Kincaide

Dear Jasper,

I think the session hash function is set to 32, and MD5 is selected, as the 
following lines of code show:

--
function Session($sessionName=SESSID) {
   $this-sendNoCacheHeader();

   //  Session-Namen setzen, Session initialisieren
   session_name(isset($sessionName)
   ? $sessionName
   : session_name());

   @session_start();

   //  Prüen ob die Session-ID die Standardlänge
   //  von 32 Zeichen hat,
   //  ansonsten Session-ID neu setzen
   if (strlen(session_id()) != 32)
   {
   mt_srand ((double)microtime()*100);
   session_id(md5(uniqid(mt_rand(;
   }
--

The sentence die($_COOKIE[session_name()]), when executed, shows this value: 
211b78tfl8umggkdh1ak7jrbf3 (a string of 26 characters long).


Thank you very much, again!
Nancy.

- Original Message - 
From: Jasper Bryant-Greene [EMAIL PROTECTED]

To: php php-general@lists.php.net
Sent: Tuesday, August 30, 2005 8:48 AM
Subject: Re: [PHP] Cookies.



Nancy Ferracutti Kincaide wrote:
I am trying to install a web application that tests if cookies are 
enabled the following way:


 $this-usesCookies =
   (isset($_COOKIE[session_name()]) 
@strlen($_COOKIE[session_name()])
== 32);

As it gives as a result, that cookies are NOT ENABLED, I can't go on with 
the SETUP phase.


The responsible of the FALSE result, in the sentence above, is the LENGTH 
of the string $_COOKIE[session_name()]. Its actual value is 26 instead of 
32, as expected. ¿Could anyone tell me if that LENGTH should be 32? ¿Is 
this value mandatory to admit that cookies are enabled?


That would depend on what the session hash function was set to. Normally 
it should be 32 or 40 depending on whether MD5 or SHA1 was selected.


Just the fact that $_COOKIE[session_name()] is set would indicate that 
cookies are enabled, but the application may be performing some sort of 
sanity check, which is obviously failing...


Put a die($_COOKIE[session_name()]); just before that line, and tell us 
what it shows.


--
Jasper Bryant-Greene
Freelance web developer
http://jasper.bryant-greene.name/

If you find my advice useful, please consider donating to a poor
student! You can choose whatever amount you think my advice was
worth to you. http://tinyurl.com/7oa5s

--
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

2005-02-25 Thread Chris Shiflett
--- William Stokes [EMAIL PROTECTED] wrote:
 If I send a session cookie to browser where it is stored in WinXP?

Session cookies are kept in memory.

Chris

=
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly HTTP Developer's Handbook - Sams
Coming Soon http://httphandbook.org/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Cookies

2005-02-24 Thread William Stokes
Hello,

If I send a session cookie to browser where it is stored in WinXP? Or is it 
stored as a separate file at all. I know that the script sends the cookie 
but I can't find it in the client computer harddrive.

I am testing with Opera, IE6 and Firefox.

Thanks
-Will

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




  1   2   3   4   >