phplib-users — A list for users of phplib to talk / discuss phplib

Re: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

Layne,

On Sat, Sep 21, 2002 at 07:22:10AM -0500, Layne Weathers wrote:
> > OK!
> > 
> > How many people vote for a drop in PHPlib replacement release which
> > automagically starts using PHP4 sessions with 
> > register_globals=off in your
> > existing applications
> 
> I vote yes as well.
> 

A big help would be to move the files required for Session4 stuff as 
requested in this bug report:

[ 549660 ] php4 session support
https://sourceforge.net/tracker/index.php?func=detail&aid=549660&group_id=31885&atid=403611

Then a prepend.php for session4 support can be supplied.

Cleaning up the session4 installation instructions should be simple at 
this point.

thanks,

Joe

> Layne Weathers
> Ifworld Inc. 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

On Sat, Sep 21, 2002 at 12:42:23PM +0200, Giancarlo wrote:
> Il 12:13, sabato 21 settembre 2002, Giancarlo ha scritto:
> 
> I notice now that session4 comes with its own page4.inc already.
> It all seems to have originated from the fact that session->freeze() did not 
> exist with that implementation of session4. Same as register().
> But if we now resume the session->freeze function even for session4, what 
> reaason has to be two different page.inc?
> 


I don't believe page4.inc is used after Ulf and Max split the _Custome 
class to replace the other Session4 stuff.

All my testing has been done using Session4_Custom, Session4 and the 
normal page.inc (It calls sess->freeze).

Re: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

On Sat, Sep 21, 2002 at 05:32:25PM +0530, Dr Tarique Sani wrote:
> On Sat, 21 Sep 2002, Giancarlo wrote:
> 
> > 
> > The resumption of the $auth object used to happen in session->start(), as all 
> > the other frozen ojcets an values.
> > So page.inc does really need any change?
> > If we already globalize all session data, among which the auth object, do we 
> > need that? But I tend to go into confusion.
> 
> Well my thinking stemmed from the fact that page4.inc already exists and
> would be less work than session4.inc 
>

From Max's explanation, there is no page4.inc, just uses the regular 
page.inc.  However with register_globals off page_close must be called 
just as before.
 
> BUT yes the right way to go is to put this in session->start() and
> session->freeze()
> 

yes.  Look at the patch.

> 
> Remember folks we are talking here drop in replacement - so calls to
> page_close() will be already there
> 
> Tarique 

Re: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

On Sat, Sep 21, 2002 at 02:53:54PM +0530, Dr Tarique Sani wrote:
> On Fri, 20 Sep 2002, Giancarlo wrote:
> 
> > Just for backward and API comoatibility, I'd add write a register() function 
> > for the  php4 session 
> > 
> > This way session4  can be plugged into any previous phplib based app.
> 
> OK!
> 
> How many people vote for a drop in PHPlib replacement release which
> automagically starts using PHP4 sessions with register_globals=off in your
> existing applications
> 
> (may be this can be labled as a separate release)
> 
> I would vote yes
> 
> And presuming a mojority of yes
> 
> Let us look at what needs to be done?
> 
> Session4.inc will require minimal work - Joe are you up to writing it?
>

Um, how is this different than the patch already supplied?
 
> Page4.inc with $auth = &$_SESSION["auth"] makes auth.inc work properly,
> simlarly for perms
> 

shouldn't be needed.

Re: [Phplib-users] PHPLIB without 'register_globals'

[Giancarlo <gia...@na...>]

Il 12:42, sabato 21 settembre 2002, Giancarlo ha scritto:

> It all seems to have originated from the fact that session->freeze() did

.....

So I believe I found a way to have it seamingless work with register_g on and 
off.
I can even change it on the fly in .htaccess.

Here is the new register function of session4.inc by Joe Stewart, ad from his 
published patch

...............
  function register ($var_names) {


    if (!is_array($var_names)) {
      // spaces spoil everything
      $var_names = trim($var_names);
      $var_names=explode(" ", $var_names);
    }

    // If register_globals is off -> store session variables values
    if(!(bool) ini_get('register_globals')) {
      foreach ($var_names as $key => $value ) {
        global $$value;
          if (!isset($_SESSION[$value]))
            {
            $_SESSION[$value]= $$value;
            }
      }
    }
   else {
      return session_register($var_names);
    }
  } // end func register

