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

Re: [Phplib-users] Re: latest snapshot

[Giancarlo <gia...@na...>]

>   If you allow the session ID to be passed in as a string, then someone can
> hijack a session by simply passing the session ID in the get string.  A
> cookie is much harder to insert, and since they are session cookies, they
> can't easily be viewed or replicated...

the requested url  passes in cleartext, even with SSL, while msg headers 
(cookies) and bodies are encrypted.

Gian

RE: [Phplib-users] Re: latest snapshot

[Rob H. <rob...@ws...>]

I'm not Gian but...

  If you allow the session ID to be passed in as a string, then someone can
hijack a session by simply passing the session ID in the get string.  A
cookie is much harder to insert, and since they are session cookies, they
can't easily be viewed or replicated...

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Richard
> Archer
> Sent: Wednesday, November 06, 2002 5:58 AM
> To: php...@li...
> Subject: Re: [Phplib-users] Re: latest snapshot
>
>
> At 9:13 +0100 5/11/02, Giancarlo wrote:
>
> >One of the things I think everyone really needs is the
> possibility to shift
> >from a less secure get/trans-sid propagation method, to a more secure
> >only_cookies propagation
>
>
> Giancarlo,
>
> Please remind me again... why is passing the session ID in a cookie
> more secure than passing it in a GET string? Is this simply due to
> bugs and illogic in the PHPLIB and/or PHP session ID allocation?
>
>  ...Richard.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

[Phplib-users] Documentation format

[Rob H. <rob...@ws...>]

  What is the source format for the documentation?  I would like to add to
some areas, and I want to make it as easy to integrate as possible...

Thanks,

Rob Hutton
Web Safe
www.wsafe.com

RE: [Phplib-users] two different log-In forms

[Brian P. <bp...@ct...>]

You don't have to unauthorize the user. I'm using PHPLib to authenticate
about 5 different sites on one server. Each has it's own authentication
table and permission scheme. The trick I used was creating a separate
local.inc for each site. Each local.inc uses different session, auth, & perm
classes. Each site also uses it's own database (although it doesn't
necessarily have to). Just take a local.inc file and strip out all the
extraneous stuff. Then include this on each page within the area that needs
to be protected. 

First Site Folder
    local.php
    index.php
    globals.php

Second Site Folder
    local.php
    index.php
    globals.php

(make sure your local.php class declarations don't interfere with the global
local.inc class declarations)

I setup all my pages to include "globals.php" on the first line. Each
globals.php then includes the corresponding local.php file (and any other
necessary include files) and defines any global variables. 

This is really how PHPLib should be setup to work (even though the docs are
somewhat misleading in this regard). It's silly to try and keep all this
stuff in one HUGE local.inc file (which gets parsed by ever single PHP hit).


The only downside to this method is that your password could be compromised
if PHP didn't work for some reason. As long as you have control of your
server, this shouldn't be a problem. If you're concerned about this, put all
your local.php files in a separate folder outside the document root (naming
them uniquely of course). 

bpopp

-----Original Message-----
From: Guenther Theilen [mailto:th...@eq...]
Sent: Wednesday, November 06, 2002 7:57 AM
To: php...@li...
Subject: Re: [Phplib-users] two different log-In forms


Hi Benjamin,

Benjamin Boksa <b....@si...> schrieb:

> Should his authorization for area A be kept, when he enters area B, or
> can he be unauthorized in area A?

He can be unauthorized.

Regards
Guenther


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] two different log-In forms

[Guenther T. <th...@eq...>]

Michael Chaney <mdc...@mi...> schrieb:

> I think the best solution is to separate them into subdomains.

