| Strange url session behaviour after upgrade to 4.3 [message #182706] |
Fri, 30 August 2013 20:33  |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
I have a page that needs to get another page on the fly, using
the same session. I figured out how to stop my session and set
the cookie on the CURL handler, and everything was cool. The
curled page had my same session available as the calling page.
Life was good.
Now something has changed after upgrading from 5.2.4 to 5.3.10.
My session was no longer available on the curled page. What's
strange is that the PHPSESSID cookie was still being set, and
hit had the correct value.
Here is the weirdest part. If I do this:
session_id($_COOKIE['PHPSESSID']);
session_start();
The session is there! But why isn't php taking
the cookie as the id all by itself? Regular
pages (not curled) all work as before. All of
our websites work fine on the new version, except
for this one curl call. I could update 100's of
websites to fix them with the added lines, but
I'd really rather find out why the curled page
is not taking the session_id from the PHPSESSID
cookie.
Thanks!
Toby
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182712 is a reply to message #182706] |
Sat, 31 August 2013 00:28  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 8/30/2013 4:33 PM, Tobiah wrote:
> I have a page that needs to get another page on the fly, using
> the same session. I figured out how to stop my session and set
> the cookie on the CURL handler, and everything was cool. The
> curled page had my same session available as the calling page.
> Life was good.
>
> Now something has changed after upgrading from 5.2.4 to 5.3.10.
> My session was no longer available on the curled page. What's
> strange is that the PHPSESSID cookie was still being set, and
> hit had the correct value.
>
> Here is the weirdest part. If I do this:
>
> session_id($_COOKIE['PHPSESSID']);
> session_start();
>
> The session is there! But why isn't php taking
> the cookie as the id all by itself? Regular
> pages (not curled) all work as before. All of
> our websites work fine on the new version, except
> for this one curl call. I could update 100's of
> websites to fix them with the added lines, but
> I'd really rather find out why the curled page
> is not taking the session_id from the PHPSESSID
> cookie.
>
> Thanks!
>
> Toby
I don't know what would have changed in the PHP update. But you haven't
shown us the failing (cURL) code - so anything would be a guess.
Are you trying to access a PHP script on a different server (or domain)?
Or what are you trying to do specifically?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182729 is a reply to message #182706] |
Sat, 31 August 2013 17:58 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Tobiah wrote:
> I have a page that needs to get another page on the fly, using
> the same session. I figured out how to stop my session and set
> the cookie on the CURL handler, and everything was cool. The
> curled page had my same session available as the calling page.
> Life was good.
>
> Now something has changed after upgrading from 5.2.4 to 5.3.10.
> My session was no longer available on the curled page. What's
> strange is that the PHPSESSID cookie was still being set, and
> hit had the correct value.
>
> Here is the weirdest part. If I do this:
>
> session_id($_COOKIE['PHPSESSID']);
> session_start();
>
> The session is there! But why isn't php taking
> the cookie as the id all by itself?
Have you checked the PHP ini settings related to sessions (session.*),
especially session.name and session.use_cookies?
--
Christoph M. Becker
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182730 is a reply to message #182706] |
Sat, 31 August 2013 18:47 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 30-08-2013 22:33, Tobiah wrote:
> I have a page that needs to get another page on the fly, using
> the same session. I figured out how to stop my session and set
> the cookie on the CURL handler, and everything was cool. The
> curled page had my same session available as the calling page.
> Life was good.
>
> Now something has changed after upgrading from 5.2.4 to 5.3.10.
ok, when getting the changelog, and counting the occurrances of
'sesssion' between 'Version 5.2.4' and 'Version 5.3 10', i do get a
count of 28
<-- bash-script below, for those who are interested ;) -->
#!/bin/bash
wget "http://php.net/ChangeLog-5.php" -O /tmp/blaat.htm
awk '/Version 5.3.10/,/Version 5.2.4/{ print $0 }' blaat.htm | grep -i
session | wc -l
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182747 is a reply to message #182712] |
Tue, 03 September 2013 15:58 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 08/30/2013 05:28 PM, Jerry Stuckle wrote:
> On 8/30/2013 4:33 PM, Tobiah wrote:
>> I have a page that needs to get another page on the fly, using
>> the same session. I figured out how to stop my session and set
>> the cookie on the CURL handler, and everything was cool. The
>> curled page had my same session available as the calling page.
>> Life was good.
>>
>> Now something has changed after upgrading from 5.2.4 to 5.3.10.
>> My session was no longer available on the curled page. What's
>> strange is that the PHPSESSID cookie was still being set, and
>> hit had the correct value.
>>
>> Here is the weirdest part. If I do this:
>>
>> session_id($_COOKIE['PHPSESSID']);
>> session_start();
>>
>> The session is there! But why isn't php taking
>> the cookie as the id all by itself? Regular
>> pages (not curled) all work as before. All of
>> our websites work fine on the new version, except
>> for this one curl call. I could update 100's of
>> websites to fix them with the added lines, but
>> I'd really rather find out why the curled page
>> is not taking the session_id from the PHPSESSID
>> cookie.
>>
>> Thanks!
>>
>> Toby
>
> I don't know what would have changed in the PHP update. But you haven't shown us the failing (cURL) code - so anything would be a
> guess.
>
> Are you trying to access a PHP script on a different server (or domain)? Or what are you trying to do specifically?
>
So I'm executing PHP, and I need to grab the HTML from another
url on the same domain. It's easy to use curl for this, but
I need the other url to execute PHP with the same session id as
the calling script.
I'm doing something like this:
$session_id = session_id();
session_write_close();
Then I make a cookie jar of the Netscape type and point to it:
$cookie = sprintf("%s\t%s\t%s\t%s\t%s\t%s\t%s\n",
$this->host, "FALSE", "/$this->path/", "FALSE", "0", $key, $val
);
$cookie_jar = fopen($this->cookie_jar_name, 'a');
fwrite($cookie_jar, $cookie);
fclose($cookie_jar);
$ch = curl_init($this->url);
curl_setopt($ch, CURLOPT_COOKIEFILE, $this->cookie_jar_name);
I set some other options, including CURLOPT_POST and
CURLOPT_RETURNTRANSFER. I've tried some others that don't
seem to matter either way:
CURLOPT_USERAGENT
CURLOPT_FOLLOWLOCATION
CURLOPT_SSL_VERIFYPEER
CURLOPT_SSL_VERIFYHOST
CURLOPT_FORBID_REUSE
$other_html_page = curl_exec($ch);
So, under php 5.2.4, the 'other' page php
sees the session and the page runs correctly.
Now, under 5.3.10, I have to do this on the other page:
session_id($_COOKIE['PHPSESSID']);
session_start();
So what I don't understand, is why php doesn't know to
look at the PHPSESSID cookie and makes me spoon feed it
the value. This is all running on the same server under
the same .ini file. Sessions work fine in the main page,
and I know PHP is getting the session value out of the
cookie, because deleting the PHPSESSID cookie results in
a reset of all my data for the app.
So there is some difference in curl, where just setting
the cookie is not enough. I have to force the cookie
value into session_id().
Thanks again,
Toby
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182748 is a reply to message #182747] |
Tue, 03 September 2013 16:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/3/2013 11:58 AM, Tobiah wrote:
> On 08/30/2013 05:28 PM, Jerry Stuckle wrote:
>> On 8/30/2013 4:33 PM, Tobiah wrote:
>>> I have a page that needs to get another page on the fly, using
>>> the same session. I figured out how to stop my session and set
>>> the cookie on the CURL handler, and everything was cool. The
>>> curled page had my same session available as the calling page.
>>> Life was good.
>>>
>>> Now something has changed after upgrading from 5.2.4 to 5.3.10.
>>> My session was no longer available on the curled page. What's
>>> strange is that the PHPSESSID cookie was still being set, and
>>> hit had the correct value.
>>>
>>> Here is the weirdest part. If I do this:
>>>
>>> session_id($_COOKIE['PHPSESSID']);
>>> session_start();
>>>
>>> The session is there! But why isn't php taking
>>> the cookie as the id all by itself? Regular
>>> pages (not curled) all work as before. All of
>>> our websites work fine on the new version, except
>>> for this one curl call. I could update 100's of
>>> websites to fix them with the added lines, but
>>> I'd really rather find out why the curled page
>>> is not taking the session_id from the PHPSESSID
>>> cookie.
>>>
>>> Thanks!
>>>
>>> Toby
>>
>> I don't know what would have changed in the PHP update. But you
>> haven't shown us the failing (cURL) code - so anything would be a
>> guess.
>>
>> Are you trying to access a PHP script on a different server (or
>> domain)? Or what are you trying to do specifically?
>>
>
>
> So I'm executing PHP, and I need to grab the HTML from another
> url on the same domain. It's easy to use curl for this, but
> I need the other url to execute PHP with the same session id as
> the calling script.
>
> I'm doing something like this:
>
> $session_id = session_id();
> session_write_close();
>
> Then I make a cookie jar of the Netscape type and point to it:
>
> $cookie = sprintf("%s\t%s\t%s\t%s\t%s\t%s\t%s\n",
> $this->host, "FALSE", "/$this->path/", "FALSE",
> "0", $key, $val
> );
> $cookie_jar = fopen($this->cookie_jar_name, 'a');
> fwrite($cookie_jar, $cookie);
> fclose($cookie_jar);
>
> $ch = curl_init($this->url);
> curl_setopt($ch, CURLOPT_COOKIEFILE, $this->cookie_jar_name);
>
> I set some other options, including CURLOPT_POST and
> CURLOPT_RETURNTRANSFER. I've tried some others that don't
> seem to matter either way:
>
> CURLOPT_USERAGENT
> CURLOPT_FOLLOWLOCATION
> CURLOPT_SSL_VERIFYPEER
> CURLOPT_SSL_VERIFYHOST
> CURLOPT_FORBID_REUSE
>
> $other_html_page = curl_exec($ch);
>
> So, under php 5.2.4, the 'other' page php
> sees the session and the page runs correctly.
> Now, under 5.3.10, I have to do this on the other page:
>
> session_id($_COOKIE['PHPSESSID']);
> session_start();
>
> So what I don't understand, is why php doesn't know to
> look at the PHPSESSID cookie and makes me spoon feed it
> the value. This is all running on the same server under
> the same .ini file. Sessions work fine in the main page,
> and I know PHP is getting the session value out of the
> cookie, because deleting the PHPSESSID cookie results in
> a reset of all my data for the app.
>
> So there is some difference in curl, where just setting
> the cookie is not enough. I have to force the cookie
> value into session_id().
>
> Thanks again,
>
> Toby
>
Hi, Toby,
Well, one thing I see right off hand:
$cookie_jar = fopen($this->cookie_jar_name, 'a');
You are appending to the file. I think you want 'w' here to overwrite
the contents of the cookie_jar (unless you have previously cleared the
contents in this script).
Additionally, setting the domain to www.example.com with a value of
FALSE would say you have to access www.example.com - example.com won't
work, for instance. Setting .example.com with a value of TRUE would
allow access via either www.example.com or example.com. I don't know if
this is part of the problem or not, though. Maybe not.
I also don't know what's in your $this->path; normally I just use '/' here.
I don't know if the latter two are related to your problem, but I highly
suspect the appending to the file will cause a problem. They are just a
couple of other things to look at.
Hope this gives you a lead. I'd be interested in knowing if one of
these fixed your problem, and if so, which one.
Jerry
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182749 is a reply to message #182748] |
Tue, 03 September 2013 18:07 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 09/03/2013 09:59 AM, Jerry Stuckle wrote:
> On 9/3/2013 11:58 AM, Tobiah wrote:
>> On 08/30/2013 05:28 PM, Jerry Stuckle wrote:
>>> On 8/30/2013 4:33 PM, Tobiah wrote:
>>>> I have a page that needs to get another page on the fly, using
>>>> the same session. I figured out how to stop my session and set
>>>> the cookie on the CURL handler, and everything was cool. The
>>>> curled page had my same session available as the calling page.
>>>> Life was good.
>>>>
>>>> Now something has changed after upgrading from 5.2.4 to 5.3.10.
>>>> My session was no longer available on the curled page. What's
>>>> strange is that the PHPSESSID cookie was still being set, and
>>>> hit had the correct value.
>>>>
>>>> Here is the weirdest part. If I do this:
>>>>
>>>> session_id($_COOKIE['PHPSESSID']);
>>>> session_start();
>>>>
>>>> The session is there! But why isn't php taking
>>>> the cookie as the id all by itself? Regular
>>>> pages (not curled) all work as before. All of
>>>> our websites work fine on the new version, except
>>>> for this one curl call. I could update 100's of
>>>> websites to fix them with the added lines, but
>>>> I'd really rather find out why the curled page
>>>> is not taking the session_id from the PHPSESSID
>>>> cookie.
>>>>
>>>> Thanks!
>>>>
>>>> Toby
>>>
>>> I don't know what would have changed in the PHP update. But you
>>> haven't shown us the failing (cURL) code - so anything would be a
>>> guess.
>>>
>>> Are you trying to access a PHP script on a different server (or
>>> domain)? Or what are you trying to do specifically?
>>>
>>
>>
>> So I'm executing PHP, and I need to grab the HTML from another
>> url on the same domain. It's easy to use curl for this, but
>> I need the other url to execute PHP with the same session id as
>> the calling script.
>>
>> I'm doing something like this:
>>
>> $session_id = session_id();
>> session_write_close();
>>
>> Then I make a cookie jar of the Netscape type and point to it:
>>
>> $cookie = sprintf("%s\t%s\t%s\t%s\t%s\t%s\t%s\n",
>> $this->host, "FALSE", "/$this->path/", "FALSE",
>> "0", $key, $val
>> );
>> $cookie_jar = fopen($this->cookie_jar_name, 'a');
>> fwrite($cookie_jar, $cookie);
>> fclose($cookie_jar);
>>
>> $ch = curl_init($this->url);
>> curl_setopt($ch, CURLOPT_COOKIEFILE, $this->cookie_jar_name);
>>
>> I set some other options, including CURLOPT_POST and
>> CURLOPT_RETURNTRANSFER. I've tried some others that don't
>> seem to matter either way:
>>
>> CURLOPT_USERAGENT
>> CURLOPT_FOLLOWLOCATION
>> CURLOPT_SSL_VERIFYPEER
>> CURLOPT_SSL_VERIFYHOST
>> CURLOPT_FORBID_REUSE
>>
>> $other_html_page = curl_exec($ch);
>>
>> So, under php 5.2.4, the 'other' page php
>> sees the session and the page runs correctly.
>> Now, under 5.3.10, I have to do this on the other page:
>>
>> session_id($_COOKIE['PHPSESSID']);
>> session_start();
>>
>> So what I don't understand, is why php doesn't know to
>> look at the PHPSESSID cookie and makes me spoon feed it
>> the value. This is all running on the same server under
>> the same .ini file. Sessions work fine in the main page,
>> and I know PHP is getting the session value out of the
>> cookie, because deleting the PHPSESSID cookie results in
>> a reset of all my data for the app.
>>
>> So there is some difference in curl, where just setting
>> the cookie is not enough. I have to force the cookie
>> value into session_id().
>>
>> Thanks again,
>>
>> Toby
>>
>
> Hi, Toby,
>
> Well, one thing I see right off hand:
>
> $cookie_jar = fopen($this->cookie_jar_name, 'a');
>
> You are appending to the file. I think you want 'w' here to overwrite the contents of the cookie_jar (unless you have previously
> cleared the contents in this script).
That line is from a class that handles the curl call.
The use is more like this:
$cash_page_getter = new url_getter($_SERVER['SERVER_NAME'], dirname($PHP_SELF), 'http');
$cash_page_getter->set_cookie('PHPSESSID', $session_id);
$cash_page_getter->set_cookie('other_cookie', $_COOKIE['other_cookie']);
$cash_page = $cash_page_getter->get('get_cash.html', array('return_url' => $return_url));
And the class url_getter() knows to close the cookie jar before calling the URL, and puffs
the temp file on destruction. The 'a' mode is necessary for writing multiple cookies.
Keep in mind that everything works fine on 5.2.4
> Additionally, setting the domain to www.example.com with a value of FALSE would say you have to access www.example.com - example.com
> won't work, for instance. Setting .example.com with a value of TRUE would allow access via either www.example.com or example.com.
> I don't know if this is part of the problem or not, though. Maybe not.
>
> I also don't know what's in your $this->path; normally I just use '/' here.
I could play around with that, but doesn't the fact that the cookie is available
as $_COOKIE['PHPSESSID'] mean that the cookie setting all went fine?
The crux I think is that this works:
session_id($_COOKIE['PHPSESSID']);
session_start();
but plain session_start() does not.
Thanks for your great suggestions.
Toby
|
|
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182751 is a reply to message #182749] |
Tue, 03 September 2013 18:52 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/3/2013 2:07 PM, Tobiah wrote:
> On 09/03/2013 09:59 AM, Jerry Stuckle wrote:
>> On 9/3/2013 11:58 AM, Tobiah wrote:
>>> On 08/30/2013 05:28 PM, Jerry Stuckle wrote:
>>>> On 8/30/2013 4:33 PM, Tobiah wrote:
>>>> > I have a page that needs to get another page on the fly, using
>>>> > the same session. I figured out how to stop my session and set
>>>> > the cookie on the CURL handler, and everything was cool. The
>>>> > curled page had my same session available as the calling page.
>>>> > Life was good.
>>>> >
>>>> > Now something has changed after upgrading from 5.2.4 to 5.3.10.
>>>> > My session was no longer available on the curled page. What's
>>>> > strange is that the PHPSESSID cookie was still being set, and
>>>> > hit had the correct value.
>>>> >
>>>> > Here is the weirdest part. If I do this:
>>>> >
>>>> > session_id($_COOKIE['PHPSESSID']);
>>>> > session_start();
>>>> >
>>>> > The session is there! But why isn't php taking
>>>> > the cookie as the id all by itself? Regular
>>>> > pages (not curled) all work as before. All of
>>>> > our websites work fine on the new version, except
>>>> > for this one curl call. I could update 100's of
>>>> > websites to fix them with the added lines, but
>>>> > I'd really rather find out why the curled page
>>>> > is not taking the session_id from the PHPSESSID
>>>> > cookie.
>>>> >
>>>> > Thanks!
>>>> >
>>>> > Toby
>>>>
>>>> I don't know what would have changed in the PHP update. But you
>>>> haven't shown us the failing (cURL) code - so anything would be a
>>>> guess.
>>>>
>>>> Are you trying to access a PHP script on a different server (or
>>>> domain)? Or what are you trying to do specifically?
>>>>
>>>
>>>
>>> So I'm executing PHP, and I need to grab the HTML from another
>>> url on the same domain. It's easy to use curl for this, but
>>> I need the other url to execute PHP with the same session id as
>>> the calling script.
>>>
>>> I'm doing something like this:
>>>
>>> $session_id = session_id();
>>> session_write_close();
>>>
>>> Then I make a cookie jar of the Netscape type and point to it:
>>>
>>> $cookie = sprintf("%s\t%s\t%s\t%s\t%s\t%s\t%s\n",
>>> $this->host, "FALSE", "/$this->path/", "FALSE",
>>> "0", $key, $val
>>> );
>>> $cookie_jar = fopen($this->cookie_jar_name, 'a');
>>> fwrite($cookie_jar, $cookie);
>>> fclose($cookie_jar);
>>>
>>> $ch = curl_init($this->url);
>>> curl_setopt($ch, CURLOPT_COOKIEFILE, $this->cookie_jar_name);
>>>
>>> I set some other options, including CURLOPT_POST and
>>> CURLOPT_RETURNTRANSFER. I've tried some others that don't
>>> seem to matter either way:
>>>
>>> CURLOPT_USERAGENT
>>> CURLOPT_FOLLOWLOCATION
>>> CURLOPT_SSL_VERIFYPEER
>>> CURLOPT_SSL_VERIFYHOST
>>> CURLOPT_FORBID_REUSE
>>>
>>> $other_html_page = curl_exec($ch);
>>>
>>> So, under php 5.2.4, the 'other' page php
>>> sees the session and the page runs correctly.
>>> Now, under 5.3.10, I have to do this on the other page:
>>>
>>> session_id($_COOKIE['PHPSESSID']);
>>> session_start();
>>>
>>> So what I don't understand, is why php doesn't know to
>>> look at the PHPSESSID cookie and makes me spoon feed it
>>> the value. This is all running on the same server under
>>> the same .ini file. Sessions work fine in the main page,
>>> and I know PHP is getting the session value out of the
>>> cookie, because deleting the PHPSESSID cookie results in
>>> a reset of all my data for the app.
>>>
>>> So there is some difference in curl, where just setting
>>> the cookie is not enough. I have to force the cookie
>>> value into session_id().
>>>
>>> Thanks again,
>>>
>>> Toby
>>>
>>
>> Hi, Toby,
>>
>> Well, one thing I see right off hand:
>>
>> $cookie_jar = fopen($this->cookie_jar_name, 'a');
>>
>> You are appending to the file. I think you want 'w' here to overwrite
>> the contents of the cookie_jar (unless you have previously
>> cleared the contents in this script).
>
> That line is from a class that handles the curl call.
> The use is more like this:
>
> $cash_page_getter = new url_getter($_SERVER['SERVER_NAME'],
> dirname($PHP_SELF), 'http');
> $cash_page_getter->set_cookie('PHPSESSID', $session_id);
> $cash_page_getter->set_cookie('other_cookie', $_COOKIE['other_cookie']);
> $cash_page = $cash_page_getter->get('get_cash.html', array('return_url'
> => $return_url));
>
So which way are you doing it? Are you using set_cookie() or a cookie
file (or both)?
> And the class url_getter() knows to close the cookie jar before calling
> the URL, and puffs
> the temp file on destruction. The 'a' mode is necessary for writing
> multiple cookies.
>
OK, as long as you delete the $cookie_jar file at the end (I hope you're
using a temporary filename and not a fixed one - in the latter case
you'll have trouble if two people happen to be executing this script at
the same time).
> Keep in mind that everything works fine on 5.2.4
>
And doesn't work now...
>> Additionally, setting the domain to www.example.com with a value of
>> FALSE would say you have to access www.example.com - example.com
>> won't work, for instance. Setting .example.com with a value of TRUE
>> would allow access via either www.example.com or example.com.
>> I don't know if this is part of the problem or not, though. Maybe not.
>>
>> I also don't know what's in your $this->path; normally I just use '/'
>> here.
>
> I could play around with that, but doesn't the fact that the cookie is
> available
> as $_COOKIE['PHPSESSID'] mean that the cookie setting all went fine?
>
Do you see the cookie being set in the script you are calling?
> The crux I think is that this works:
>
> session_id($_COOKIE['PHPSESSID']);
> session_start();
>
> but plain session_start() does not.
>
> Thanks for your great suggestions.
>
> Toby
>
This tells me Christopher might be on to something I overlooked - you
should check his questions.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Strange url session behaviour after upgrade to 4.3 [message #182756 is a reply to message #182750] |
Wed, 04 September 2013 17:38 |
Tobiah
Messages: 30
Registered: April 2011
Karma: 0
|
Member |
|
|
On 09/03/2013 11:38 AM, Christoph Michael Becker wrote:
> Tobiah wrote:
>
>> The crux I think is that this works:
>>
>> session_id($_COOKIE['PHPSESSID']);
>> session_start();
>>
>> but plain session_start() does not.
>
> You may consider checking the PHP ini settings session.name and
> session.use_cookies.
>
session.name = PHPSESSID
session.use_cookies = 1
I wasn't looking too much at the php.ini because the sessions
work fine when loading normal pages. I know I'm using the PHPSESSID
cookie, because when I delete that cookie, my session goes away.
The only difference here is that instead of using a browser, I'm
using curl.
I know that curl is setting the cookie because of the code quoted
above.
Thanks,
Tobiah
|
|
|
|
| Strange url session behaviour after upgrade to 5.3 (was: Strange url session behaviour after upgrade to 4.3) [message #182762 is a reply to message #182756] |
Thu, 05 September 2013 22:23 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Tobiah wrote:
> On 09/03/2013 11:38 AM, Christoph Michael Becker wrote:
>> Tobiah wrote:
>>> The crux I think is that this works:
>>>
>>> session_id($_COOKIE['PHPSESSID']);
>>> session_start();
>>>
>>> but plain session_start() does not.
>>
>> You may consider checking the PHP ini settings session.name and
>> session.use_cookies.
>
> session.name = PHPSESSID
> session.use_cookies = 1
>
> I wasn't looking too much at the php.ini because the sessions
> work fine when loading normal pages. I know I'm using the PHPSESSID
> cookie, because when I delete that cookie, my session goes away.
> The only difference here is that instead of using a browser, I'm
> using curl.
>
> I know that curl is setting the cookie because of the code quoted
> above.
Still, the culprit appears to be the “session.name” or “session.use_cookies”
configuration setting. Both settings being PHP_INI_ALL-changeable, they can
be overridden by
- using the Apache “php_admin_value” and “php_value” directives in
httpd.conf (including Virtual Host configurations), .htaccess, or
.user.ini;
- calling ini_set() prior to session_start() or
- calling session_name() prior to session_start().
(In theory, you can configure it in the Windows Registry as well, but
I think php.ini settings override the settings in the Windows Registry.
I may be wrong.)
In fact, this is recommended for “session.name”, so that each application on
a server uses its own session name (unless there is a reason that two
applications use the same session data).
It would probably be best to make sure what is the setting of “session.name”
and “session_use_cookies” before you call session_start(), by inserting
phpinfo(INFO_GENERAL | INFO_CONFIGURATION);
See also:
<http://php.net/manual/en/session.configuration.php>
<http://php.net/manual/en/configuration.changes.modes.php>
<http://php.net/session_name>
<http://php.net/phpinfo>
Please use your full (real) name.
I have also fixed the Subject header field. Please be more careful next
time.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]