...........

I use this with the standard page.inc, with a minor change, that fits for 
phplib session too (no need for a separate page4.inc)


  if (isset($sess)) {
###    if ($_PHPLIB["version"] != "4") {
      $sess->freeze();
###    }


Maybe you can try it. I cannnot access sf patches to publish it now.
I think this should work mostly also for migrating from phplib session to 
php4 session, without modifying the API. I haven't tried that
As of now I've simply tried the simple page, the login and registerform 
(kris/test example from php-lib), and I can switch globals on and off 
anytime...

I hope I've not missed any thing BTW.
To complete this there are other functions to reincorporate, as unregister 
etc. But basically should be straightfwd.

Gian

Re: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Sat, 21 Sep 2002, Giancarlo wrote:

> 
> The resumption of the $auth object used to happen in session->start(), as all 
> the other frozen ojcets an values.
> So page.inc does really need any change?
> If we already globalize all session data, among which the auth object, do we 
> need that? But I tend to go into confusion.

Well my thinking stemmed from the fact that page4.inc already exists and
would be less work than session4.inc 

BUT yes the right way to go is to put this in session->start() and
session->freeze()


Remember folks we are talking here drop in replacement - so calls to
page_close() will be already there

Tarique 

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

RE: [Phplib-users] PHPLIB without 'register_globals'

[Layne W. <la...@if...>]

> OK!
> 
> How many people vote for a drop in PHPlib replacement release which
> automagically starts using PHP4 sessions with 
> register_globals=off in your
> existing applications

I vote yes as well.

Layne Weathers
Ifworld Inc. 

Re: [Phplib-users] PHPLIB without 'register_globals'

[Giancarlo <gia...@na...>]

Il 12:13, sabato 21 settembre 2002, Giancarlo ha scritto:
> > Let us look at what needs to be done?
> > Session4.inc will require minimal work - Joe are you up to writing it?
> > Page4.inc with $auth = &$_SESSION["auth"] makes auth.inc work properly,
> > simlarly for perms
>
> The resumption of the $auth object used to happen in session->start(), as
> all the other frozen ojcets an values.
> So page.inc does really need any change?
> If we already globalize all session data, among which the auth object, do
> we need that? But I tend to go into confusion.
>
> Gian

I notice now that session4 comes with its own page4.inc already.
It all seems to have originated from the fact that session->freeze() did not 
exist with that implementation of session4. Same as register().
But if we now resume the session->freeze function even for session4, what 
reaason has to be two different page.inc?

page4.inc says:
......
    if (($sess->auto_init != "") && ($sess->in == "")) {
      $sess->in = 1;
      include($_PHPLIB["libdir"] . $sess->auto_init);
//      if ($sess->secure_auto_init != "") {
//        $sess->freeze();
//      }
......

What is wrong with that secure_auto_init, once we have the session->freeze() 
back? Can't we uncomment those back, and so revert to an unique page.inc?

Gian

Re: [Phplib-users] PHPLIB without 'register_globals'

[Giancarlo <gia...@na...>]

> Let us look at what needs to be done?
> Session4.inc will require minimal work - Joe are you up to writing it?
> Page4.inc with $auth = &$_SESSION["auth"] makes auth.inc work properly,
> simlarly for perms

The resumption of the $auth object used to happen in session->start(), as all 
the other frozen ojcets an values.
So page.inc does really need any change?
If we already globalize all session data, among which the auth object, do we 
need that? But I tend to go into confusion.

Gian

Re: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Fri, 20 Sep 2002, Giancarlo wrote:

> Just for backward and API comoatibility, I'd add write a register() function 
> for the  php4 session 
> 
> This way session4  can be plugged into any previous phplib based app.

OK!

How many people vote for a drop in PHPlib replacement release which
automagically starts using PHP4 sessions with register_globals=off in your
existing applications

(may be this can be labled as a separate release)

I would vote yes

And presuming a mojority of yes

Let us look at what needs to be done?

Session4.inc will require minimal work - Joe are you up to writing it?

Page4.inc with $auth = &$_SESSION["auth"] makes auth.inc work properly,
simlarly for perms

OOHForms register global off patch is already there. Template does not
have an issue with register_globals = off

What else?

Lets have a beta of this out by mid next week!!!

Tarique 

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

On Fri, Sep 20, 2002 at 07:11:51PM +0400, Maxim Derkachev wrote:
> 
> Just wanted to clear misunderstanding. Session4_Custom is extension
> of Session4. Basic PHP4 session interface (which is the thing that
> have to be patched) is present in Session4, NOT Session4_Custom.
> Session4_Custom only extends Session4 with a provider of a custom save
> handler. It need not be patched to resolve the register_globals issue,
> it simply has nothing to do with the session variables at all, global or not.
> The issue is in Session4.
> 

Thank you for clarifying this.  This can be easily moved to Session4 if it 
is proven worthy.

I only saw that Session4_Custom already was overriding start and freeze 
conveniently.

Joe

> -- 
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru 

Re[4]: [Phplib-users] PHPLIB without 'register_globals'

[Maxim D. <max...@bo...>]

Hello Joe,

Friday, September 20, 2002, 6:49:31 PM, you wrote:
JS> This is the basis of a patch submitted to sf.net -

JS> [ 612139 ] Session4_Custom w/reg. globals off
JS> http://sourceforge.net/tracker/index.php?func=detail&aid=612139&group_id=31885&atid=403613

JS> Please post comments.

Just wanted to clear misunderstanding. Session4_Custom is extension
of Session4. Basic PHP4 session interface (which is the thing that
have to be patched) is present in Session4, NOT Session4_Custom.
Session4_Custom only extends Session4 with a provider of a custom save
handler. It need not be patched to resolve the register_globals issue,
it simply has nothing to do with the session variables at all, global or not.
The issue is in Session4.

-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: Re[2]: [Phplib-users] PHPLIB without 'register_globals'

[Joe S. <jo...@be...>]

On Thu, Sep 19, 2002 at 11:16:43PM +0200, Giancarlo wrote:
> 
> Sorry if this sounds nonsense, but I don't know the matter too well.
> What is there wrong in setting them to global before? Wasn't that the usual 
> behaviour. 
> PHP will not set them back to globals for us, but can't we set them as 
> globals for urselves.  This is no input fields. And then finalize them into 
> the $_SESSION  array at page_close/freeze?
> 
> Gian
> 

This is the basis of a patch submitted to sf.net -

[ 612139 ] Session4_Custom w/reg. globals off
http://sourceforge.net/tracker/index.php?func=detail&aid=612139&group_id=31885&atid=403613

Please post comments.

thanks,

Joe

Re: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Fri, 20 Sep 2002, Michael Chaney wrote:

> > theoritically) that modifications / improvements to your library are
> > contributed back to public domain. 
> 
> I am using the PHPLIB db abstraction, but it's LGPL.  If it's rewritten
> under a BSD license, then I can relicense my code as BSD.  Actually, if

Well it is your personal choice BUT I prefer to release my code under LGPL
or Maybe under PHP License

Yes having DB abstraction is good 

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: [Phplib-users] PHPLIB without 'register_globals'

[Michael C. <mdc...@mi...>]

On Fri, Sep 20, 2002 at 08:32:34AM +0530, Dr Tarique Sani wrote:
> On Thu, 19 Sep 2002, Michael Chaney wrote:
> 
> > Good point, I'll relicense it at the next release.  I'm actually willing
> > to license under a BSD license if someone will rewrite the db
> > abstraction layer under that license.
> 
> Why not use PHPlib db abstraction? 
> 
> Note - I have still not looked at the code :-)
> 
> LGPL is a perfect license for libraries, it ensures (at least
> theoritically) that modifications / improvements to your library are
> contributed back to public domain. 