Thanks.
I've solved the problem already with Benjamin's help.
He gave me the hint to patch page.inc:

 *** page.inc.orig
 --- page.inc    
 ***************
 *** 22,28 ****
        if (isset($feature["auth"])) {
          global $auth;

 !       if (!isset($auth)) {
            $auth = new $feature["auth"];
          }
          $auth->start();
 --- 22,28 ----
        if (isset($feature["auth"])) {
          global $auth;

 !       if (!isset($auth) || ($auth->classname != $feature["auth"])) {
            $auth = new $feature["auth"];
          }
          $auth->start();

 and just use a differnt auth in page_open().

Now everything just works fine. :-)

Regards

Guenther



-- 
eqi - Neue Medien                                    http://www.eqi.de
Kampmann & Theilen GbR                           mailto:th...@eq...
Lahnstr. 1                                        Tel: 04931 / 930 971
26506 Norden                                      Fax: 04931 / 930 972

Re: [Phplib-users] two different log-In forms

[Michael C. <mdc...@mi...>]

On Wed, Nov 06, 2002 at 02:28:36PM +0100, Guenther Theilen wrote:
> Hi!
> 
> I want to use the phpLib to make two seperated password-protected areas
> for one site. It's important that the log-in forms look different and
> the two areas are completely seperated. That means, if a user is logged
> in into area A and he clicks on the link to area B, he should be treated
> like a new user.
> 
> I solved the part with the two different log-in forms by adding another
> auth-class extendig auth to the local.inc. But I've got no idea how to
> solve the other problem.
> 
> Any hints?

I think the best solution is to separate them into subdomains.

b.whatever.com
a.whatever.com

That would be the easiest solution.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] two different log-In forms

[Guenther T. <th...@eq...>]

Hi Benjamin,

Benjamin Boksa <b....@si...> schrieb:

> Should his authorization for area A be kept, when he enters area B, or
> can he be unauthorized in area A?

He can be unauthorized.

Regards
Guenther

Re: [Phplib-users] two different log-In forms

[Benjamin B. <b....@si...>]

Hi Guenther!

Should his authorization for area A be kept, when he enters area B, or 
can he be unauthorized in area A?

Regards,

Benne


Am Mittwoch, 06.11.02, um 14:28 Uhr (Europe/Berlin) schrieb Guenther 
Theilen:

> Hi!
>
> I want to use the phpLib to make two seperated password-protected areas
> for one site. It's important that the log-in forms look different and
> the two areas are completely seperated. That means, if a user is logged
> in into area A and he clicks on the link to area B, he should be 
> treated
> like a new user.
>
> I solved the part with the two different log-in forms by adding another
> auth-class extendig auth to the local.inc. But I've got no idea how to
> solve the other problem.
>
> Any hints?
>
> tia.
>
> Sorry for my bad English...
>
> Regards
> Guenther
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>
-- 

Benjamin Boksa
b....@si...

side by site GmbH & Co. KG
Druckgestaltung & Webdesign

Barbarastr. 3-9 (Block 6)
D-50735 Koeln

Fon: +49 221 2790964
Fax: +49 221 2790965

http://www.sidebysite.de/

[Phplib-users] two different log-In forms

[Guenther T. <th...@eq...>]

Hi!

I want to use the phpLib to make two seperated password-protected areas
for one site. It's important that the log-in forms look different and
the two areas are completely seperated. That means, if a user is logged
in into area A and he clicks on the link to area B, he should be treated
like a new user.

I solved the part with the two different log-in forms by adding another
auth-class extendig auth to the local.inc. But I've got no idea how to
solve the other problem.

Any hints?

tia.

Sorry for my bad English...

Regards
Guenther

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@be...>]

On Wed, Nov 06, 2002 at 01:46:20PM +1100, Richard Archer wrote:
> At 18:06 -0600 5/11/02, Joe Stewart wrote:
> 
> >The docs are not updated.  The current docs do not exist in the cvs.
> 
> The user comments aren't there, but the base files are all there
> (as sgml). It's a pita to update the sgml, but well worth keeping
> the docs up to date.
> 

