Please patch inc/auth.php with the attached diff and test the crud out
of it. Thanks. :)
On Tue, Apr 23, 2002 at 08:12:49PM -0700, Ben Curtis wrote:
> Ok, I may have found a solution... With a quick test it looks like as
> long as the initialization of the session variable happens with
> session_register on a global variable, then all reads and writes to the
> $HTTP_SESSION_VARS array work fine. For example, in inc/auth.php if I
> change the $HTTP_SESSION_VARS['group_ids'] = array(0); line to
> $group_ids = array(0); session_register('group_ids'); then I can read
> and change $HTTP_SESSION_VARS['group_ids'] just fine ($group_ids is
> global). I'm going to test this a bit more and see if it works for all
> the session variables.
>
> On Tue, Apr 23, 2002 at 08:01:38PM -0700, Ben Curtis wrote:
> > This is probably the best long term solution. Now if I had more than
> > five minutes in a week to work on it. :)
> >
> > On Wed, Apr 24, 2002 at 12:13:15AM +0100, John Wilkins wrote:
> > > This one seems to be causing a lot of problems with people!
> > >
> > > The problem (on my server anyway) really seems to be that
> > > assignments to $HTTP_SESSION_VARS['name'] dont work with
> > > regiter_globals 'on', but do with it 'off'.
> > >
> > > ie $HTTP_SESSION_VARS['one'] = "test";
> > >
> > > For information, this is on php 4.0.6 which is the default
> > > with redhat 7.2.
> > >
> > > On more recent versions of php, the $_SESSION looks to be
> > > the way to go. On older versions such as 4.0.6, the old
> > > session_register method works.... The problem seems to
> > > be in trying to find a method that works on both 'old'
> > > and 'new' releases.
> > >
> > > Could a solution - or at least a long-term fix - be to
> > > abstract the session variable assignment into a function
> > > and to code the function to detect the version of php and
> > > use the appropriate method for writing data?? This could
> > > be done in such a way that ONLY the session writing code
> > > is affected - session variable reading seems to work fine
> > > in all cases.
> > >
> > > john
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > phpbt-dev mailing list
> > > php...@li...
> > > https://lists.sourceforge.net/lists/listinfo/phpbt-dev
> >
> > _______________________________________________
> > phpbt-dev mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpbt-dev
>
> _______________________________________________
> phpbt-dev mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpbt-dev
|
