Thread: [phplib-users] PHP 5.2 and PHPlib
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Lindsay H. <fmo...@fm...> - 2008-04-11 20:12:53
|
It looks as if PHP4 is history. Distributions such as Ubuntu Linux and Gentoo Linux are discontinuing support for it, primarily for security reasons, and pushing migration to PHP5. PHP6 is in the works. I've been using PHPlib since PHP3 was the standard version. I've been going over the PHPlib code base with a view to migrating all the websites I host to PHP5, and while the PHPlib code seems to work well enough, I note that a lot of code in PHPlib dates back to PHP3, and there are numerous shortcuts and other improvements in the code base and functionality in PHP5 that would clean up the code and very possibly improve it. Has anyone looked at the following issues? * The code should assume that register_globals is off. It's a major security risk, disabled by default in recent distributions of PHP, and will be dropped altogether in PHP6. Dropping tests and conditionals in PHPLib based on the value of register_globals and making register_globals = 0 a necessary precondition for running PHPlib (it should be a necessary precondition for running PHP!) would simplify the PHPlib code. The same caveats apply to session.use_trans_sid. * $_SERVER, $_POST, $_COOKIE superglobals could be substituted for $HTTP_SERVER_VARS, $HTTP_POST_VARS, etc. and the global declarations eliminated from the code. This would clean things up a bit. * The $classname class property is a holdover from PHP3, where it was required, I believe, in order to serialize classes. My understanding is that it's no longer needed. Does it serve any function at all? Could it be dropped altogether? * Some very nice coding efficiencies are available in PHP5 by using the __autoload() function. Reorganizing PHPlib's file naming system would provide at least a hook to implement this. * Is it still necessary to have the option of storing session data in a database rather than using PHP's native session management? * Other points, questions ..... I've been doing a bit of work on session4.inc to bring it in line with PHP5, plus I'm using a PEAR MDB2 based database class which I wrote which is a workalike for PHPlib's DB class, less a few of the very seldom used methods and properties. It's been 100% OK as a drop-in replacement for PHPlib's DB class wherever I've used it. I may totally out to lunch with this, but thought I'd write this list and see if anyone else is interested. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | |
|
From: Lindsay H. <fmo...@fm...> - 2008-04-12 01:04:39
|
On Fri, 2008-04-11 at 19:00 -0500, Mike Green wrote: > I still use the PHPLib DB and Template classes a lot. So bringing > these up-to-date and/or making them a part of PEAR, without changing > their APIs would, for me, be a great benefit. I'm stuck with PHPlib's Cart class for several customer online shopping sites :-) It's simple and rather nice, and I've morphed and expanded it to suit my needs, but I note that it's not even documented on the PHPlib website anymore. I've never used PHPlib's Template class, although I've recently started using Smarty templates on some of my newer projects. Smarty is under active development. > I stopped using PHPLib sessions in favor of using PHP native sessions > a while back. And I have written my own routines to replace OOForms > and the authentication functionality of PHPLib. I'm afraid that I am > quite guilty, however, of not keeping the same APIs for these. So, > even if I were to clean them up and properly document them, they would > not be drop-in substitutes for those of PHPLib. :-( Because I have a bunch of customer websites built on top of PHPlib I pretty much have to keep at least the application-level class method and object API consistent. > Writing the two paragraphs above makes me feel more than a little > hypocritical -- having asked that others improve upon the DB and > Template classes while keeping the old APIs and at the same time not > keeping the APIs for the OOForms and authentication routines for my > own replacements for these. :-[ There's some pretty arcane stuff in the PHPlib API such as the haltmsg() and link_id() methods in the DB_Sql class. I dropped some of these, with no loss of functionality as far as my applications are concerned. I intentionally crafted the API on my DB class to work with PHPlib since there are so many other classes in PHPlib that require DB access, and also because I thought I might want to share it. I'll send it to you in private email. The only reason to keep the APIs constant for you own code is if you plan to share it, or integrate it into existing applications which expect it. I go both ways on this. I've put together, for instance, a simple "uservar" class that handles user variables better than does PHPlib's User class, and has only 4 methods and a constructor, and a PermAuth class that's based on PEAR::Auth and is a functional equivalent of the Perm class in PHPlib but is used quite differently. I'm pleased to note that PHPlib seems to work quite well with PHP5, so it's still in my toolkit, although all the PHPlib documentation talks about PHP3, and about PHP4 as if it were something new. Most hosting admins these days are migrating off of PHP4 as fast as they can since the security folks at the PHP project have thrown up their hands on it and new LAMP installs are all based on PHP5. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | |
|
From: Marko K. <mk...@mc...> - 2008-04-14 11:00:14
|
Hi Lindsay, if you've got a version to share in private for a start I am interested in receiving one as well. I am quite interested to see whether things work for my case (using session4.inc) as well. BTW, which phplib version did you use as a starting point? Regards, Marko P.S.: Unfortunately the design of my application is still based on RegisterGlobals=On, which is why I resurrect at the beginning all POST and GET variables from the corresponding $HTTP_*_VARS arrays... I know, bad design. But you know how it is with a running system! (Never change it.) |
|
From: Marko K. <mk...@mc...> - 2008-07-25 14:18:59
|
Hi Lindsay, any progress on the PHP5 front in relation to PHPlib? Regards, Marko |
|
From: Marko K. <mk...@mc...> - 2008-08-22 12:51:41
|
Hi all, whoever might be out there... I just downloaded Richard Archer's version 7.4a from the internet. Then remembering that I would find phplib's source also on SourceForge... Anyway, having checked its bugtracker I verified that phplib is full of HTTP_POST_VARS and similar things. That's just frightening now that I wanted to port my application to PHP5 where these VARs don't exist anymore. Feel quite lost all of a sudden. Looks like I'd have to step back and use PHP4 again... If somebody out there has successfully applied PHPlib on PHP5 and would be willing to share the source I'd be very happy. Regards, Marko |
|
From: Lindsay H. <fmo...@fm...> - 2008-08-22 16:21:25
|
On Fri, 2008-08-22 at 14:51 +0200, Marko Käning wrote: > Hi all, > > whoever might be out there... > > I just downloaded Richard Archer's version 7.4a from the internet. Then > remembering that I would find phplib's source also on SourceForge... > > Anyway, having checked its bugtracker I verified that phplib is full of > HTTP_POST_VARS and similar things. That's just frightening now that I > wanted to port my application to PHP5 where these VARs don't exist > anymore. The long, old-style arrays can still be used by setting register_long_arrays = On your global php.ini file, or by putting the equivalent directive in one of the apache configuration files. It's also pretty easy to script a utility which will replace all of the long array names using perl, python, or even probably sed/awk from a shell script. I've done this to to replace all the short PHP tags - "<?" - in all files in a directory with the longer equivalent - "<?php", which is necessary if one wants to use XML tags in a PHP page. I have bunch of websites to move from a PHP4 box to a PHP5 box with register_long_arrays = Off and will toss together a utility or two in python to do this conversion easily. I'll post them here if anyone is interested. > Feel quite lost all of a sudden. Looks like I'd have to step back and use > PHP4 again... PHP4 is not considered up to current security standards for use on the open Internet, and is no longer supported by the PHP development group. > If somebody out there has successfully applied PHPlib on PHP5 and would be > willing to share the source I'd be very happy. I'm successfully using PHPlib on PHP 5.2. Looking at the PHPlib source, the only file that contain the long array names which I use frequently is local4.inc, which I copy and modify on a per-site basis, and so far I've simply used a global replace in vim to do the name conversion. -- Lindsay Haisley |"Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate |<http://pubkeys.fmp.com> http://www.fmp.com | dandelions" | | (Pamela Jones) | |
|
From: Layne W. <la...@dr...> - 2008-08-22 16:30:35
|
>Hi all,
>
>whoever might be out there...
>
>I just downloaded Richard Archer's version 7.4a from the
>internet. Then remembering that I would find phplib's source
>also on SourceForge...
>
>Anyway, having checked its bugtracker I verified that phplib is
>full of HTTP_POST_VARS and similar things. That's just
>frightening now that I wanted to port my application to PHP5
>where these VARs don't exist anymore.
Marko,
I don't know about Richard's release - AFAIK the best, most
up-to-date is using the php-lib-stable repository branch. In
January 2007, I committed changes that only used the HTTP_*_VARS
form when the superglobals were not present - you might want to
double-check the source code to see if this is the case. E.g.
session.inc, lines 92-98:
if (!isset($_POST)) {
global $HTTP_COOKIE_VARS, $HTTP_GET_VARS,
$HTTP_POST_VARS, $HTTP_SERVER_VARS;
$_COOKIE = $HTTP_COOKIE_VARS;
$_POST = $HTTP_POST_VARS;
$_GET = $HTTP_GET_VARS;
$_SERVER = $HTTP_SERVER_VARS;
}
This pattern allowed for backwards compatibility (pre-4.1) and
allows you to run without the long vars arrays support.
--
Layne Weathers
|
|
From: Frank B. <fb...@sy...> - 2008-08-22 17:52:44
|
Layne Weathers wrote:
>> Hi all,
>>
>> whoever might be out there...
>>
>> I just downloaded Richard Archer's version 7.4a from the
>> internet. Then remembering that I would find phplib's source
>> also on SourceForge...
>>
>> Anyway, having checked its bugtracker I verified that phplib is
>> full of HTTP_POST_VARS and similar things. That's just
>> frightening now that I wanted to port my application to PHP5
>> where these VARs don't exist anymore.
>
>
> Marko,
>
> I don't know about Richard's release - AFAIK the best, most
> up-to-date is using the php-lib-stable repository branch. In
> January 2007, I committed changes that only used the HTTP_*_VARS
> form when the superglobals were not present - you might want to
> double-check the source code to see if this is the case. E.g.
> session.inc, lines 92-98:
> if (!isset($_POST)) {
> global $HTTP_COOKIE_VARS, $HTTP_GET_VARS,
> $HTTP_POST_VARS, $HTTP_SERVER_VARS;
> $_COOKIE = $HTTP_COOKIE_VARS;
> $_POST = $HTTP_POST_VARS;
> $_GET = $HTTP_GET_VARS;
> $_SERVER = $HTTP_SERVER_VARS;
> }
>
> This pattern allowed for backwards compatibility (pre-4.1) and
> allows you to run without the long vars arrays support.
>
I'm wondering if 7.2b is warranted; that includes those changes?
I'm almost completed complete removal of phplib from my apps; but I've
often wondered why there was never a release after those Jan.2007 changes.
|
|
From: Richard A. <rh...@ju...> - 2008-08-22 21:16:15
|
At 1:52 PM -0400 22/8/08, Frank Bax wrote: >I'm wondering if 7.2b is warranted; that includes those changes? > >I'm almost completed complete removal of phplib from my apps; but I've >often wondered why there was never a release after those Jan.2007 changes. The version of PHPLIB in CVS only has very minor changes from the released version. The last release was rolled only to fix a security problem. Perhaps it's worth rolling a new release of the current -stable. I'm not sure I can compile the SGML documentation files any more though! Maybe I can fire up the old server I rolled the last release on... it's still sitting out in the garden shed :) Then we could do some major work on the code to remove PHP3 support and properly include PHP5 support. Is there still enough interest in PHPLIB to justify such work? I only have a couple of legacy apps running PHPLIB now, apart from the db and template classes which I use in almost every project. My main web server is still running PHP4, although I will probably be updating it before the end of the year. ...Richard. |
|
From: Lindsay H. <fmo...@fm...> - 2008-08-23 14:52:29
|
On Fri, 2008-08-22 at 21:14 -0700, aric caley wrote: > I think the current default handing of sessions in PHP sucks. I just > got bit by some security holes due to session handling. I think there > is still a need for a top notch, efficient and flexible session > handling system. The session handling in PHPlib is rooted in PHP3, before PHP implemented native session management in v4. It's database-oriented, which it no longer _needs_ to be, although I can conceive of situations in which it might be advantageous to use db-based session management as opposed to the native PHP session management. I looked at some of the PHPlib session management code a couple of years ago with a view to rewriting some of it, and I came to the conclusion that there are some API features in PHPlib's session management that can't be easily reproduced using PHP's native session management. > I also like the authentication system and it doesnt seem like there's > many other good auth systems out there. PEAR's Auth module is quite good. I believe it does challenge authentication by default. I wrote a class which I use frequently, based on the PHPlib perm and auth module APIs, using PEAR::Auth which combines both, and rides on top of native PHP4+ session management. PHPlib was written before PEAR came out. PEAR contains much of the functionality that PHPlib contains, and is pretty solid, albeit not really well documented sometimes. It seems silly to re-invent the wheel here. On the other hand, I've found that the PEAR API is often excessively rich for simple applications, and using it requires one to nail down a lot of configuration params that could easily default to reasonable values 90% or so of the time. This is why I've written several classes for my own use which rely on PEAR but present the PHPlib API, which is relatively simple, not to mention the fact that I'm already familiar with it. -- Lindsay Haisley | "Everything works | Accredited FMP Computer Services | if you let it" | by the 512-259-1190 | (The Roadie) | Austin Better http://www.fmp.com | | Business Bureau |
|
From: Lindsay H. <fmo...@fm...> - 2008-08-22 21:57:16
|
On Sat, 2008-08-23 at 07:14 +1000, Richard Archer wrote: > Is there still enough > interest in PHPLIB to justify such work? My situation here is similar to Frank's, although I have enough customer pages in use using PHPlib that I'm not going abandon it altogether - just integrate it into a PHP5 environment as-is. I've re-written some of the PHPlib classes to make use of PEAR packages, and am using these for new work. In this, I've preserved the PHPlib API inasmuch as possible since I'm familiar with it. The general configuration that I've developed for both new and old work moved into a PHP5 environment is flexible enough to allow me to change a couple of files and fully support PHPlib, or some other set of classes as I wish. Yes, I'd be quite interested in seeing PHPlib updated so as to be fully compatible with PHP5 "out of the box". The main reason I'm moving away from it is that the project appears to be more or less abandoned. -- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | | |
|
From: aric c. <gre...@gm...> - 2008-08-23 00:45:51
|
I hate seeing old things die. Then again, sometimes, you have to move on. I guess what would be needed is for someone to say hey, I'll take over this. And then, to sit down and decide which direction to take it in. Direction would depend on who else is interested and what they would like to see. My opinion is this: I think the current default handing of sessions in PHP sucks. I just got bit by some security holes due to session handling. I think there is still a need for a top notch, efficient and flexible session handling system. I also like the authentication system and it doesnt seem like there's many other good auth systems out there. I never used the ooforms. I have some ideas about auto generating forms from objects, but its way beyond ooforms. I could see moving phplib to be php 5.x only, make it fully take advantage of all php 5 features. It should probably stay being something less than a full blown framework and more a library of components where you can pick and choose. Then again frameworks are all the rage, so why not? At this point though, it almost seems like any advancement of phplib would be mostly a rewrite with some level of compatibility (and I gather that most people are going to opt for compatibility over new features), wherein the resulting package would be mostly a new framework that just uses the name PHPLib. On Fri, Aug 22, 2008 at 2:57 PM, Lindsay Haisley <fmo...@fm...>wrote: > On Sat, 2008-08-23 at 07:14 +1000, Richard Archer wrote: > > Is there still enough > > interest in PHPLIB to justify such work? > > My situation here is similar to Frank's, although I have enough customer > pages in use using PHPlib that I'm not going abandon it altogether - > just integrate it into a PHP5 environment as-is. > > I've re-written some of the PHPlib classes to make use of PEAR packages, > and am using these for new work. In this, I've preserved the PHPlib API > inasmuch as possible since I'm familiar with it. > > The general configuration that I've developed for both new and old work > moved into a PHP5 environment is flexible enough to allow me to change a > couple of files and fully support PHPlib, or some other set of classes > as I wish. > > Yes, I'd be quite interested in seeing PHPlib updated so as to be fully > compatible with PHP5 "out of the box". The main reason I'm moving away > from it is that the project appears to be more or less abandoned. > > -- > Lindsay Haisley | "In an open world, | PGP public key > FMP Computer Services | who needs Windows | available at > 512-259-1190 | or Gates" | http://pubkeys.fmp.com > http://www.fmp.com | | > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > phplib-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Aric Caley, Developer, Trixbox CE Fonality, inc. |
|
From: aric c. <gre...@gm...> - 2008-08-23 04:14:07
|
I hate seeing old things die. Then again, sometimes, you have to move on. I guess what would be needed is for someone to say hey, I'll take over this. And then, to sit down and decide which direction to take it in. Direction would depend on who else is interested and what they would like to see. My opinion is this: I think the current default handing of sessions in PHP sucks. I just got bit by some security holes due to session handling. I think there is still a need for a top notch, efficient and flexible session handling system. I also like the authentication system and it doesnt seem like there's many other good auth systems out there. I never used the ooforms. I have some ideas about auto generating forms from objects, but its way beyond ooforms. I could see moving phplib to be php 5.x only, make it fully take advantage of all php 5 features. It should probably stay being something less than a full blown framework and more a library of components where you can pick and choose. Then again frameworks are all the rage, so why not? At this point though, it almost seems like any advancement of phplib would be mostly a rewrite with some level of compatibility (and I gather that most people are going to opt for compatibility over new features), wherein the resulting package would be mostly a new framework that just uses the name PHPLib. On Fri, Aug 22, 2008 at 2:57 PM, Lindsay Haisley <fmo...@fm...>wrote: > On Sat, 2008-08-23 at 07:14 +1000, Richard Archer wrote: > > Is there still enough > > interest in PHPLIB to justify such work? > > My situation here is similar to Frank's, although I have enough customer > pages in use using PHPlib that I'm not going abandon it altogether - > just integrate it into a PHP5 environment as-is. > > I've re-written some of the PHPlib classes to make use of PEAR packages, > and am using these for new work. In this, I've preserved the PHPlib API > inasmuch as possible since I'm familiar with it. > > The general configuration that I've developed for both new and old work > moved into a PHP5 environment is flexible enough to allow me to change a > couple of files and fully support PHPlib, or some other set of classes > as I wish. > > Yes, I'd be quite interested in seeing PHPlib updated so as to be fully > compatible with PHP5 "out of the box". The main reason I'm moving away > from it is that the project appears to be more or less abandoned. > > -- > Lindsay Haisley | "In an open world, | PGP public key > FMP Computer Services | who needs Windows | available at > 512-259-1190 | or Gates" | http://pubkeys.fmp.com > http://www.fmp.com | | > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > phplib-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Aric Caley, Developer, Trixbox CE Fonality, inc. |
|
From: aric c. <gre...@gm...> - 2008-08-23 22:24:18
|
On Sat, Aug 23, 2008 at 7:52 AM, Lindsay Haisley <fmo...@fm...>wrote: > On Fri, 2008-08-22 at 21:14 -0700, aric caley wrote: > > I think the current default handing of sessions in PHP sucks. I just > > got bit by some security holes due to session handling. I think there > > is still a need for a top notch, efficient and flexible session > > handling system. > > The session handling in PHPlib is rooted in PHP3, before PHP implemented > native session management in v4. It's database-oriented, which it no > longer _needs_ to be, although I can conceive of situations in which it > might be advantageous to use db-based session management as opposed to > the native PHP session management. multiple web servers where you need to maintain the user's session no matter which one he ends up on is a good example. Or using memcache for speed as well. It boggles my mind that php by default puts session files into /tmp where anybody can get to them, with no encryption or filtering.. > > > I looked at some of the PHPlib session management code a couple of years > ago with a view to rewriting some of it, and I came to the conclusion > that there are some API features in PHPlib's session management that > can't be easily reproduced using PHP's native session management. The native sessions are easy to use, they just need better options like phplib's sessions. > > > > I also like the authentication system and it doesnt seem like there's > > many other good auth systems out there. > > PEAR's Auth module is quite good. I believe it does challenge > authentication by default. I wrote a class which I use frequently, > based on the PHPlib perm and auth module APIs, using PEAR::Auth which > combines both, and rides on top of native PHP4+ session management. > > PHPlib was written before PEAR came out. PEAR contains much of the > functionality that PHPlib contains, and is pretty solid, albeit not > really well documented sometimes. It seems silly to re-invent the wheel > here. On the other hand, I've found that the PEAR API is often > excessively rich for simple applications, and using it requires one to > nail down a lot of configuration params that could easily default to > reasonable values 90% or so of the time. This is why I've written > several classes for my own use which rely on PEAR but present the PHPlib > API, which is relatively simple, not to mention the fact that I'm > already familiar with it. Yeah, it may be that phplib has no real purpose these days, what with PEAR and the Zend framework, etc. I am even using a framework (Kohana) for new development. But I yearn for the early days of PHP programming. :) Well, not really... > > > -- > Lindsay Haisley | "Everything works | Accredited > FMP Computer Services | if you let it" | by the > 512-259-1190 | (The Roadie) | Austin Better > http://www.fmp.com | | Business Bureau > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > phplib-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Aric Caley, Developer, Trixbox CE Fonality, inc. |
|
From: aric c. <gre...@gm...> - 2008-08-23 22:24:46
|
On Sat, Aug 23, 2008 at 7:52 AM, Lindsay Haisley <fmo...@fm...>wrote: > On Fri, 2008-08-22 at 21:14 -0700, aric caley wrote: > > I think the current default handing of sessions in PHP sucks. I just > > got bit by some security holes due to session handling. I think there > > is still a need for a top notch, efficient and flexible session > > handling system. > > The session handling in PHPlib is rooted in PHP3, before PHP implemented > native session management in v4. It's database-oriented, which it no > longer _needs_ to be, although I can conceive of situations in which it > might be advantageous to use db-based session management as opposed to > the native PHP session management. multiple web servers where you need to maintain the user's session no matter which one he ends up on is a good example. Or using memcache for speed as well. It boggles my mind that php by default puts session files into /tmp where anybody can get to them, with no encryption or filtering.. > > > I looked at some of the PHPlib session management code a couple of years > ago with a view to rewriting some of it, and I came to the conclusion > that there are some API features in PHPlib's session management that > can't be easily reproduced using PHP's native session management. The native sessions are easy to use, they just need better options like phplib's sessions. > > > > I also like the authentication system and it doesnt seem like there's > > many other good auth systems out there. > > PEAR's Auth module is quite good. I believe it does challenge > authentication by default. I wrote a class which I use frequently, > based on the PHPlib perm and auth module APIs, using PEAR::Auth which > combines both, and rides on top of native PHP4+ session management. > > PHPlib was written before PEAR came out. PEAR contains much of the > functionality that PHPlib contains, and is pretty solid, albeit not > really well documented sometimes. It seems silly to re-invent the wheel > here. On the other hand, I've found that the PEAR API is often > excessively rich for simple applications, and using it requires one to > nail down a lot of configuration params that could easily default to > reasonable values 90% or so of the time. This is why I've written > several classes for my own use which rely on PEAR but present the PHPlib > API, which is relatively simple, not to mention the fact that I'm > already familiar with it. Yeah, it may be that phplib has no real purpose these days, what with PEAR and the Zend framework, etc. I am even using a framework (Kohana) for new development. But I yearn for the early days of PHP programming. :) Well, not really... > > > -- > Lindsay Haisley | "Everything works | Accredited > FMP Computer Services | if you let it" | by the > 512-259-1190 | (The Roadie) | Austin Better > http://www.fmp.com | | Business Bureau > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > phplib-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Aric Caley, Developer, Trixbox CE Fonality, inc. |
|
From: Frank B. <fb...@sy...> - 2008-08-24 21:13:38
|
Richard Archer wrote: > Then we could do some major work on the code to remove PHP3 > support and properly include PHP5 support. Is there still enough > interest in PHPLIB to justify such work? Although I've abandoned most of phplib already because I could not make it run in php5; I am still using ooh-forms and will stay tuned to see if phplib comes back to life. I would consider switching back. I don't know anything about CVS; but would it possible to setup phplib development so that there are separate packages for php5, php6, php7, etc. Might as well plan for that already. Frank |
|
From: aric c. <gre...@gm...> - 2008-08-24 21:19:27
|
who is currently in control of the project? Maybe someone new would be interested in taking over. On Sun, Aug 24, 2008 at 2:13 PM, Frank Bax <fb...@sy...> wrote: > Richard Archer wrote: > > Then we could do some major work on the code to remove PHP3 > > support and properly include PHP5 support. Is there still enough > > interest in PHPLIB to justify such work? > > > Although I've abandoned most of phplib already because I could not make > it run in php5; I am still using ooh-forms and will stay tuned to see if > phplib comes back to life. I would consider switching back. > > I don't know anything about CVS; but would it possible to setup phplib > development so that there are separate packages for php5, php6, php7, > etc. Might as well plan for that already. > > Frank > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > phplib-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Aric Caley, Developer, Trixbox CE Fonality, inc. |
|
From: Richard A. <rh...@ju...> - 2008-08-24 22:24:14
|
At 2:19 PM -0700 24/8/08, aric caley wrote: >who is currently in control of the project? Maybe someone new would >be interested in taking over. If someone new wants to "take over" they will need to post up some patches and roadmaps to the Sourceforge trackers to prove that they have the vision and competence required to manage the project. ...Richard. |
|
From: Andrew C. <ph...@ev...> - 2008-08-25 20:24:29
|
Lindsay Haisley wrote: > On Fri, 2008-08-22 at 21:14 -0700, aric caley wrote: >> I think the current default handing of sessions in PHP sucks. I just >> got bit by some security holes due to session handling. I think there >> is still a need for a top notch, efficient and flexible session >> handling system. > > The session handling in PHPlib is rooted in PHP3, before PHP implemented > native session management in v4. It's database-oriented, which it no > longer _needs_ to be, although I can conceive of situations in which it > might be advantageous to use db-based session management as opposed to > the native PHP session management. For some of my newer development, I built some wrappers around ADODB's session handling. ADODB is a PHP5 database abstraction library. That puts the session info in the database. As a database abstraction layer, ADODB is reputed to be one of the best, out performing the PEAR DB stuff by a large margin. >> I also like the authentication system and it doesnt seem like there's >> many other good auth systems out there. > > PEAR's Auth module is quite good. I believe it does challenge I wasn't entirely happy with any of the authentication systems I looked at. So, I ended up rolling my own. I do a number of things like require SSL, do challenge authentication, etc. I have it integrated with the session code (so there is one encrypted cookie). The wrappers I built support single sign-on (i.e., you can share the authentication session across multiple servers, if necessary). PHPlib's permissions system has been inadequate for several projects, resulting in some ugly work-arounds. So, I have been working with PHP gACL for some newer projects. That provides a much more flexible permissions system. It's a little difficult for a typical user to grasp, though. So, I have built some application-specific simplified interfaces for it. Conveniently, PHP gACL uses ADODB for database abstraction. Like a lot of people here, I think, I have a number of legacy applications built on PHPlib that I am not gung-ho to re-write. So, I am keen to see PHPlib keep going. I have looked at some of the frameworks and, some of them seem pretty good. It seems to require a commitment to doing everything their way, though and, I'm not sure that's for me. They all have weaknesses and, integrating the best-of-breed for any given component doesn't always work well. By contrast, I have always liked the loose coupling of the PHPlib components. Just my two cents. Andrew Crawford |
|
From: Marko K. <mk...@mc...> - 2008-09-25 07:33:36
|
Hi phplib community members, scared off by the thought that PHPlib might be incompatible with PHP 5 I did not notice what my real problem was: After doing three little changes to my setup (register_long_array=on, register_globals=on, temporally disable use of ssl) my application did what it was supposed to do. So, it is by no means as I thought it is... PHP5 still allows to run old code. Probably not in a very efficient way, but it does. I guess it would be cool to see PHPlib's user and user data managment as a PEAR module, just like Lindsay did it with the database abstraction class. PHPlib is dead, long live PHPlib! ;) Best regards, Marko |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X