I don't believe this is accurate.  The linuxdoc sgml files that exist in 
cvs are not up to date with the docbook version.  The docbook xml and the 
associated files to output the finished documentation are not in cvs yet.

'make all' only creates the html version is the only problem I saw.

> 
> >You may be able to address two questions:
> >
> >What are the release criteria we are looking for?
> 
> My preference would be for:
> 
> complete back-compatibility with existing applications
> good documentation for the changes outlining possible breakages
> not throwing warnings with all error/warning messages enabled
> compatible with the new PHP defaults wrt globals etc (done?)
> a switch in local.inc to choose phplib-session or session-4
> examples of session-4 classes in local.inc and the html dir
> 

No switch in local.inc, but a separate prepend.php.  

> The main thing I would stress is that this release should not change
> the PHPLIB API in any non-compatible way. API changes may occur in the
> 8.0 release, but should not happen in an incremental release.
> 
> The only area where this may not be possible is in the session-4 stuff,
> but this is OK as long as the old phplib-sessions are still intact and
> back-compatible. Switching on session-4 for an existing app would be
> something the developer would do in a test environment (one hopes!).
> 

So, is this the current state of cvs?

> 
> >Do we need a -devel or -unstable cvs tree?
> 
> There is a devel tree (it's the one that's not stable :). Unfortunately
> this code is quite broken. It is really only useful as a resource for
> ideas (like the session-4 stuff). I would be hesitant to over-write
> this tree with a new suite of changes at this point.
> 
> I would like to see the rest of the good stuff merged from the "phplib"
> tree into the stable tree, and the old "phplib" tree deleted (or
> archived, whatever).
> 
> I think it would be quite a good idea to create a new branch for
> development work. I would like to see it called "unstable" and to
> include a file warning against inclusion of this tree for any
> packaged release of PHPLIB. This would be an attempt at preventing
> a repeat of the inclusion of the broken tree in several OS releases.
> 
>  ...R.

thanks,

Joe


> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Re: latest snapshot

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

At 9:13 +0100 5/11/02, Giancarlo wrote:

>One of the things I think everyone really needs is the possibility to shift
>from a less secure get/trans-sid propagation method, to a more secure
>only_cookies propagation


Giancarlo,

Please remind me again... why is passing the session ID in a cookie
more secure than passing it in a GET string? Is this simply due to
bugs and illogic in the PHPLIB and/or PHP session ID allocation?

 ...Richard.

Re: [Phplib-users] Current PHPLIB development questions

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

At 18:06 -0600 5/11/02, Joe Stewart wrote:

>The docs are not updated.  The current docs do not exist in the cvs.

The user comments aren't there, but the base files are all there
(as sgml). It's a pita to update the sgml, but well worth keeping
the docs up to date.


>You may be able to address two questions:
>
>What are the release criteria we are looking for?

My preference would be for:

complete back-compatibility with existing applications
good documentation for the changes outlining possible breakages
not throwing warnings with all error/warning messages enabled
compatible with the new PHP defaults wrt globals etc (done?)
a switch in local.inc to choose phplib-session or session-4
examples of session-4 classes in local.inc and the html dir

The main thing I would stress is that this release should not change
the PHPLIB API in any non-compatible way. API changes may occur in the
8.0 release, but should not happen in an incremental release.

The only area where this may not be possible is in the session-4 stuff,
but this is OK as long as the old phplib-sessions are still intact and
back-compatible. Switching on session-4 for an existing app would be
something the developer would do in a test environment (one hopes!).


>Do we need a -devel or -unstable cvs tree?

There is a devel tree (it's the one that's not stable :). Unfortunately
this code is quite broken. It is really only useful as a resource for
ideas (like the session-4 stuff). I would be hesitant to over-write
this tree with a new suite of changes at this point.

I would like to see the rest of the good stuff merged from the "phplib"
tree into the stable tree, and the old "phplib" tree deleted (or
archived, whatever).

