Cookies & sessions

I am trying for the first time to use cookies. The manual contains the statement "Cookies
are part of the HTTP header, so setcookie() must be called before any output is sent to
the browser."

When I first started using sessions, I was alarmed to read a very similar statement about
sessions, but I soon found that if I started my program with the statement
"session_start();" I could then set up, access, modify or clear any session variable at
any time in my program. This is enormously useful, as I can put the session handling at
any convenient point in my program, and can precede them with diagnostics if I need to.

However I have almost immediately found that while I appear to be able to read cookies at
any time, I cannot set them when I would like to. Is there any similar trick which will
work with cookies? If I really have to work out what they should be, and then set them up,
before issuing any diagnostics, etc, it will make life decidely more complicated. (I
assume that I can set several cookies using successive calls to setcookie()?)

I was also somewhat surprised to find that a cookie is used to implement sessions. Does
this place any limitations on using both sessions and cookies in the same program?


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

Re: Cookies & sessions

2010/1/19 :
> 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: Cookies & sessions

> When I first started using sessions, I was alarmed to read a very similar statement about
> sessions, but I soon found that if I started my program with the statement
> "session_start();" I could then set up, access, modify or clear any session variable at
> any time in my program. This is enormously useful, as I can put the session handling at
> any convenient point in my program, and can precede them with diagnostics if I need to.

are you looking for ob_* functions ?

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

Re: Cookies & sessions

Hi,

> However I have almost immediately found that while I appear to be able to read cookies at
> any time, I cannot set them when I would like to. Is there any similar trick which will
> work with cookies?

Keep in mind that cookies are set by sending an HTTP header as part of
the response, so until you do that they can't be sent back to you by
the client (and subsequently appear in $_COOKIE).

> (I assume that I can set several cookies using successive calls to setcookie()?)

Sure. Not that I've done it.

> I was also somewhat surprised to find that a cookie is used to implement sessions. Does
> this place any limitations on using both sessions and cookies in the same program?

No (give them a different name though). You can also use sessions by
putting the session ID on the URL, but this, I believe, is called "a
ball ache".

--
Richard Heyes
HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 16th January)
Follow me on Twitter: http://twitter.com/_rgraph
Lots of PHP and Javascript code - http://www.phpguru.org

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

Re: Cookies & sessions

Be aware that there is a limit of 20 cookies per domain

Bastien

Sent from my iPod

On Jan 19, 2010, at 6:12 AM, Bruno Fajardo wrote:

> 2010/1/19 :
>> 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: Cookies & sessions

On Tue, Jan 19, 2010 at 10:06:26PM +1100, clancy_1@cybec.com.au wrote:

> 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()?)

Session variables are available throughout your session. Cookie
variables are only available if you read them into variables you can
access. Changes to session variables will the flushed to the server when
your page is terminated. Cookie variables are flushed to disk if you
make the appropriate *_cookie() function call, and even then I don't
know if this is actually echoed to disk until your page is terminated.

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

I don't believe so. If I'm not mistaken, session values are stored on the
server, not on the client. What's stored on the client is the session
ID.

Please bear in mind my understanding of cookies is fragmentary, and I
hope someone else will write in to correct any incorrect statements I've
made.

Paul

--
Paul M. Foster

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

Re: Cookies & sessions

--001636c5b90f502852047d885ec4
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 19, 2010 at 12:42 PM, Paul M Foster wrote:

> On Tue, Jan 19, 2010 at 10:06:26PM +1100, clancy_1@cybec.com.au wrote:
>
> > 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()?)
>
> Session variables are available throughout your session. Cookie
> variables are only available if you read them into variables you can
> access. Changes to session variables will the flushed to the server when
> your page is terminated. Cookie variables are flushed to disk if you
> make the appropriate *_cookie() function call, and even then I don't
> know if this is actually echoed to disk until your page is terminated.
>
> >
> > 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?
>
> I don't believe so. If I'm not mistaken, session values are stored on the
> server, not on the client. What's stored on the client is the session
> ID.
>
> Please bear in mind my understanding of cookies is fragmentary, and I
> hope someone else will write in to correct any incorrect statements I've
> made.
>
> Paul
>
> --
> Paul M. Foster
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

>

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


There shouldn't be any issue. By default, PHP uses a cookie named
PHPSESSIONID to associate a particular visitor with their corresponding
session data stored server-side. So, just be sure not to use a cookie
called "PHPSESSIONID".


--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com

--001636c5b90f502852047d885ec4--

Re: Cookies & sessions

On Tue, 19 Jan 2010 09:12:17 -0200, bsfajardo@gmail.com (Bruno Fajardo) wrote:

>2010/1/19 :
>> 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:


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: Cookies & sessions

The first setcookie call is empty which produces the errors that cause
the second cookie to fail.

Bastien

Sent from my iPod

On Jan 19, 2010, at 10:16 PM, clancy_1@cybec.com.au wrote:

> On Tue, 19 Jan 2010 09:12:17 -0200, bsfajardo@gmail.com (Bruno
> Fajardo) wrote:
>
>> 2010/1/19 :
>>> 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:
>
> >
> 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: Cookies & sessions

On Tue, 19 Jan 2010 16:45:37 +0530, kranthi117@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: Cookies & sessions

On Tue, 19 Jan 2010 22:45:14 -0500, phpster@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:


session_start ();

setcookie ('Try_1', 'Works', time()+3600);
echo ' ';
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: Cookies & sessions

--=-b29KXKEWj6t9PcO+SECo
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2010-01-20 at 15:45 +1100, clancy_1@cybec.com.au wrote:

> On Tue, 19 Jan 2010 22:45:14 -0500, phpster@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:
>
> >
> session_start ();
>
> setcookie ('Try_1', 'Works', time()+3600);
> echo ' ';
> 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



