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

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.

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

[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...>]

>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

[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

[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] delivering static content with phplib

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

>Not to be confused with my other email; this one deals with a=20
>webpage that is entirely static, but I've used php to simply=20
>the html coding.  There is a lot of repetitious html in the=20
>page, so I used php arrays to make sure it all gets generated=20
>cleanly/consistently.  Is there a phplib feature, or some other=20
>php functions that I can use to give browser the timestamp of=20
>the php so the browser can think the page is static instead of=20
>dynamic?  This way, when I change the page, timestamp changes=20
>and browser should cache page until I make a change.

You can set the last modified header. Here is the group of=20
headers I've used in the past to make downloaded files "static".=20
If you have this code in an include, you'll need to change the=20
target of filemtime() to point to the page file.

header("Expires: " . gmdate("D, d M Y H:i:s", time() + 1440 *=20
60) . " GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s",=20
filemtime(__FILE__)) . " GMT");
header("Cache-Control: public");
header("Cache-Control: max-age=3D" . 1440 * 60, false);
header("Pragma: public");

--=20

Layne Weathers

[phplib-users] delivering static content with phplib

[Frank B. <fb...@sy...>]

Not to be confused with my other email; this one deals with a webpage that 
is entirely static, but I've used php to simply the html coding.  There is 
a lot of repetitious html in the page, so I used php arrays to make sure it 
all gets generated cleanly/consistently.  Is there a phplib feature, or 
some other php functions that I can use to give browser the timestamp of 
the php so the browser can think the page is static instead of 
dynamic?  This way, when I change the page, timestamp changes and browser 
should cache page until I make a change.

Another use of this would be with truly dynamic pages where database can 
tell us when the data last changed.  It would be nice if I could somehow 
send 'last-change' timestamp to browser and allow it to do some caching 
until the 'last-change' changes.

Frank 

[phplib-users] OT: caching static content

[Frank B. <fb...@sy...>]

I've got some php pages with more static than dynamic content.  Is there a 
way to send this to the client's browser as two files so that the browser 
can cache the static portion of the page?  A simple example would be static 
header/menu in one file; dynamic content; then static footer content.  I 
know I can simply use php include() function to send the static header with 
every request, but then the browser only sees one large dynamic page.  I'd 
like the browser to know that the header and content are separate so that 
it can cache header part of the page.  Using frames is the only idea I 
could come up with (with static and dynamic content in separate frames), 
but frames just won't work in this project.

Frank

Re: [phplib-users] phplib and PHP5?

[Frank B. <fb...@sy...>]

At 08:18 AM 2/20/07, Marko Kaening wrote:
>is it possible to run the phplib-framework under PHP5? Up to now I am
>running PHP 4.3.10, but soon I would have to upgrade my Linux distro and
>that would bring PHP5 into play, I am afraid. That is why I have to think
>about future compatibility issues with phplib...


         https://lists.sourceforge.net/lists/listinfo/phplib-users
In PHP5 "register_long_arrays" is OFF by default - it was ON in 
PHP4.  Layne has fixed phplib in CVS; or you can make changes yourself 
based on messages in Archives Jan-2007.

[phplib-users] phplib and PHP5?

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

Hi phplib-users,

is it possible to run the phplib-framework under PHP5? Up to now I am 
running PHP 4.3.10, but soon I would have to upgrade my Linux distro and 
that would bring PHP5 into play, I am afraid. That is why I have to think 
about future compatibility issues with phplib...

Any hints?

Regards,
Marko

Re: [phplib-users] Problem with loginform.ihtml inclusion passing from PH4 to PHP5

[Frank B. <fb...@sy...>]

At 04:10 AM 1/30/07, Davide Strepparava wrote:
>   function auth_validatelogin() {
>     global $username, $password;
>
>     if(isset($username)) {
>       $this->auth["uname"]=$username;        ## This provides access for
>"loginform.ihtml"
>     }
>
>     $uid = false;
>
>     $this->db->query(sprintf("select user_id, perms ".
>                              "        from %s ".
>                              "       where username = '%s' ".
>                              "         and password = '%s'",
>                           $this->database_table,
>                           addslashes($username),
>                           addslashes($password)));



The above code does not appear to be part of 7.4 (as you claim).  On my system:

         global $username, $password;
changed to:
         global $HTTP_POST_VARS;
and
         addslashes($username),
         addslashes($password)));
changed to:
         addslashes($HTTP_POST_VARS["username"]),
         addslashes($HTTP_POST_VARS["password"])));


This code was recently changed again in CVS (using $_POST instead of 
$HTTP_POST_VARS).

You should probably audit all your local files that are supposed to be 
based on library code, to see if updates have been applied.  It certainly 
looks like at least some of your code predates 7.4 release.

Frank  

Re: [phplib-users] Problem with loginform.ihtml inclusion passing from PH4 to PHP5

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

Davide,

I would enable PHP's error logging and see what problems are being
encountered. It could be that some included or required files can't
be found without a specified path.

--=20

Layne Weathers

[phplib-users] Problem with loginform.ihtml inclusion passing from PH4 to PHP5