I think it would be quite a good idea to create a new branch for
development work. I would like to see it called "unstable" and to
include a file warning against inclusion of this tree for any
packaged release of PHPLIB. This would be an attempt at preventing
a repeat of the inclusion of the broken tree in several OS releases.

 ...R.

[Phplib-users] ADV:Website Promotion

[<pet...@ma...>]

*To be removed see below.



Greetings,

I work with a company that submits websites to search engines and saw your listing on the Internet.

We can submit your website to over 300 of the world’s best search engines and directories for a one time fee of $39.95.   If you would like to put your website into the fast lane and receive more Internet traffic.  For more details call our toll-free number (877) 284-8258 and speak with one our representatives.

All work is verified!

Regards,

Peter Murphy

__________________________________________________________________________________

To be removed call toll-free: (888) 529-1703







3383GlPZ4-493rcNT8761Ctlg3-500VEl30

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@be...>]

Hi Richard,

On Wed, Nov 06, 2002 at 10:23:21AM +1100, Richard Archer wrote:
> I'm seeing all this traffic on the list about ongoing development to
> PHPLIB, but I've not seen any commits to the CVS.
> 

I'm sorry.  I thought this had already been covered.

There are two main reasons that the patches haven't been committed to cvs 
( at least by me).

1.  I had not previously done any cvs commits to the phplib project and 
didn't want to come in and start committing willy-nilly.

2.  It's my impression that the state of the current -stable cvs is 
basically frozen waiting for a release.

> I am quite concerned that all these changes are going to be committed
> in one hit with a comment like "merge changes from snapshot".
> 

They are pretty much available as individual patches on sf.net.

> This will give users of PHPLIB no clues as to what changes have been
> made and where to look for breakages in their apps.
> 
> So, two questions:
> 
> 1. where is this development taking place?
> 

sf.net patches.

> 2. are all the changes well documented and are the docs also being updated?
> 

The docs are not updated.  The current docs do not exist in the cvs.

You may be able to address two questions:

What are the release criteria we are looking for?

Do we need a -devel or -unstable cvs tree?

thanks,

Joe


>  ...Richard.
> 

[Phplib-users] Current PHPLIB development questions

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

I'm seeing all this traffic on the list about ongoing development to
PHPLIB, but I've not seen any commits to the CVS.

I am quite concerned that all these changes are going to be committed
in one hit with a comment like "merge changes from snapshot".

This will give users of PHPLIB no clues as to what changes have been
made and where to look for breakages in their apps.

So, two questions:

1. where is this development taking place?

2. are all the changes well documented and are the docs also being updated?

 ...Richard.

[Phplib-users] Request for Comment: phplib db access for jpcache2

[Joe S. <jo...@be...>]

If anyone uses jpcache please take the time to test this patch.  
Especially if you use a database other than mysql.

thanks,

Joe

On Tue, Nov 05, 2002 at 01:58:08PM -0800, no...@so... wrote:
> Patches item #634093, was opened at 2002-11-05 15:58
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=403613&aid=634093&group_id=31885
> 
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 1
> Submitted By: Joe Stewart (joestewart)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: phplib db access for jpcache2
> 
> Initial Comment:
> jpcache2 provides for different storage types to be
> plugged in.  This file - phplib.php interfaces the
> phplib db access methods to jpcache.  This should
> provide db abstraction to jpcache.
> 
> This is an initial test to get feedback.  It has only
> been tested with mysql.
> 
> jpcache can be downloaded at:  http://www.jpcache.com
> 
> ----------------------------------------------------------------------
> 

Re: [Phplib-users] Templates -- lists vs. rows

[Fred Y. <fc...@ac...>]

On Tue, Nov 05, 2002 at 02:53:18PM -0500, Matthew Leingang wrote:
> But what if instead of a list I want this?
> 
> [ <a href="url1">text1</a> | <a href="url2">text2</a> | ... | 
>   <a href="urln">textn</a> ]