I am using the PHPLIB db abstraction, but it's LGPL.  If it's rewritten
under a BSD license, then I can relicense my code as BSD.  Actually, if
I change the mysql_auth.inc file to just use the mysql functions (a 10
minute change), I could get by without the db abstraction.  However, I
happen to like the db abstraction and wish to keep it around.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Thu, 19 Sep 2002, Michael Chaney wrote:

> Good point, I'll relicense it at the next release.  I'm actually willing
> to license under a BSD license if someone will rewrite the db
> abstraction layer under that license.

Why not use PHPlib db abstraction? 

Note - I have still not looked at the code :-)

LGPL is a perfect license for libraries, it ensures (at least
theoritically) that modifications / improvements to your library are
contributed back to public domain. 

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: Re[2]: [Phplib-users] PHPLIB without 'register_globals'

[Giancarlo <gia...@na...>]

Il 09:43, gioved=EC 19 settembre 2002, Maxim Derkachev ha scritto:
> Hello friends,
>
> MK> There was a discussion on this list about that issue concerning
> MK> session4_custom where Maxim Derkachev, the author of that nice piec=
e of
> MK> code, mentioned that he is unable to do that job right now.
>
> The problem is the session_register() & session_unregister() don't
> work with register_globals=3D'off'. Only direct assignment to $_SESSION
> array works. I don't know why the silly decision in the PHP group camp
> was made, cause it breaks compatibility but does not make any profit.
> session_register() & session_unregister() take the variable names as
> argument, and the named variables for the session_register() should be
> globals. $_SESSION needs the variable itself, and the variable does not
> need to be global -=20