[Davide S. <dav...@qp...>]

Hi all,
I am a newbie with phplib and I must port an old software that use them 
from PHP4 to PHP5.
Unfortunately I don't realize to do it.

This is the old system where the software runs correctly:
OS: Debian Woody 3.0
PHP version: 4.1.2-4
Apache version:  1.3.26
MySQL server version: 3.23.49-8
PHPLib version: 7.4

Before on this system there was an old PHPlib version, but copying 
logger.inc and language.inc in phplib
directory I realize to use PHPLib 7.4 with no problem (I have no errors 
in Apache's error.log).

Instead this is the new system where the software does not run correctly:
OS: OpenSuSE 10.2
PHP version: 5.2.0
Apache version:  2.2.3
MySQL server version: 5.0.26
PHPLib version: 7.4

On this system when I go to DocumentRoot's index.php, the browser give 
me nothing as output.
After some test I noted that when local.inc is loaded by prepend.inc the 
function auth_loginform that includes loginform.ihtml
is not executed. In this way I can't access the login form. I am sure 
the local.inc has been executed.
auth_loginforn belongs to Control_Auth class, an extension of Auth, this 
class is defined in the DocumentRoot's local.inc,
I report it below:

class Control_Auth extends Auth {
  var $classname      = "Control_Auth";

  var $lifetime       =  120; // two hours
  var $refresh        =    1; // validate perms every 10 minutes

  var $database_class = "DB_Control";
  var $database_table = "auth_user";
 
  function auth_loginform() {            #Function that has been 
executed with the old system
    global $sess;                        #but not with the new.
   
    include("loginform.ihtml");        
  }
 
  function auth_validatelogin() {
    global $username, $password;
   
    if(isset($username)) {
      $this->auth["uname"]=$username;        ## This provides access for 
"loginform.ihtml"
    }
   
   
    $uid = false;
   
    $this->db->query(sprintf("select user_id, perms ".
                             "        from %s ".
                             "       where username = '%s' ".
                             "         and password = '%s'",
                          $this->database_table,
                          addslashes($username),
                          addslashes($password)));

    while($this->db->next_record()) {
      $uid = $this->db->f("user_id");
      $this->auth["perm"] = $this->db->f("perms");
    }

    if ($uid) {
      $this->db->query(sprintf("update %s set lastlog=now() WHERE 
user_id='%s'",
        $this->database_table,
        addslashes($uid)));
      $log = new Control_Logger;
      $log->message(sprintf("User %s logged in.", $username), $username);
    }
   
    return $uid;
  }

  function auth_refreshlogin() {
    $uid = false;
   
    //print "3: I am in auth_refreshlogin<br>";
   
    $this->db->query(sprintf("select user_id, perms ".
                             "        from %s ".
                             "       where user_id = '%s' ",
                             $this->database_table,
                             addslashes($this->auth["uid"])));

    while($this->db->next_record()) {
      $uid = $this->db->f("user_id");
      $this->auth["perm"] = $this->db->f("perms");
    }

    return $uid;
  }
}


In the old system all works fine also with the newest version of PHPlib, 
so I don't think the problem is due to PHPlib.
Have you any ideas, please?

Kind regards and thank you for the attention,
Davide Strepparava

Re: [phplib-users] loginform.ihtml

[Frank B. <fb...@sy...>]

At 11:04 PM 1/13/07, Frank Bax wrote:
>I must have been a bit bored, because I ran W3C html validation on the
>login page.
>
>         - The </table> tag immediately before </body> is redundant.
>         - The javascript tag should include type="text/javascript"
>         - The javascript code should be between <head> and </head>.
>         - Should have a <!DOCTYPE> tag as first line (I used 4.01 
> Transitional).
>         - Should have a <meta> tag for character set (I used utf-8).


Sorry, the 3rd item is incorrect - the javascript code is "broken" when 
placed between "head" tags.  The </body> tag that precedes the code should 
be after the code. 

Re: [phplib-users] register_long_arrays

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

At 9:49 AM -0600 15/1/07, Layne Weathers wrote:

>The latest change I made still works pre-4.1 - I tested the new
>method with a vanilla 4.0.6 install. There may be other changes that
>don't work pre-4.1 - I haven't tested a complete PHPLib stack
>against old versions.

Yes, I realised after that last post that this was the case.
Very clever :)

 ...R.

Re: [phplib-users] register_long_arrays

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

>Perhaps this calls for some enhancements to the documentation
>such that it is explicitly stated that PHP 4.1 is required.
>
>Prior to this change I think we required PHP 3.0.9 or somesuch.

Richard,

The latest change I made still works pre-4.1 - I tested the new
method with a vanilla 4.0.6 install. There may be other changes that
don't work pre-4.1 - I haven't tested a complete PHPLib stack
against old versions.

--=20

Layne Weathers

Re: [phplib-users] register_long_arrays

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

At 3:50 PM -0600 12/1/07, Layne Weathers wrote:

>>Are there any plans to release an update that supports:
>>   register_long_arrays = Off