I tend to use this idiom when generating separators:

    $sep = '';
    foreach ($links as $url => $text) {
	$template->set_var('SEP', $sep);
	$template->set_var('URL',$url);
	$template->set_var('TEXT',$text);
	$template->parse('links', 'each_link', true); 
	$sep = '|';
    }

where the template looks like this:

      [
      <!-- BEGIN each_link -->
      {SEP} <a href="{URL}">{TEXT}</a>
      <!-- END each_link -->
      ]

-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

Re: [Phplib-users] How to?

[Ron P. <ro...@ne...>]

So I would have to have an additional class extention for each database I
use?

I thought maybe I could have done something like:

$db->database = "newDB";
$db->username="newUser";
$db->password="newPass";

then

$db->query('sql');

Thanks, I just wanted to be sure.

Ron

----- Original Message -----
From: "Layne Weathers" <la...@if...>
To: "'Ron Phillips'" <ro...@ne...>; <Php...@li...>
Sent: Tuesday, November 05, 2002 2:53 PM
Subject: RE: [Phplib-users] How to?


> > How do I utilize multiple databases in the same script?
>
> Make sure you are using separate user/pass for each database, then extend
> DB_Sql for each database and create your objects for each extension class.
>
> Layne Weathers
> Ifworld Inc.
>
>
>
>

[Phplib-users] Templates -- lists vs. rows

[Matthew L. <lei...@ma...>]

Hi,

Say I have an array of link names and URLs that I want to put into an HTML 
page.  If I want a list, it's easy enough.  The template contains

<!-- main.tpl -->
<ul>
<!-- BEGIN each_link -->
<a href="{URL}">{TEXT}</a>
<!-- END each_link -->
</ul>

and the code is 

$template->set_block('main','each_link','EACH_LINK');
foreach ($links as $url => $text) {
  $template->set_var('URL',$url);
  $template->set_var('TEXT',$text);	
  $template->parse('each_link','EACH_LINK',true);
}
$template->parse('main','MAIN');
$template->print('MAIN');

But what if instead of a list I want this?

[ <a href="url1">text1</a> | <a href="url2">text2</a> | ... | 
  <a href="urln">textn</a> ]

There should be a way to write the two templates so that a single snippet
generate both.  The problem is the divider, which comes after each link
but the last.  

How can this be done while keeping all presentation data in the templates 
and all logic in the PHP script?

Any thoughts are appreciated.
--Matt

-- 
----------------------------------------------------------------
Matthew Leingang                http://www.math.rutgers.edu/
Rutgers University              lei...@ma...
Department of Mathematics       "This signature needs no quote."

RE: [Phplib-users] How to?

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

> How do I utilize multiple databases in the same script?

Make sure you are using separate user/pass for each database, then extend
DB_Sql for each database and create your objects for each extension class.

Layne Weathers
Ifworld Inc.

[Phplib-users] How to?

[Ron P. <ro...@ne...>]

How do I utilize multiple databases in the same script?

thanks.

Ron Phillips
Web Development
-------------------------------------------------------
Charleston Newspapers Interactive
http://www.cn-interactive.com

Phone: (304) 348-5167
Email: ro...@cn...

Re: [Phplib-users] Re: latest snapshot

[Giancarlo <gia...@na...>]

Il 13:52, marted=EC 5 novembre 2002, Rob Hutton ha scritto:
> Can't you shift modes now by having two sessions, one with get, one wit=
h
> only cookies, and two auths in local.inc? =20


> BTW, why would you use get in
> the first place unless the browser is not accepting cookies.  If that i=
s
> the case, then you can't use cookies anyway?

with php4 you can force get mode and an id of your own choice by simply=20
opening an url with your-choice sid in it. Must be not a cookie already a=
t=20
your browser.

