phplib-users

[phplib-users] current status of phplib

[aric c. <gre...@gm...>]

I am wondering what the current status of phplib is?

Who's still using it?
If you are, why?  Legacy applications?  Do you use it in new projects?
Is anybody interested in updating it (drop pre php4 or even pre php5
support, add new features, etc)?
If its not going to go anywhere further, what are the other options for
currently supported replacements?  Pear::auth?

I've used phplib for years.  Mainly I am using the authentication features
and I havent found anything else I like better.  But its showing its age.

I've never found the need for a templating system more advanced than
phplib's (so things like smarty just seem rediculous to me) and even then
I'm not sure I see the need for it.

The database abstraction is simple and I've not needed to use anything other
than mysql anyway.  Seems this part of phplib may be all but obsoleted by
things like pdo, so maybe it should be changed to be just an API on top of
pdo, just for compatiblity?

sessions are now handled natively in php..

I've never used the ooforms stuff so I cant comment on that.

I'm not sure phplib makes sense anymore considering things like PEAR, PDO,
etc.

The only thing keeping me using it is the authentication feature with the
perm extensions patch and the groups stuff from phpslash..

I would like to see phplib reworked and modernized around the core feature
of authentication and advanced sessions management.  I am desperately in
need of cross-site authentication functionality, which it looks like it was
discussed but never implemented, and I haven't seen any easy to use
implementations in php.


-- 
---------------------------------
Aric Caley,
Swiftlead Software, inc.

Re: [phplib-users] current status of phplib

[Marko K. <mk...@mc...>]

Hi,

I also use PHPLIB because of its authentication framework.

I also thought about moving to PEAR, because of the easy install/upgrade 
of packages, but couldn't find a comparable replacement of auth.

*************************************************************************
 To implement phplib's authentication as a PEAR package would be a great 
 idea, I guess!!!
*************************************************************************

Actually I do use one PEAR package:

  flmpc21:~> pear list
  Installed packages, channel pear.php.net:
  =========================================
  Package              Version State
  ...
  HTML_Template_PHPLIB 1.3.1   stable
  ...

;)

Bjoern Schotte implemented phplib's template system into PEAR a while ago.

This templating is in my opinion fulfilling everything you want from a 
template system.

Regards,
Marko

Re: [phplib-users] current status of phplib

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

>I am wondering what the current status of phplib is?

Obviously I can only speak for myself.

I do have write access to the PHPLib repository, but I have not=20
had discussions with other project devs or admins about=20
development plans. I haven't seen anything from the PHPLib=20
project admins in about 2 years, but Richard Archer (who is a=20
project dev and may be able to publish new releases) has written=20
recently. It doesn't look like there's much of a future plan,=20
and development is either dead or in a persistent vegitative=20
state. On the other hand, the core functionality is stable and=20
works, so there is not as much need for development as there was=20
7 years ago when I started using/improving PHPLib.


>Who's still using it?
>If you are, why?  Legacy applications?  Do you use it in new projects?
>Is anybody interested in updating it (drop pre php4 or even pre php5
>support, add new features, etc)?
>If its not going to go anywhere further, what are the other options for
>currently supported replacements?  Pear::auth?

I currently have one major PHPLib app in production that I built=20
and continue to maintain (4+ years old). There may be other=20
PHPLib apps I've written still in production, but I can't be=20
sure of that.

A few years ago I made several changes to my local copies of=20
PHPLib - I think I committed most of them back into the PHPLib=20
repository, but haven't checked recently. (One example -=20
PHPLib's Oracle OCI8 DB layer was completely broken.)

=46or now, though, I am developing most new apps in Rails - I=20
don't like Ruby's current performance, but I don't feel that the=20
PHP clones of Rails have much to offer. Neither Ruby nor Rails=20
are perfect or trouble-free, but they have a large active=20
community and a framework that does much of what I need without=20
getting in the way.

PEAR findings can be useful for some pieces of functionality,=20
but when you have to configure (and/or manually bind) all of=20
your core framework pieces to work together you might as well=20
switch to Java where such time-wasting nonsense is deemed "enterprise".


>I've used phplib for years.  Mainly I am using the authentication features
>and I havent found anything else I like better.  But its showing its age.

I like (and use exclusively) the CRC auth variation that 1)=20
keeps passwords hashed in the DB and 2) prevents eavesdroppers=20
from catching the password hash in transit.


>I've never found the need for a templating system more advanced than
>phplib's (so things like smarty just seem rediculous to me) and even then
>I'm not sure I see the need for it.

I've recently used small bits of smarty functionality (I came in=20
on an existing project that used it) and like it. Rather than=20
trying to strictly keep PHP and HTML in separate files, I think=20
the more important priority is keeping the display logic=20
separate from the business and data logic.


>The database abstraction is simple and I've not needed to use anything oth=
er
>than mysql anyway.  Seems this part of phplib may be all but obsoleted by
>things like pdo, so maybe it should be changed to be just an API on top of
>pdo, just for compatiblity?

Last I checked (years ago), PHPLib's db class was faster than=20
the alternatives. Merging it with pdo would probably decrease=20
that speed. Of course, the database performance will usually be=20
a much larger factor than the abstraction layer.


>sessions are now handled natively in php..

But for anything that needs to scale across multiple servers (or=20
whenever you want to limit your slow disk I/O), you'll switch to=20
storing sessions either in the DB or in memcached - might as=20
well start out with them there. The difference between using a=20
custom DB save handler for PHP's native sessions and using=20
PHPLib's sessions is greater flexibility with PHPLib. Having the=20
user sessions persisting across all of a user's logins or an=20
app-wide "session" holding infrequently-updated variables is=20
handy and easy to do with PHPLib.

I have no interest in using slow, insecure disk-based sessions.


>I would like to see phplib reworked and modernized around the core feature
>of authentication and advanced sessions management.

That's not a bad goal. Maybe you can convince a project admin to=20
hand over the reins.

PHPLib was based on a good goal of being an integrated=20
application framework. Many apps need a more extensive=20
framework, but deciding what should be included is tricky.=20
Having seen newer frameworks, I don't think I'll build another=20
big (or critical) app in a framework that doesn't support easy,=20
robust automated tests.


>I am desperately in need of cross-site authentication functionality,
>which it looks like it was discussed but never implemented, and I
>haven't seen any easy to use implementations in php.

There are different levels of cross-site authentication that=20
have been discussed on this list from running multiple sites on=20
the same servers to sharing logins with a site under another=20
organization's control. I've implemented cross-site=20
authentication for sites hosted on the same servers a couple=20
times myself - it is trivial to build with auth_preauth(),=20
passing authentication tokens (stored temporarily in the DB) via=20
a hidden iframe or riding as parameters on a transparent gif request.

--=20

Layne Weathers

Re: [phplib-users] current status of phplib

[aric c. <gre...@gm...>]

On 7/19/07, Layne Weathers <la...@dr...> wrote:
>
> >I am wondering what the current status of phplib is?
>
> Obviously I can only speak for myself.
>
> I do have write access to the PHPLib repository, but I have not
> had discussions with other project devs or admins about
> development plans. I haven't seen anything from the PHPLib
> project admins in about 2 years, but Richard Archer (who is a
> project dev and may be able to publish new releases) has written
> recently. It doesn't look like there's much of a future plan,
> and development is either dead or in a persistent vegitative
> state. On the other hand, the core functionality is stable and
> works, so there is not as much need for development as there was
> 7 years ago when I started using/improving PHPLib.
>
>
> >Who's still using it?
> >If you are, why?  Legacy applications?  Do you use it in new projects?
> >Is anybody interested in updating it (drop pre php4 or even pre php5
> >support, add new features, etc)?
> >If its not going to go anywhere further, what are the other options for
> >currently supported replacements?  Pear::auth?
>
> I currently have one major PHPLib app in production that I built
> and continue to maintain (4+ years old). There may be other
> PHPLib apps I've written still in production, but I can't be
> sure of that.


Yeah I've got a  similarly aged major project using phplib auth and
templates/db (actually the template and db classes are derived from phplib,
and not directly from it: they are used in a commercial RAD tool called
CodeCharge studio).  I've been looking into alternates to replace phplib and
into frameworks to replace the RAD tool.

A few years ago I made several changes to my local copies of
> PHPLib - I think I committed most of them back into the PHPLib
> repository, but haven't checked recently. (One example -
> PHPLib's Oracle OCI8 DB layer was completely broken.)
>
> For now, though, I am developing most new apps in Rails - I
> don't like Ruby's current performance, but I don't feel that the
> PHP clones of Rails have much to offer. Neither Ruby nor Rails
> are perfect or trouble-free, but they have a large active
> community and a framework that does much of what I need without
> getting in the way.
>
> PEAR findings can be useful for some pieces of functionality,
> but when you have to configure (and/or manually bind) all of
> your core framework pieces to work together you might as well
> switch to Java where such time-wasting nonsense is deemed "enterprise".


I've got mixed feelings about PEAR, too.  A great idea in theory but I've
found it to be a bit of a PITA to use.   And it doesn't look like the auth
package in there does what phplib's does.

>I've used phplib for years.  Mainly I am using the authentication features
> >and I havent found anything else I like better.  But its showing its age.
>
> I like (and use exclusively) the CRC auth variation that 1)
> keeps passwords hashed in the DB and 2) prevents eavesdroppers
> from catching the password hash in transit.


It always seemed sensible to me which is why I've used it.  But after
googling on the subject it seems that even this is not as secure as you
might think, it only obscures things a bit better.  It should still be
combined with SSL.  This
link<http://www.ietf.org/internet-drafts/draft-newman-auth-scram-04.txt>sounds
pretty similar to what phplib does.  I think I am by no means an
expert on these things, but phplib's auth seems much closer to secure (by
far) than any other php authentication I've seen -- unless I am missing
something.

>I've never found the need for a templating system more advanced than
> >phplib's (so things like smarty just seem rediculous to me) and even then
> >I'm not sure I see the need for it.
>
> I've recently used small bits of smarty functionality (I came in
> on an existing project that used it) and like it. Rather than
> trying to strictly keep PHP and HTML in separate files, I think
> the more important priority is keeping the display logic
> separate from the business and data logic.


Yes, and that can be done by proper programing discipline.  Personally I
dont feel that I need to be forced to keep them separate by a system that
makes things more complicated.  Now, the template system is great if you're
going to, say, let a user of your application create and upload templates to
be used by your application, in which case you dont want them to be able to
access *anything* internal to your app.  Unfortunately to my knowledge PHP
doesn't have any kind of real sandboxing feature that would let you run php
code in a walled off area where you have to explicitly enable language
features.  that would be great...

>The database abstraction is simple and I've not needed to use anything
> other
> >than mysql anyway.  Seems this part of phplib may be all but obsoleted by
> >things like pdo, so maybe it should be changed to be just an API on top
> of
> >pdo, just for compatiblity?
>
> Last I checked (years ago), PHPLib's db class was faster than
> the alternatives. Merging it with pdo would probably decrease
> that speed. Of course, the database performance will usually be
> a much larger factor than the abstraction layer.


I think at this point the minor trade off in overhead might be worthwhile...

>sessions are now handled natively in php..
>
> But for anything that needs to scale across multiple servers (or
> whenever you want to limit your slow disk I/O), you'll switch to
> storing sessions either in the DB or in memcached - might as
> well start out with them there. The difference between using a
> custom DB save handler for PHP's native sessions and using
> PHPLib's sessions is greater flexibility with PHPLib. Having the
> user sessions persisting across all of a user's logins or an
> app-wide "session" holding infrequently-updated variables is
> handy and easy to do with PHPLib.
>
> I have no interest in using slow, insecure disk-based sessions.


Excellent point.  I assume that phplib may be the only option for this
flexibility... do you think it would be possible to make phplib use php's
native sessions and extend them to be as flexible as the phplib-only
sessions?

>I would like to see phplib reworked and modernized around the core feature
> >of authentication and advanced sessions management.
>
> That's not a bad goal. Maybe you can convince a project admin to
> hand over the reins.
>
> PHPLib was based on a good goal of being an integrated
> application framework. Many apps need a more extensive
> framework, but deciding what should be included is tricky.
> Having seen newer frameworks, I don't think I'll build another
> big (or critical) app in a framework that doesn't support easy,
> robust automated tests.
>
>
> >I am desperately in need of cross-site authentication functionality,
> >which it looks like it was discussed but never implemented, and I
> >haven't seen any easy to use implementations in php.
>
> There are different levels of cross-site authentication that
> have been discussed on this list from running multiple sites on
> the same servers to sharing logins with a site under another
> organization's control. I've implemented cross-site
> authentication for sites hosted on the same servers a couple
> times myself - it is trivial to build with auth_preauth(),
> passing authentication tokens (stored temporarily in the DB) via
> a hidden iframe or riding as parameters on a transparent gif request.


it seems like an easy enough concept but I have had trouble getting it to
work..

--
>
> Layne Weathers
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phplib-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>



-- 
---------------------------------
Aric Caley,
Swiftlead Software, inc.

Re: [phplib-users] current status of phplib

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

>It always seemed sensible to me which is why I've used it.  But after
>googling on the subject it seems that even this is not as secure as
>you might think, it only obscures things a bit better.  It should
>still be combined with SSL.  This link
><http://www.ietf.org/internet-drafts/draft-newman-auth-scram-04.txt>
>sounds pretty similar to what phplib does.  I think I am by no means
>an expert on these things, but phplib's auth seems much closer to
>secure (by far) than any other php authentication I've seen -- unless
>I am missing something.

Thanks for the link. CRC gives a nice security benefit for very=20
little effort, but it's not a panacea.

I am baffled when I see people implementing HTTP auth for their=20
web app (or not protecting themselves from SQL injection).



>>>I am desperately in need of cross-site authentication functionality,
>>>which it looks like it was discussed but never implemented, and I
>>>haven't seen any easy to use implementations in php.
>>
>>There are different levels of cross-site authentication that
>>have been discussed on this list from running multiple sites on
>>the same servers to sharing logins with a site under another
>>organization's control. I've implemented cross-site
>>authentication for sites hosted on the same servers a couple
>>times myself - it is trivial to build with auth_preauth(),
>>passing authentication tokens (stored temporarily in the DB) via
>>a hidden iframe or riding as parameters on a transparent gif request.
>
>it seems like an easy enough concept but I have had trouble getting it to
>work..

Why don't you start a new thread with the details - at least a=20
couple of us can take a look.

--=20

Layne Weathers

Re: [phplib-users] current status of phplib

[Richard A. <rh...@ju...>]

At 10:08 AM -0700 19/7/07, aric caley wrote:

>I do have write access to the PHPLib repository, but I have not
>had discussions with other project devs or admins about
>development plans. I haven't seen anything from the PHPLib
>project admins in about 2 years, but Richard Archer (who is a
>project dev and may be able to publish new releases) has written
>recently.

I rolled in a few security patches and pushed a release
some time ago. I do monitor the SF trackers for patches
but they are few and far between these days. I don't
think many people are writing new apps using PHPLib these
days.

Personally I use the template and db on every job I do.
I don't often use session or auth and when I do I am often
left wondering if the complexity is worth while.


Several of the PHPLib developers are using Drupal for their
new projects. I had a good bash at using Drupal, but for my
specific requirements Drupal development moved too fast,
leaving my apps orphaned long before their expected EOL.


>It always seemed sensible to me which is why I've used it.  But after
>googling on the subject it seems that even this is not as secure as
>you might think, it only obscures things a bit better.  It should
>still be combined with SSL.

I did quite a bit of work on PHPLib's crcloginform.ihtml.
With it, the password does not pass over the network and
replay attacks are impossible. It does require Javascript
on the client browser (but falls back gracefully).

SSL is far superior if you can justify the expense.


>Excellent point.  I assume that phplib may be the only option for this
>flexibility... do you think it would be possible to make phplib use
>php's native sessions and extend them to be as flexible as the
>phplib-only sessions?

session4.inc is intended to offer all PHPLib's functionality
with PHP4-style sessions.


>>I would like to see phplib reworked and modernized around the core feature
>>of authentication and advanced sessions management.
>
>That's not a bad goal. Maybe you can convince a project admin to
>hand over the reins.

I'm happy to look at proposals.

I'm a big fan of backwards compatibility and a stable API.
But that doesn't mean the code can't be improved under the hood
or that new features can't be implemented.

 ...R.