--=-b29KXKEWj6t9PcO+SECo--

Re: Cookies & sessions

On Wed, 20 Jan 2010 13:19:03 +0000, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:

>On Wed, 2010-01-20 at 15:45 +1100, clancy_1@cybec.com.au wrote:
>
>> On Tue, 19 Jan 2010 22:45:14 -0500, phpster@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:
>>
>> >>
>> session_start ();
>>
>> setcookie ('Try_1', 'Works', time()+3600);
>> echo ' ';
>> 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: Cookies & sessions

--=-Nu8YNWKuwYaJp4P1Gn10
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-01-21 at 08:43 +1100, clancy_1@cybec.com.au wrote:

> On Wed, 20 Jan 2010 13:19:03 +0000, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:
>
> >On Wed, 2010-01-20 at 15:45 +1100, clancy_1@cybec.com.au wrote:
> >
> >> On Tue, 19 Jan 2010 22:45:14 -0500, phpster@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:
> >>
> >> > >>
> >> session_start ();
> >>
> >> setcookie ('Try_1', 'Works', time()+3600);
> >> echo ' ';
> >> 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



--=-Nu8YNWKuwYaJp4P1Gn10--

Re: Cookies & sessions

2010/1/20 :
> 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: Cookies & sessions

Bruno Fajardo wrote:
> You don't need to use output buffering at all. You only need this
> mechanism if your script needs to output stuff before the
> session_start() or setcookie() functions get executed.
Output buffering is also used if you need to "output" something before
the headers are sent either by the header() function or simply using
echo or print().

Joseph

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

Re: Cookies & sessions

On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@gmail.com (Bruno Fajardo) wrote:

>2010/1/20 :
>> 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

Re: Cookies & sessions

At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
>On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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.

Cheer,

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: Cookies & sessions

On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@gmail.com (tedd) wrote:

>At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
>>On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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: Cookies & sessions

--=-Z/iQrvpXiX7z6cz9QcKc
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Fri, 2010-01-22 at 08:58 +1100, clancy_1@cybec.com.au wrote:

> On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@gmail.com (tedd) wrote:
>
> >At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
> >>On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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



--=-Z/iQrvpXiX7z6cz9QcKc--

Re: Cookies & sessions

clancy_1@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: Cookies & sessions

At 8:58 AM +1100 1/22/10, clancy_1@cybec.com.au wrote:
>On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@gmail.com (tedd) wrote:
>
>>At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
>>>On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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: Cookies & sessions

On Thu, 21 Jan 2010 22:00:30 +0000, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:

>On Fri, 2010-01-22 at 08:58 +1100, clancy_1@cybec.com.au wrote:
>
>> On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@gmail.com (tedd) wrote:
>>
>> >At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
>> >>On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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: Cookies & sessions

clancy_1@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: Cookies & sessions

At 1:13 PM +1100 1/23/10, clancy_1@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: Cookies & sessions

clancy_1@cybec.com.au wrote:
> On Thu, 21 Jan 2010 22:00:30 +0000, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:
>
>> On Fri, 2010-01-22 at 08:58 +1100, clancy_1@cybec.com.au wrote:
>>
>>> On Thu, 21 Jan 2010 08:54:44 -0500, tedd.sperling@gmail.com (tedd) wrote:
>>>
>>>> At 12:15 PM +1100 1/21/10, clancy_1@cybec.com.au wrote:
>>>>> On Wed, 20 Jan 2010 20:05:42 -0200, bsfajardo@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 key (session_id) in the cookie and everything on the safe
secure server is the way to go.

Regards!


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

Re: Cookies & sessions

tedd wrote:
> At 1:13 PM +1100 1/23/10, clancy_1@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: Cookies & sessions

On Sat, 23 Jan 2010 09:32:37 -0500, tedd.sperling@gmail.com (tedd) wrote:

>At 1:13 PM +1100 1/23/10, clancy_1@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: Cookies & sessions

On Sat, 23 Jan 2010 15:10:11 +0000, nrixham@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: Cookies & sessions

clancy_1@cybec.com.au wrote:
> On Sat, 23 Jan 2010 09:32:37 -0500, tedd.sperling@gmail.com (tedd) wrote:
>
>> At 1:13 PM +1100 1/23/10, clancy_1@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: Cookies & sessions

On Sun, 24 Jan 2010 17:44:16 +1100, clancy_1@cybec.com.au wrote:

>On Sat, 23 Jan 2010 15:10:11 +0000, nrixham@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: Cookies & sessions

On Thu, 21 Jan 2010 08:43:58 +1100, clancy_1@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:

Some results:



/Nisse

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

Re: Cookies & sessions

--=-1NFGDdI7XFee79mKBzmg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2010-01-25 at 22:13 +0100, Nisse Engström wrote:

> On Thu, 21 Jan 2010 08:43:58 +1100, clancy_1@cybec.com.au wrote:
>=20
> > When you are working with sessions, provided you start your program wit=
h session_id(), you
> > can then do anything you like with session variables at any point in yo=
ur program. In my
> > original question I asked if there was a cookie equivalent.=20
>=20
> 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.
>=20
> The only user agents I know of that support trailers are
> the WC3 and WDG validators, and Opera(!).
>=20
> Trailer test:
>
> Some results:
>
>=20
>=20
> /Nisse
>=20


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



--=-1NFGDdI7XFee79mKBzmg--

Re: Cookies & sessions

On Mon, 25 Jan 2010 21:26:05 +0000, 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...

header ("Trailer: Cookie");
/* PHP takes notice! */

echo ' setcookie (...);
echo '

Some 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