And php4 doesn't really tell me when this session is a just-new-issued on=
e or=20
a preexistent one. I can nnever be sure when my session is fresh,=20
uninitialized.
If you want to block anything (eg: registration submission) by requiring =
that=20
the client has previously obtained a session from you, you can't.

And with php4 I couldn't obtain to reissue a second  session after a firs=
t=20
one.

If you want to ignore sessions provided in the url that were not previous=
ly=20
issued by yourself, you cant. There can exists sharable sessions, user ca=
n=20
choose his 'unpredictable' session id. Cookie-enableb client, but vergin =
on=20
our cookies, can be forced into accepting any sid from the URL get method=
=2E
I want to open as much as possible the public access, to anyone with or=20
without cookies. But for the authed access I want to have a strictier pol=
icy.


Gian

RE: [Phplib-users] Re: latest snapshot

[Rob H. <rob...@ws...>]

Can't you shift modes now by having two sessions, one with get, one with
only cookies, and two auths in local.inc?  BTW, why would you use get in the
first place unless the browser is not accepting cookies.  If that is the
case, then you can't use cookies anyway?

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Tuesday, November 05, 2002 3:13 AM
> To: Marko Kaening; Joe Stewart
> Cc: phplib-users list
> Subject: Re: [Phplib-users] Re: latest snapshot
>
>
> I particularly like the fact that snapshot is compatible with the
> traditional
> session.inc.
> As we were speaking about credit card etc, I'd like tomention
> that in using
> any authentication, the control over the session propagation
> becomes vital to
> security, and php4 ofeers zero control on that. I am sure that
> session.inc
> could acquire some speed by the builtin serializations for the data
> representation, and the save handlers could be quick, but I'd like a more
> controlled propagation in general.
> One of the things I think everyone really needs is the
> possibility to shift
> from a less secure get/trans-sid propagation method, to a more secure
> only_cookies propagation, reissuing a new session of the latter type and
> migration all the old session values in it. This means that once
> authed you
> get a new session, possibly of the stronger type.
> BEcause the fact that anyone can be driven into 'get' mode and accept any
> users-choice-unpredictable sid...
>
>

Re: [Phplib-users] Re: latest snapshot

[Giancarlo <gia...@na...>]

I particularly like the fact that snapshot is compatible with the traditi=
onal=20
session.inc.
As we were speaking about credit card etc, I'd like tomention that in usi=
ng=20
any authentication, the control over the session propagation becomes vita=
l to=20
security, and php4 ofeers zero control on that. I am sure that session.in=
c=20
could acquire some speed by the builtin serializations for the data=20
representation, and the save handlers could be quick, but I'd like a more=
=20
controlled propagation in general.
One of the things I think everyone really needs is the possibility to shi=
ft=20
=66rom a less secure get/trans-sid propagation method, to a more secure=20
only_cookies propagation, reissuing a new session of the latter type and=20
migration all the old session values in it. This means that once authed y=
ou=20
get a new session, possibly of the stronger type.
BEcause the fact that anyone can be driven into 'get' mode and accept any=
=20
users-choice-unpredictable sid...


Gian

Il 09:55, luned=EC 4 novembre 2002, Marko Kaening ha scritto:
> Hi,
>
> shouldn't we in general use the $_POST, $_GET vars from now on, instead=
 of
> the old $HTTP_* variables? The latter one don't seem to be recommended =
for
> further use and if a new phplib4 is created one should use right away t=
he
> proper superglobals.
>
> Marko
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Re: latest snapshot

[Chris J. <ch...@ch...>]

On Mon, Nov 04, 2002 at 09:55:23AM +0100, Marko Kaening wrote:

> shouldn't we in general use the $_POST, $_GET vars from now on, instead of
> the old $HTTP_* variables? The latter one don't seem to be recommended for
> further use and if a new phplib4 is created one should use right away the
> proper superglobals.

Agreed.  There may be a few people out there still using PHP3, but I
honestly think we need to focus on supporting PHP4.

-- 
    ..chris