Sorry if this sounds nonsense, but I don't know the matter too well.
What is there wrong in setting them to global before? Wasn't that the usu=
al=20
behaviour.=20
PHP will not set them back to globals for us, but can't we set them as=20
globals for urselves.  This is no input fields. And then finalize them in=
to=20
the $_SESSION  array at page_close/freeze?

Gian

> there could be no variables at all, indeed, we can
> assign constants to $_SESSION keys. The difference is fundamental, and =
we
> can not change the session4 class and retain compatibility, because
> $sess->register() & unregister historically take varname argument.
> But to make them work with register_globals=3Doff we need to pass them
> the variable content (or a reference) as well.
> So, the patches can be easily incorporated, but I'm sure they'll defini=
tely
> break backward compatibility.
> The question is open. Maybe I've missed something and somebody has
> something to add?

Re: [Phplib-users] PHPLIB without 'register_globals'

[Michael C. <mdc...@mi...>]

On Thu, Sep 19, 2002 at 07:09:37PM +0200, Lars Heuer wrote:
> Hi Michael,
> 
> > This is why I created the phpauth project (phpauth.com).  Ultimately,
> 
> I think one disadvantage phpauth has, is that you put it under GPL,
> PHPLib is LGPL.

Good point, I'll relicense it at the next release.  I'm actually willing
to license under a BSD license if someone will rewrite the db
abstraction layer under that license.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] PHPLIB without 'register_globals'

[Lars H. <ph...@qu...>]

Hi Michael,

> This is why I created the phpauth project (phpauth.com).  Ultimately,

I think one disadvantage phpauth has, is that you put it under GPL,
PHPLib is LGPL.

Regards,
Lars

Re: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Thu, 19 Sep 2002, Michael Chaney wrote:

> This is why I created the phpauth project (phpauth.com).  Ultimately,
> PHP is "moving on" and some new paradigms are in place.  PHPLIB was

Yesterday I have downloaded the phpauth files and will look into it soon 

BUT folks tell me what constitutes PHPlib?

sess auth and perm only?

I use OOHForms and Template much more than the above and really love them
over any other forms and template classes

Does anyone know the current status of new OOHForms from Ulf?

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

Re: [Phplib-users] PHPLIB without 'register_globals'

[Michael C. <mdc...@mi...>]

On Thu, Sep 19, 2002 at 05:53:38PM +0400, Maxim Derkachev wrote:
> Hello Tarique,
> 
> Thursday, September 19, 2002, 4:09:09 PM, you wrote:
> DTS> Yes having two API is a solution
> It is not the solution. The old PHPLib-based code will be thrown away. And
> you will never be able to mix the new code with the old.
> The only solution I see is to fork (yes, fork) PHPLib into new
> project(say PHPLib_New, like PHPAds_New), and abandon the original PHPLib
> (except for bugfixes).