Perhaps this calls for some enhancements to the documentation
such that it is explicitly stated that PHP 4.1 is required.

Prior to this change I think we required PHP 3.0.9 or somesuch.

 ...R.

[phplib-users] loginform.ihtml

[Frank B. <fb...@sy...>]

I must have been a bit bored, because I ran W3C html validation on the 
login page.

	- The </table> tag immediately before </body> is redundant.
	- The javascript tag should include type="text/javascript"
	- The javascript code should be between <head> and </head>.
	- Should have a <!DOCTYPE> tag as first line (I used 4.01 Transitional).
	- Should have a <meta> tag for character set (I used utf-8).

Frank 

Re: [phplib-users] register_long_arrays

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

>I noticed that in a few places, you used code like:
>
>   if (!isset($_POST)) {
>     global $HTTP_POST_VARS, $HTTP_POST_FILES;
>     $_POST  =3D $HTTP_POST_VARS;
>     $_FILES =3D $HTTP_POST_FILES;
>   }
>
>I don't have an old system for testing this, but can we assume
>that all arrays are always defined?  Is it possible that
>reference to $HTTP_POST_FILES could trigger warning?=20

I really don't have a good idea of who's using PHPLib these days -
its probably ridiculous to think that anyone using a PHP version
less than 4.1 will use the latest CVS release of PHPLib, but I was
wanting to not break backwards compatibility without warning.

Because the references to the long arrays will only be reached if
the auto-globals aren't set, I don't think it should trigger any
warnings for you. I could be wrong - please let me know if it does
and I'll go ahead and break the backwards compatibility.

--=20

Layne Weathers

Re: [phplib-users] register_long_arrays

[Frank B. <fb...@sy...>]

At 08:26 AM 1/2/07, Layne Weathers wrote:

> >That being said, handling this seems like an easy multi-file find
> >and replace. You could even do it from the command line (untested,
> >but should be correct if in the PHPLib directory):
>
>
>I forgot the old long arrays weren't super globals, so you'd need to
>handle that as well. If I have time in the near future I'll try to
>at least commit changes to CVS.


The link to CVS on this page is broken:
         http://phplib.sourceforge.net/


I noticed that in a few places, you used code like:

   if (!isset($_POST)) {
     global $HTTP_POST_VARS, $HTTP_POST_FILES;
     $_POST  = $HTTP_POST_VARS;
     $_FILES = $HTTP_POST_FILES;
   }

I don't have an old system for testing this, but can we assume that all 
arrays are always defined?  Is it possible that reference to 
$HTTP_POST_FILES could trigger warning? 

Re: [phplib-users] register_long_arrays

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

>Are there any plans to release an update that supports:
>   register_long_arrays =3D Off
>This is the default setting on my php5 host.

=46rank,

I've committed changes to the php-lib-stable CVS repository. The
updated files are:
  pages/defauth.php3
  pages/admin/new_user.php3
  pages/admin/new_user_alt.php3
  pages/admin/new_user_md5.php3
  php/auth.inc
  php/auth4.inc
  php/crcloginform.ihtml
  php/crloginform.ihtml
  php/layout_html.inc
  php/local.inc
  php/local4.inc
  php/loginform.ihtml
  php/menu.inc
  php/oohforms.inc
  php/session.inc
  php/session4.inc
  php/setup.inc
  php/tpl_form.inc

--=20

Layne Weathers

Re: [phplib-users] register_long_arrays

[Frank B. <fb...@sy...>]

At 08:23 AM 1/2/07, Layne Weathers wrote:

> >Are there any plans to release an update that supports:
> >   register_long_arrays = Off
> >This is the default setting on my php5 host.
>
>find . -type f -name "*.php" -exec perl -pi -e 's/HTTP_(\w+)_VARS/_\1/g' {} \;
>
>find . -type f -name "*.inc" -exec perl -pi -e 's/HTTP_(\w+)_VARS/_\1/g' {} \;


Also *.ihtml 

Re: [phplib-users] register_long_arrays

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

>That being said, handling this seems like an easy multi-file find
>and replace. You could even do it from the command line (untested,
>but should be correct if in the PHPLib directory):


I forgot the old long arrays weren't super globals, so you'd need to
handle that as well. If I have time in the near future I'll try to
at least commit changes to CVS.

--=20

Layne Weathers

Re: [phplib-users] register_long_arrays

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

>Are there any plans to release an update that supports:
>   register_long_arrays =3D Off
>This is the default setting on my php5 host.


As far as I know, there isn't a release that is officially
guaranteed to run under PHP 5, but I could be wrong. I'm not sure
how many people might want support for the older PHP versions
without the short forms, but I'm guessing that's not a significant
issue.

That being said, handling this seems like an easy multi-file find
and replace. You could even do it from the command line (untested,
but should be correct if in the PHPLib directory):

find . -type f -name "*.php" -exec perl -pi -e
's/HTTP_(\w+)_VARS/_\1/g' {} \;

find . -type f -name "*.inc" -exec perl -pi -e
's/HTTP_(\w+)_VARS/_\1/g' {} \;

--=20

Layne Weathers