| 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:
|
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
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]