Re: [PHP-DEV] Re: Bug #14540 Updated: sessions and register_globals

[Yasuo Ohgaki]

[EMAIL PROTECTED] wrote:

> On Sun, 16 Dec 2001, Yasuo Ohgaki wrote:
> 
> 
>>[EMAIL PROTECTED] wrote:
>>
>>
>>>Hello,
>>>
>>>On Sun, 16 Dec 2001, John Lim wrote:
>>>
>>>
>>>
Doesn't this seem counter-intuitive? Can we improve the implementation
somehow?


>>
>>I think it's not a problem in code, but a documentation problem.
>>Many people are confused. I'll update document  ;)
>>
> 
> I'm already working on that...
> 


Ok. It's fine for me ;)
I'll spend time for mod_pgsql session handler then.

-- 
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #14540 Updated: sessions and register_globals

[derick]

On Sun, 16 Dec 2001, Yasuo Ohgaki wrote:

> [EMAIL PROTECTED] wrote:
>
> > Hello,
> >
> > On Sun, 16 Dec 2001, John Lim wrote:
> >
> >
> >>Doesn't this seem counter-intuitive? Can we improve the implementation
> >>somehow?
> >>
>
>
> I think it's not a problem in code, but a documentation problem.
> Many people are confused. I'll update document  ;)

I'm already working on that...

Derick

>
> --
> Yasuo Ohgaki
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #14540 Updated: sessions and register_globals

[Yasuo Ohgaki]

[EMAIL PROTECTED] wrote:

> Hello,
> 
> On Sun, 16 Dec 2001, John Lim wrote:
> 
> 
>>Doesn't this seem counter-intuitive? Can we improve the implementation
>>somehow?
>>


I think it's not a problem in code, but a documentation problem.
Many people are confused. I'll update document  ;)

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #14540 Updated: sessions and register_globals

[derick]

Hello,

On Sun, 16 Dec 2001, John Lim wrote:

> Doesn't this seem counter-intuitive? Can we improve the implementation
> somehow?

It does not to me, you need to check if $PIPPO exist in the session, and
the only way (when register globals is off) is to do that with isset
($_SESSION['PIPPO']).

Derick

>
> Regards, John
>
> <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > ID: 14540
> > Updated by: derick
> > Reported By: [EMAIL PROTECTED]
> > Status: Bogus
> > Bug Type: Session related
> > Operating System: linux 2.2.18 - glibc 2.1.3
> > PHP Version: 4.1.0
> > New Comment:
> >
> > Oops,
> >
> > here is the explanation:
> >
> > the function 'session_register()' 'registers' a variabele to a session. In
> other words, when the script ends, the value of this variabele is stored
> with the session.
> >
> > On the first run $PIPPO is empty (of course), and it is set to 'ONE'.
> > At the end of the script, the value is stored in the session file.
> >
> > At the second run, (PIPPO is still registered to the session, so
> session_register has no effect), empty($PIPPO) evalutes to TRUE again,
> because the value is in $_SESSION['PIPPO'], and thus PIPPO is set to 'ONE'
> again.
> > At the end of the script, the value of $PIPPO ('ONE') is saved to the
> session again.
> >
> > You can see more of this behavior, if you set error_reporting(E_ALL) to on
> in the script.
> >
> > Hope this explained it,
> > regards,
> >
> > Derick
> >
> > Previous Comments:
> > 
> >
> > [2001-12-16 05:15:53] [EMAIL PROTECTED]
> >
> > Hello,
> >
> > let me explain this,
> >
> > 
> >
> > [2001-12-15 22:32:36] [EMAIL PROTECTED]
> >
> > There is something I don't understand.
> >
> > I've updated to v4.1.0 and noticed that the recommended
> > configuration defaults register_globals to *Off*. I
> > understand the security reasons behind this choice. I've
> > tried to run one of my projects with the new interpreter
> > and the recommended settings (register_globals=Off). After
> > resolving a plenty of warnings, I noticed that things were
> > not working as I expected.
> >
> > This is a sample code:
> >
> >  > session_register('PIPPO');
> > if (empty($PIPPO)) {
> > $PIPPO = "ONE";
> > } else {
> > $PIPPO = "TWO";
> > }
> >
> > $sidfile = "/tmp/sess_" . $_COOKIE['PHPSESSID'];
> >
> > echo "Session file $sidfile contains: ";
> > readfile($sidfile);
> > echo "";
> >
> > echo "The value is: $PIPPO";
> > ?>
> >
> >
> > When I run and reload the script I get:
> >
> > Session file /tmp/sess_87...blahblah...3e contains:
> >
> > PIPPO|s:3:"ONE";maxrating|N;
> >
> > The value is: ONE
> >
> > Why the first run sets the session variable to "ONE" and
> > the second run can't get it's value? In the latter case I
> > guess the answer is: "because you have to access it through
> > $HTTP_SESSION_VARS", but ... shouldn't it had to be the
> > same in the former case?
> >
> >
> > 
> >
> >
> >
> > Edit this bug report at http://bugs.php.net/?id=14540&edit=1
> >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #14540 Updated: sessions and register_globals