This is why I created the phpauth project (phpauth.com).  Ultimately,
PHP is "moving on" and some new paradigms are in place.  PHPLIB was
created to give sessioning and authentication to PHP3.  PHP4 changed the
game completely, so it's time to move on.
 
Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: Re[6]: [Phplib-users] PHPLIB without 'register_globals'

[Dr T. S. <ta...@sa...>]

On Thu, 19 Sep 2002, Maxim Derkachev wrote:

> DTS> dirty job with $_SESSION["auth"] strewn all over the place, it works OK
> DTS> with log mode
> 
> You could simply $auth = &$_SESSION['auth'] in page.inc or something
> ... it would work without hacks.

Yep discovered it half an hour ago :-)

Tarique

-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

R: R: [Phplib-users] PEAR versus phplib

[Gaetano G. <giu...@se...>]

> Hello Gaetano,
>=20
> Thursday, September 19, 2002, 5:07:30 PM, you wrote:
> GG> My own wishes:
> GG> - make it compatible with REGISTER_GLOBALS OFF! Either have 2 API
> GG> sets or just dump the old code, I don't mind too much as=20
> long as it is compatible
> GG> with new releases of PHP.
>=20
> Yes, that's too easy. We'll have to dump nothing more than=20
> all the code based upon
> PHPLib as well with the API change :)
>=20

Ok, I know it's not THAT easy. But if phplib is to survive, it has to =
adapt to new versions of the engine.

> GG> - provide alternatives to the db-access layer, e.g.=20
> better integration w. adodb
> GG> or pear-db etc...
> Nothing in PHPLib depends on DB_SQL - one can use the db=20
> abstraction he
> likes. The only thing - if CT_SQL is used, just adapt it to the other
> db API.

Yep, exactly what I've done. What I intended to suggest is to bundle =
with the phplib distro the alternatives to CT_SQL (there are so many of =
them already), so everybody can use them instead of having to rewrite =
from scratch.

>=20
> GG> - provide integration with other php projects that do all=20
> the auth-session over again,
> GG> e.g. phpBB
> As I know, applications are usually built over the libraries, not vice
> versa. And if an app uses its own libraries and apis, there's nothing
> good in adapting other libraries for it - apps will always use the
> libraries they've initially been based upon.
>=20

Just bully (or bribe) the app writers into doing the dirty job!

Re[6]: [Phplib-users] PHPLIB without 'register_globals'

[Maxim D. <max...@bo...>]

Hello Tarique,

Thursday, September 19, 2002, 4:09:09 PM, you wrote:
DTS> Yes having two API is a solution
It is not the solution. The old PHPLib-based code will be thrown away. And
you will never be able to mix the new code with the old.
The only solution I see is to fork (yes, fork) PHPLib into new
project(say PHPLib_New, like PHPAds_New), and abandon the original PHPLib
(except for bugfixes).

DTS> BTW folks I tried (successfully) to hack auth.inc to work with
DTS> session4.inc (more like PHP 4 sessions) BUT it is a very
DTS> dirty job with $_SESSION["auth"] strewn all over the place, it works OK
DTS> with log mode

You could simply $auth =& $_SESSION['auth'] in page.inc or something
... it would work without hacks.




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: R: [Phplib-users] PEAR versus phplib

[Maxim D. <max...@bo...>]

Hello Gaetano,

Thursday, September 19, 2002, 5:07:30 PM, you wrote:
GG> My own wishes:
GG> - make it compatible with REGISTER_GLOBALS OFF! Either have 2 API
GG> sets or just dump the old code, I don't mind too much as long as it is compatible
GG> with new releases of PHP.

Yes, that's too easy. We'll have to dump nothing more than all the code based upon
PHPLib as well with the API change :)

GG> - provide alternatives to the db-access layer, e.g. better integration w. adodb
GG> or pear-db etc...
Nothing in PHPLib depends on DB_SQL - one can use the db abstraction he
likes. The only thing - if CT_SQL is used, just adapt it to the other
db API.

GG> - provide integration with other php projects that do all the auth-session over again,
GG> e.g. phpBB
As I know, applications are usually built over the libraries, not vice
versa. And if an app uses its own libraries and apis, there's nothing
good in adapting other libraries for it - apps will always use the
libraries they've initially been based upon.



-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru