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.