[John Lim]

Hi Derick

Doesn't this seem counter-intuitive? Can we improve the implementation
somehow?

Regards, John

<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> ID: 14540
> Updated by: derick
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: Session related
> Operating System: linux 2.2.18 - glibc 2.1.3
> PHP Version: 4.1.0
> New Comment:
>
> Oops,
>
> here is the explanation:
>
> the function 'session_register()' 'registers' a variabele to a session. In
other words, when the script ends, the value of this variabele is stored
with the session.
>
> On the first run $PIPPO is empty (of course), and it is set to 'ONE'.
> At the end of the script, the value is stored in the session file.
>
> At the second run, (PIPPO is still registered to the session, so
session_register has no effect), empty($PIPPO) evalutes to TRUE again,
because the value is in $_SESSION['PIPPO'], and thus PIPPO is set to 'ONE'
again.
> At the end of the script, the value of $PIPPO ('ONE') is saved to the
session again.
>
> You can see more of this behavior, if you set error_reporting(E_ALL) to on
in the script.
>
> Hope this explained it,
> regards,
>
> Derick
>
> Previous Comments:
> 
>
> [2001-12-16 05:15:53] [EMAIL PROTECTED]
>
> Hello,
>
> let me explain this,
>
> 
>
> [2001-12-15 22:32:36] [EMAIL PROTECTED]
>
> There is something I don't understand.
>
> I've updated to v4.1.0 and noticed that the recommended
> configuration defaults register_globals to *Off*. I
> understand the security reasons behind this choice. I've
> tried to run one of my projects with the new interpreter
> and the recommended settings (register_globals=Off). After
> resolving a plenty of warnings, I noticed that things were
> not working as I expected.
>
> This is a sample code:
>
>  session_register('PIPPO');
> if (empty($PIPPO)) {
> $PIPPO = "ONE";
> } else {
> $PIPPO = "TWO";
> }
>
> $sidfile = "/tmp/sess_" . $_COOKIE['PHPSESSID'];
>
> echo "Session file $sidfile contains: ";
> readfile($sidfile);
> echo "";
>
> echo "The value is: $PIPPO";
> ?>
>
>
> When I run and reload the script I get:
>
> Session file /tmp/sess_87...blahblah...3e contains:
>
> PIPPO|s:3:"ONE";maxrating|N;
>
> The value is: ONE
>
> Why the first run sets the session variable to "ONE" and
> the second run can't get it's value? In the latter case I
> guess the answer is: "because you have to access it through
> $HTTP_SESSION_VARS", but ... shouldn't it had to be the
> same in the former case?
>
>
> 
>
>
>
> Edit this bug report at http://bugs.php.net/?id=14540&edit=1
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]