phplib-users Mailing List for PHPLIB
Brought to you by:
nhruby,
richardarcher
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(106) |
Sep
(99) |
Oct
(44) |
Nov
(97) |
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(56) |
Feb
(81) |
Mar
(134) |
Apr
(69) |
May
(106) |
Jun
(122) |
Jul
(98) |
Aug
(52) |
Sep
(184) |
Oct
(219) |
Nov
(102) |
Dec
(106) |
2003 |
Jan
(88) |
Feb
(37) |
Mar
(46) |
Apr
(51) |
May
(30) |
Jun
(17) |
Jul
(45) |
Aug
(19) |
Sep
(5) |
Oct
(4) |
Nov
(12) |
Dec
(7) |
2004 |
Jan
(11) |
Feb
(7) |
Mar
|
Apr
(15) |
May
(17) |
Jun
(13) |
Jul
(5) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(21) |
Dec
(13) |
2005 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(11) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
2006 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(5) |
2007 |
Jan
(15) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(19) |
Sep
(2) |
Oct
|
Nov
|
Dec
(6) |
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
From: Lindsay H. <fmo...@fm...> - 2009-12-13 23:57:57
|
On Sun, 2009-12-13 at 15:00 -0500, A. F. Cano wrote: > On Sat, Dec 12, 2009 at 12:20:14AM -0600, Lindsay Haisley wrote: > > ... > > > > Check your php.ini file and see if register_long_arrays = On or Off. > > It was On, but right above that was "register_globals = Off". Turning > that On solved the problem. Admittedly that's the quick fix, as > register_globals should be Off. Maybe I'll dig into the code some more > and figure out how to do away with the global variables, but at least > bookmarker now works. Having register_globals on is considered a significant security risk, although in some circumstances you can get away with it. I've seen it exploited, and one of my hosting clients got in a fight with earthlink after someone exploited their code and Earthlink hosting had register-globals was on at the system level. I think the necessity of auto-registering globals was removed from PHPlib some time ago, but perhaps not from bookmarker. If the only problems you're having are with regard to logging in, you should be able to add the following lines to any file that needs these variables and the problem should be solved: $username = $_POST["username"]; $password = $_POST["password"]; -- 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: A. F. C. <af...@sh...> - 2009-12-13 21:59:11
|
On Sat, Dec 12, 2009 at 12:20:14AM -0600, Lindsay Haisley wrote: > ... > > Check your php.ini file and see if register_long_arrays = On or Off. It was On, but right above that was "register_globals = Off". Turning that On solved the problem. Admittedly that's the quick fix, as register_globals should be Off. Maybe I'll dig into the code some more and figure out how to do away with the global variables, but at least bookmarker now works. > ... Thanks a bunch for your help! Augustine |
From: Lindsay H. <fmo...@fm...> - 2009-12-12 06:20:28
|
On Fri, 2009-12-11 at 23:38 -0500, A. F. Cano wrote: > Mmm... So I installed PEAR and read quite a bit of the docs, but the > class names don't have a 1 to 1 relationship with the phplib classes. No, and the PEAR equivalent classes are much more sophisticated, with a lot more hooks. PHPlib wasn't a model or a guide when PEAR classes were written. Many times PEAR is overkill for a simple job, which is why I wrote the fmplib classes, which overlay the PHPlib API over the PEAR API. > As I was looking at something simpler than a rewrite, like replacing > class names with the newer ones from PEAR, this option got pushed to > the back burner. No, there's no such correspondence, for better or worse. > > have installed code which depends on PHPlib. I've been migrating some > > of this code to PEAR <http://pear.php.net/> routines and class by > > writing libraries which mimic the PHPlib API but rely on PEAR for their > > functionality. See <http://www.fmp.com/fmp/fmp_include/>. All the > > I downloaded these right away and as they were closer to what bookmarker > depended on, it was easier to replace class names, but then I got into > other problems, like functions that don't exist in the fmp_include > files, so it was back to square 1. The fmplib classes emulate a very large subset of the equivalent PHPlib classes. If there's something missing in them, I hope I've written the code clearly enough so that you, or anyone, could easily extend the functionality of these classes as needed. > > ... > > Check out Krumo at <http://sourceforge.net/projects/krumo/>. You'll > > find it a big help. I still find, though, that using print or echo > > calls sprinkled throughout a PHP script has its place :-) > > This was good. I installed it and it's been helping debug the problem, > in combination with print statements. I ended up installing the latest > version of phplib where bookmarker expects it, but I'm having the same > problem as with the old version. The login screen never lets me > through. With some print statements I've found that the global > variables in the php code $username and $password are not set. The > values are entered with some javascript code in a template form. Check your php.ini file and see if register_long_arrays = On or Off. This setting controls whether PHP recognizes the global arrays $HTTP_GET_VARS and friends or only the newer $_GET superglobal. PHPlib uses lots of long arrays, but modern PHP installations frequently have this variable set off. You can either turn it on, or convert the PHPlib scripts to use short arrays. I wrote a couple of conversion utilities which are available at <http://www.fmp.com/downloads/>. php_long_arrays.py converts long arrays to short arrays in code, and php_tags.py converts short PHP tags ("<?") to proper long tags ("<?php"). The programs are python scripts and self-doc, so they're easy to use. > Looking around I've found this: > > http://www.irt.org/script/1065.htm > > but in this case the kludgy fix does nothing. > > At the end of the javascript code there is document.login.submit() but > I haven't found this function yet. It's a javascript-driven way of submitting a form. > The commented write statements return what is expected, so the problem > is between document.login.submit() and the php global variables. > > Since this used to work in the days of php3, I wonder if something has > changed that deals with the transmission of the variables between > javascript and php at the server. The only true communication between JS and the server within the context of a page is the XMLHttpRequest object which is at the heart of AJAX technology. PHPlib doesn't use this, but simply relies on POST and GET to get values back to the server after a page submit. My guess is that your PHP installation doesn't properly recognize the long array globals mentioned above. -- Lindsay Haisley | "The difference between | PGP public key FMP Computer Services | a duck is because one | available at 512-259-1190 | leg is both the same" | http://pubkeys.fmp.com http://www.fmp.com | - Anonymous | |
From: A. F. C. <af...@sh...> - 2009-12-12 04:41:48
|
On Tue, Dec 08, 2009 at 09:44:19PM -0600, Lindsay Haisley wrote: > On Tue, 2009-12-08 at 22:09 -0500, A. F. Cano wrote: > > Phplib hasn't been updated in a long time, is it also > > dead? First, thanks for replying and the info below. It's taken a while to digest and learn some of this stuff... > It's kinda dead, having been upstaged by PEAR, but a lot of us still Mmm... So I installed PEAR and read quite a bit of the docs, but the class names don't have a 1 to 1 relationship with the phplib classes. As I was looking at something simpler than a rewrite, like replacing class names with the newer ones from PEAR, this option got pushed to the back burner. > have installed code which depends on PHPlib. I've been migrating some > of this code to PEAR <http://pear.php.net/> routines and class by > writing libraries which mimic the PHPlib API but rely on PEAR for their > functionality. See <http://www.fmp.com/fmp/fmp_include/>. All the I downloaded these right away and as they were closer to what bookmarker depended on, it was easier to replace class names, but then I got into other problems, like functions that don't exist in the fmp_include files, so it was back to square 1. > ... > Check out Krumo at <http://sourceforge.net/projects/krumo/>. You'll > find it a big help. I still find, though, that using print or echo > calls sprinkled throughout a PHP script has its place :-) This was good. I installed it and it's been helping debug the problem, in combination with print statements. I ended up installing the latest version of phplib where bookmarker expects it, but I'm having the same problem as with the old version. The login screen never lets me through. With some print statements I've found that the global variables in the php code $username and $password are not set. The values are entered with some javascript code in a template form. Looking around I've found this: http://www.irt.org/script/1065.htm but in this case the kludgy fix does nothing. At the end of the javascript code there is document.login.submit() but I haven't found this function yet. This is the javascript code: <script type="text/javascript"> <!-- start Javascript function doChallengeResponse() { str = document.login.username.value + ":" + MD5(document.login.password.value) + ":" + document.login.challenge.value; document.login.response.value = MD5(str); document.login.password.value = ""; //document.write(str); //document.write(MD5(document.login.password.value)); //document.write(document.login.response.value); document.login.submit(); } // end Javascript --> </script> The commented write statements return what is expected, so the problem is between document.login.submit() and the php global variables. Since this used to work in the days of php3, I wonder if something has changed that deals with the transmission of the variables between javascript and php at the server. Any other ideas out there? Thanks again for replying. Making some slow progress... Augustine |
From: Lindsay H. <fmo...@fm...> - 2009-12-09 04:24:49
|
On Tue, 2009-12-08 at 22:09 -0500, A. F. Cano wrote: > Phplib hasn't been updated in a long time, is it also > dead? It's kinda dead, having been upstaged by PEAR, but a lot of us still have installed code which depends on PHPlib. I've been migrating some of this code to PEAR <http://pear.php.net/> routines and class by writing libraries which mimic the PHPlib API but rely on PEAR for their functionality. See <http://www.fmp.com/fmp/fmp_include/>. All the class files with "fmplib" in their names are PHPlib knockoffs and generally drop-in replacements unless you're using some of the more useless and arcane features of PHPlib. There's also a PermAuth class here which you may find useful. All these have substantial and hopefully adequate documentation in the header comments. > This is my first foray into phplib so I could use a hint or two. How do > I go about debugging this? Is there a better way than to put print() > statements everywhere throughout the code? Check out Krumo at <http://sourceforge.net/projects/krumo/>. You'll find it a big help. I still find, though, that using print or echo calls sprinkled throughout a PHP script has its place :-) -- Lindsay Haisley | "Never expect the people who caused a problem FMP Computer Services | to solve it." - Albert Einstein 512-259-1190 | http://www.fmp.com | |
From: A. F. C. <af...@sh...> - 2009-12-09 03:11:34
|
Hi, Mmm... I see from the archives of this list that there hasn't been any activity in a long long time. Anybody still out there? I was using bookmarker years ago and it worked just fine. I accumulated many many bookmarks and then I upgraded from Debian woody to etch and it stopped working. Many OS, php, apache, etc... upgrades later, I got to debugging the problem. I had to change some code in bookmarker to accomodate php5 (it was written in the days of php3) but I'm now stuck with a problem with authentication. I can't log in. It appears that phplib is in charge of that, so I went looking for the latest version. In fact phplib has been updated quite a bit since the version that came packaged with bookmarker, so I installed the new files in the phplib directory where bookmarker wants it. I still can't get past the login screen (with user: bk, password: bk - the default administrator login/ password.) Is anyone using bookmarker these days? The author's web page has disappeared. Phplib hasn't been updated in a long time, is it also dead? This is my first foray into phplib so I could use a hint or two. How do I go about debugging this? Is there a better way than to put print() statements everywhere throughout the code? Augustine |
From: Marko K. <mk...@mc...> - 2009-01-21 10:12:47
|
> I am using a framework called Kohana. It has some pretty nice DB Did somebody try out CakePHP? (Looks quite similar, at least concept-wise, to Kohana.) |
From: Marko K. <mk...@mc...> - 2008-12-18 12:57:37
|
Hi Aric, > I am using a framework called Kohana. It has some pretty nice DB yesterday I finally downloaded the framework and gave it a quick try. > use that (I am hand coding my HTML using Appcelerator components). It also > supports MVC, though it does not force you, and it supports using templates > if you want, but again does not force you to. Well, I wasn't able to do much with it yet, but I see where you are coming from. Kohana definitely makes a good impression. It doesn't even need PEAR for its basic stuff. But I have to admit, that getting started with it is not so easy. Documentation and examples which I found so far don't get me going really. What I am looking for is actually an example application which requires user login and keeps user variables persistent over login sessions, just like phplib does it. But unfortunately I could not find anything like that. Could you point me into a direction? Do you know where to find more usable examples? I googled a bit, but there are so many that you don't know where to start... Where should I start if I want to understand how the MVC conept of kohana really works? Probably kohana's website is the point to start and supplies all this already and I had been simply too tired tonight when I checked it out... Anyway, any hint would be helpful! Best regards, Marko |
From: Marko K. <mk...@mc...> - 2008-12-03 08:33:02
|
Hi Lindsay and Aric, thanks for your response. Especially the drop-in replacement by fmplib sounds interesting for a quick migration. I'll definitely have a look at it. Well, MVC ... that was one item I missed in my list... ;) I'll check this out too. Thanks again. Best regards, Marko |
From: Lindsay H. <fmo...@fm...> - 2008-12-02 17:27:57
|
Marko, I've written several classes which you may find useful. To a greater or lesser degree the emulate phplib classes and I use them regularly in website development. They're based on PEAR classes and do require that PEAR, in particular MDB2 packages be installed. The archive consists of a session class, a user variable class and a database class. The latter, in particular, emulates phplib's db handling class sufficiently well that I generally use it as a drop-in replacement for the phplib class. The class files contain copious notes which (I hope) are adequate to make these classes useful without too much backing and hauling. Get: http://www.fmp.com/downloads/fmplib_classes.tar.gz On Tue, 2008-12-02 at 13:39 +0100, Marko Käning wrote: > Hi phplib users, > > I wonder what you would recommend as an alternative to phplib if I want to > start a completely new project for a web application. > > What I like about phplib is the easy user (data) management allowing every > single use to have his/her own set of variable contents on every new > login. User perms are great to differentiate between users. > > There is PEAR (with tons of different classes), Ajax and whatever... But I > am lost since I did not develop PHP during the past years anymore. > > Wonder what you might suggest as a new technology with future. > > Thanks in advance, > Marko -- 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-12-02 16:41:47
|
I am using a framework called Kohana. It has some pretty nice DB abstraction and it does have support for generating forms, though I do not use that (I am hand coding my HTML using Appcelerator components). It also supports MVC, though it does not force you, and it supports using templates if you want, but again does not force you to. On Tue, Dec 2, 2008 at 7:03 AM, Marko Käning <mk...@mc...> wrote: > I forgot to mention that of course proper support for form generation, > database abstraction etc. is certainly very important. > > ------------------------------------------------------------------------- > 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: Marko K. <mk...@mc...> - 2008-12-02 15:04:11
|
I forgot to mention that of course proper support for form generation, database abstraction etc. is certainly very important. |
From: Marko K. <mk...@mc...> - 2008-12-02 13:12:41
|
Hi phplib users, I wonder what you would recommend as an alternative to phplib if I want to start a completely new project for a web application. What I like about phplib is the easy user (data) management allowing every single use to have his/her own set of variable contents on every new login. User perms are great to differentiate between users. There is PEAR (with tons of different classes), Ajax and whatever... But I am lost since I did not develop PHP during the past years anymore. Wonder what you might suggest as a new technology with future. Thanks in advance, Marko |
From: Frank B. <fb...@sy...> - 2008-09-25 12:37:53
|
Frank Bax wrote: > I just upgraded my OpenBSD server from 4.1 to 4.3 which means (among > other things): > PHP 5.1.6 -> 5.2.5 > PGSQL 8.2.3 -> 8.2.6 > A page with sessions only works fine. But when I try to login a page > with sess4/auth4/perm; I get "Either your username or your password are > invalid". When I check my pgsql logs, I see a couple of "update > sessions" but no queries to my "auth" table. > > Are there any known issues with this upgrade? After a summer of rewriting code (to remove phplib); I upgraded the production server early in Sept. Soon after prod server upgrade I found a little used app that was not tested on test server. Surprisingly (to me) the phplib code on prod server after upgrade to php 5.1 still works for this little app! I have not yet had time to figure out what difference between the two servers caused the problems I encountered on test server in June. |
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 |
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: 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: 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: 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-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: 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: Lindsay H. <fmo...@fm...> - 2008-08-23 15:58:20
|
FWIW, here's the file layout I use for PHP5 sites. It's quite convenient and allows me to incorporate whatever set of libs I want to use, including legacy PHPlib, into a website. I have a couple of dozen websites on the server. My php.ini file specifies an auto_prepend file, /var/www/localhost/prepend/fmp_prepend5.inc which contains the following: <?php set_include_path($_SERVER['DOCUMENT_ROOT'] . "/fmplib" . PATH_SEPARATOR . get_include_path() . PATH_SEPARATOR . "/var/www/localhost/include"); @include_once($_SERVER['DOCUMENT_ROOT'] . "/fmplib/local.inc"); function __autoload($class_name) { (@include_once "class.".$class_name.".inc") || (@include_once "class.".$class_name.".php"); } ?> This does three things. First, it defines a search path which includes a special library directory off of the DocumentRoot for each virtual host (in my case, fmplib/). This path element is followed by a global library directory (in my case /var/www/localhost/include). Second, it auto_includes a "local.inc" file from the virtual host library directory. This is not related to PHPlib's local.inc. It's somewhat the equivalent of PHPlib's $auto_init, but more transparent in operation. This local.inc file can either be PHPlib's prepend.php file, or can include prepend.php in addition to whatever other includes are needed. Third, it defines the PHP5 special __autoload() function so that any attempt to instantiate a class causes PHP to attempt to find and include the proper file containing the class. The only drawback here is that this happens silently, so that not only are any errors in the include operation suppressed, but any errors generated by the included code are also suppressed. For debugging purposes, I generally explicitly include class files in code (sans the "@") which supercedes the __autoload(). PHPlib's prepend.php would be simplified considerably if some thought were given to filenames, and the classes therein were properly allocated so as to take advantage of PHP5's __autoload feature. -- 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-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: 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 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. |