Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10711

Re: Strange url session behaviour after upgrade to 4.3

Show all headers | View raw

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@attglobal.net
==================

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Strange url session behaviour after upgrade to 4.3 Tobiah <toby@tobiah.org> - 2013-08-30 13:33 -0700
  Re: Strange url session behaviour after upgrade to 4.3 Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-30 20:28 -0400
    Re: Strange url session behaviour after upgrade to 4.3 Tobiah <toby@tobiah.org> - 2013-09-03 08:58 -0700
      Re: Strange url session behaviour after upgrade to 4.3 Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-03 12:59 -0400
        Re: Strange url session behaviour after upgrade to 4.3 Tobiah <toby@tobiah.org> - 2013-09-03 11:07 -0700
          Re: Strange url session behaviour after upgrade to 4.3 Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-03 20:38 +0200
            Re: Strange url session behaviour after upgrade to 4.3 Tobiah <toby@tobiah.org> - 2013-09-04 10:38 -0700
              Strange url session behaviour after upgrade to 5.3 (was: Strange url session behaviour after upgrade to 4.3) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-09-06 00:23 +0200
          Re: Strange url session behaviour after upgrade to 4.3 Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-03 14:52 -0400
  Re: Strange url session behaviour after upgrade to 4.3 Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-31 19:58 +0200
  Re: Strange url session behaviour after upgrade to 4.3 Luuk <luuk@invalid.lan> - 2013-08-31 20:47 +0200

csiph-web