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

Re: [Phplib-users] Template (was: extensions to oohforms, table)

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

At 7:27 AM +1000 21/4/04, Richard Archer wrote:

>Last time I checked the only difference between the two template libs
>was a couple of dubious bug fixes in the pear lib.

I have just compared the pear and phplib template classes. The
differences amount to:

pear has "fallback" directories where it searches for templates.
pear has reverted to str_replace instead of preg_replace.
phplib has clear_var and unset_var.
pear has a couple of extra bugs and missing features.

So, for me the phplib class is the clear winner.

Although reverting to str_replace might be worthwhile for the phplib
class as it results in cleaner code and a 25% speed increase. I wonder
if it would break any existing applications due to the differences in
the way data is stored in varkeys[].

 ...R.

Re: [Phplib-users] extensions to oohforms, table

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

At 1:35 PM -0700 20/4/04, Aric Caley wrote:

>I guess the pear::template_phplib has some improvements we could back-port.

Last time I checked the only difference between the two template libs
was a couple of dubious bug fixes in the pear lib.

I have a couple of user-sumitted enhancements to template which I will
be merging and committing sometime soon, so I'll do another comparison
between the phplib and pear template classes while I'm at it.

 ...R.

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Matt Williams wrote:

> Yes I agree Aric there does seem to be a lot of stuff missing that 
> PHPLib has.
>
> I think this probably is to do with the maturity of PHPLib over 
> pear::auth. I can't help feeling though that there may be a lot of 
> dead wood so to speak lurking around in the lib now. More or less all 
> of the session stuff seems to now be redundant, and there seems to be 
> little development currently happening with PHPLIb.
>
I'm sure there's lots of "cruft" that could/should be gone over.  
Obviously the session stuff is pretty much useless, except where you 
would want to put sessions into a database (php defaults to using files 
I believe) or you already use phplib.  So, we should keep the sessions 
merely as a compatibility layer, and as a *"session_set_save_handler()" 
*extension.

I dont know if you are familiar with phpslash, but they've made some 
nice extensions to the phplib auth/perm which ought to be integrated 
back into phplib (and they are some of the same people too).  There's 
also some other nice things there I think should be part of phplib, like 
a way of handling class files and being able to overide them, which is cool.

I guess the pear::template_phplib has some improvements we could back-port.

Anybody else listening?

> Any thoughts anyone?
>
> Matt

Re: [Phplib-users] extensions to oohforms, table

[Matt W. <li...@ye...>]

Aric Caley wrote:

> I looked at pear::auth, but it doesn't look nearly as good as PHPLib's 
> auth.  Does it have the challenge-response mechanism where the password 
> is never transmitted plain-text?  Does it have the ability to register a 
> user?  Or is it at least easy and documented on how to do these things?  
> I could be wrong I didnt look at it that thoroughly but I dont think it 
> does.
> 
> The jury is still out on what to do...

Yes I agree Aric there does seem to be a lot of stuff missing that 
PHPLib has.

I think this probably is to do with the maturity of PHPLib over 
pear::auth. I can't help feeling though that there may be a lot of dead 
wood so to speak lurking around in the lib now. More or less all of the 
session stuff seems to now be redundant, and there seems to be little 
development currently happening with PHPLIb.

Any thoughts anyone?

Matt

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Matt Williams wrote:

>There is already an auth class within PEAR.
>
>I set up a test machine last week using PEAR::Auth, PEAR::DB, native sessions,
>although I customised it to use DB storage. I'm gonna bring in PHPLib perm as I
>haven't seen anything in PEAR that will do the same thing.
>I'm in two minds whether to bring in PHPLib's DB extraction or not and use that
>for my stuff or whether to use PEAR::DB, although there are some neat error
>handlers for PEAR::DB.
>
>Matt
>  
>
I looked at pear::auth, but it doesn't look nearly as good as PHPLib's 
auth.  Does it have the challenge-response mechanism where the password 
is never transmitted plain-text?  Does it have the ability to register a 
user?  Or is it at least easy and documented on how to do these things?  
I could be wrong I didnt look at it that thoroughly but I dont think it 
does.

The jury is still out on what to do...

>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>
>
>  
>

Re: [Phplib-users] extensions to oohforms, table

[Matt W. <li...@ye...>]

Quoting Aric Caley <gre...@pe...>:

> There are assorted types of template classes including a PHPLib one.  I 
> have no desire for a template engine more complex than PHPLib's and in 
> fact I'm of the mind to do things without a template engine at all.
> 
> The main thing that seems to be missing from PEAR is something 
> equivalent to PHPLib's auth and perm classes. 

There is already an auth class within PEAR.

I set up a test machine last week using PEAR::Auth, PEAR::DB, native sessions,
although I customised it to use DB storage. I'm gonna bring in PHPLib perm as I
haven't seen anything in PEAR that will do the same thing.
I'm in two minds whether to bring in PHPLib's DB extraction or not and use that
for my stuff or whether to use PEAR::DB, although there are some neat error
handlers for PEAR::DB.

Matt

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Clark Freifeld wrote:

>Hi Phplibbers,
>
>Way back in 1999, Eric Ries and I made some extensions to the oohforms
>component of phplib, version 6.4 to be precise. These included some
>fancier validation techniques and some fancier widgets, including a few
>types of database-backed widgets. I have just recently re-integrated these
>changes into PHPLib version 7.4, and I was wondering if anybody would be
>interested in taking a look at them. The code is definitely not at release
>level, but there are some nifty features.
>
>Anyway, if people are interested, I'll throw together a little Web page
>with the files and some documentation on how to drop them in on top of
>your PHPLib installation and how to use them.
>
>I also have made some enhancements to the table class, namely, integrating
>it with the DB class and providing sorting via clicking on column
>header links and more formatting flexibility. Would love to share that
>too.
>  
>
I would be interested to see what you've done.

I was looking at the PEAR classes trying to decide if there's a purpose 
for PHPLib anymore.  They have HTML_QuickForm which looks like a very 
advanced version of oohforms.  Naturaly, its much bigger, and has 
probably a lot more functionality.  I'm torn between which one I want to 
use. 

PEAR also has their own DB abstractions.  From what I've read, PHPLib DB 
class is much faster and I can't really think of all that much more 
feature wise I would want.  For me, PHPLib wins here.

There are assorted types of template classes including a PHPLib one.  I 
have no desire for a template engine more complex than PHPLib's and in 
fact I'm of the mind to do things without a template engine at all.

The main thing that seems to be missing from PEAR is something 
equivalent to PHPLib's auth and perm classes. 

I dont know if its worth working on the oohforms or not.  I'm all for it 
if somebody with experience with PEAR could give some good reasons why 
the PEAR version isn't so great, and how oohforms could have certain 
advantages over it (like speed and efficiency and simplicity).

I always like to stick with what already works and improve upon it, but 
always at some point its worth moving on.  Either we can rustle up some 
interest in PHPLib improvements, or perhaps its time to port PHPLib's 
auth, perm and lean DB functionality to PEAR?

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Layne Weathers wrote:

> Nathaniel,
>
>I don't know if re-writing PHPLib is "worthwhile" to anyone else - one of
>the beauties of OSS is that everyone is allowed to define what is worthwhile
>for them. I have been using PHPLib for a few years now and have kept using
>it precisely for the interaction of the classes.
>
>(BTW, what is the correct capitalization - PHPLIB, PHPlib, PHPLib, etc?)
>
>I would love to start working on a fresh release of PHPLib. It would be a
>bit of an undertaking and will probably take a good while to complete, but
>I'd love to get rid of the cruft.
>
>It seems to me that some possible goals could/should be:
>- define some basic coding and formatting guidelines
>    (preferably, this would be set by the project admin or other designated
>    decision-maker so we don't waste time arguing about it)
>- completely audit/rewrite the existing code
>- only commit classes that have been tested by more than one person
>    (e.g., how many current users/developers have used db_msql.inc?)
>- require a minimum of (at least) PHP 4.1 - heck, this is going to take a
>    while, why not build on PHP 5? (semi-serious)
>
>Anyone else willing to consider taking on the challenge?
>
>Layne Weathers
>
>  
>
I've been using PHPLib since I started with PHP some years ago.  I like 
it.  I haven't found anything else that seems to be as simple and 
lightweight yet powerfull enough to be generaly usefull.

I'd like to see PHPLib updated, in addition to what's listed above:
  * MySQLi support (this is the 'improved' mysql extension in php5.  
Anybody know how to get it to play nice with the old mysql extension on 
windows? ).
  * SQLite support
  * PHP5 only.  Yes, that's right.  Why not?  Take full advantage of 
PHP5 new object oriented features.  I'm exploring some ideas now with 
the db and template objects.
  * Permx built in.
  * Better documentation.  I remember having a tough time with phplib at 
first...

Re: [Phplib-users] extensions to oohforms, table

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

Quoth Nathaniel Price:

> This is a bit off of the topic, but one of the main reasons I like=20
> PHPlib is because its components work together well. However, when=20
> looking around at other code libraries like PEAR and ADOdb that are=20
> actively maintained, and seeing PHPlib mostly still using code designed=
=20
> to work with PHP3, I'm beginning to wonder if it might be worth=20
> migrating to get a more fully featured database abstraction layer.=20
> However, I wouldn't want to sacrifice the flexability that the=20
> auth/perm/user functionality offers. Does anyone have any thoughts as to=
=20
> what code out there to "replace" phplib? Would it be worthwhile to try=20
> to rewrite PHPlib to get rid of crufty code and add new features, or=20
> would that be duplicating efforts from other projects too much to be=20
> worth it?

Nathaniel,

I don't know if re-writing PHPLib is "worthwhile" to anyone else - one of
the beauties of OSS is that everyone is allowed to define what is worthwhil=
e
for them. I have been using PHPLib for a few years now and have kept using
it precisely for the interaction of the classes.

(BTW, what is the correct capitalization - PHPLIB, PHPlib, PHPLib, etc?)

I would love to start working on a fresh release of PHPLib. It would be a
bit of an undertaking and will probably take a good while to complete, but
I'd love to get rid of the cruft.

It seems to me that some possible goals could/should be:
- define some basic coding and formatting guidelines
    (preferably, this would be set by the project admin or other designated
    decision-maker so we don't waste time arguing about it)
- completely audit/rewrite the existing code
- only commit classes that have been tested by more than one person
    (e.g., how many current users/developers have used db_msql.inc?)
- require a minimum of (at least) PHP 4.1 - heck, this is going to take a
    while, why not build on PHP 5? (semi-serious)

Anyone else willing to consider taking on the challenge?

Layne Weathers

Re: [Phplib-users] random logouts

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

> As for the cookie end of things, make sure that the browsers are 
> accepting the cookie (sniffing the HTTP headers can be useful here), and=
=20
> make sure that the cookie is being set for the same domain/hostname that=
=20
> it is originating from. If you have a situaiton where you want sessions=
=20
> to span multiple hosts/domains/subdomains, that will likely cause=20
> problems as well, which you'd have to work around.

Many of the users were using the IP address (from when we moved servers,
before DNS switched), but all of the links and redirects are fully qualifie=
d
with the domain name.

> Oh, and just in case... make /absolutely/ sure that each page that uses=
=20
> sessions and/or auth is closed with page_close(). The lack of this=20
> function call at the end of your scripts is often the cause of=20
> random-looking dropped sessions.

It's embarrassing to see that I've overlooked that randomly throughout the
site. Thanks for the reminders.

Layne Weathers

Re: [Phplib-users] random logouts

[Nathaniel P. <np...@te...>]

On 4/13/2004 7:50 PM, Layne Weathers wrote :

>[snip]
>
>I have users occasionally losing their session and/or auth and getting the
>login screen. From the bug reports, this happens immediately after login
>about 20-30% of the time. The rest of the time it appears to be random, but
>usually when clicking on a link (as opposed to submitting a form and/or
>being redirected).
>
>[snip]
>
>Has anyone seen this kind of behaviour before?
>  
>
Although I can't be sure without more information, it sounds to me like 
it is an issue with cookies or session/auth lifetimes. If you are using 
the included Challenge-Response auth subclass for example, it has a 
default auth lifetime of only 1 minute, last time I checked.

As for the cookie end of things, make sure that the browsers are 
accepting the cookie (sniffing the HTTP headers can be useful here), and 
make sure that the cookie is being set for the same domain/hostname that 
it is originating from. If you have a situaiton where you want sessions 
to span multiple hosts/domains/subdomains, that will likely cause 
problems as well, which you'd have to work around.

Oh, and just in case... make /absolutely/ sure that each page that uses 
sessions and/or auth is closed with page_close(). The lack of this 
function call at the end of your scripts is often the cause of 
random-looking dropped sessions.

Hope this helps...

-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

[Phplib-users] random logouts

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

The setup:
    Oracle 9i
    Apache 1.3.29
    PHP 4.3.4
    PHPLib latest CVS
        db_oci8.inc
        ct_sql.inc (with customized queries for Oracle for speed & clob
type)
        session.inc
            cookie-based, no fallback mode
        auth.inc

I have users occasionally losing their session and/or auth and getting the
login screen. From the bug reports, this happens immediately after login
about 20-30% of the time. The rest of the time it appears to be random, but
usually when clicking on a link (as opposed to submitting a form and/or
being redirected).

I was using CT_Split_Sql, but was getting occasional primary key violations=
,
so I switched to CT_Sql with modified queries (no changes to the logic) and
the primary key violations stopped, but the dropped session/auth still
continues. I'm logging both PHP warnings (level 15) and SQL errors and am
not seeing any correlations with sessions or auth - whatever is happening i=
s
not throwing a SQL error or a PHP warning or error.

Has anyone seen this kind of behaviour before?

Layne Weathers

R: [Phplib-users] extensions to oohforms, table

[Gaetano G. <giu...@se...>]

I've been using PHPlib for a while now, mainly on a single (big) project =
at my company.
Since I had already deployed my own DB abstraction layer, based on phpDB =
code, I retro-fitted phplib to use it.
As a testament to code modularity and good design, I must say it was =
pretty painless.

Since then I tried porting the db code to ADODB.

I like this library because it is well supported (too much in fact, 1 =
release every month or so!) and widely deployed and because the API is =
quite similar to what I used before.
I do not like this library because it tends to be buggy and have =
regressions all the time, even after years of development (and every =
time I post a patch to the author we dissent on design issues ;)...

What I would like to have now is a good framework of modules that =
cooperate together, e.g.
- smarty for templating
- adodb for db access
- phplib for extending the native php session with user/auth/perm
- xmlrpc for inter-application communication (shameless self-promotion: =
I'm writing an extension to adodb to access remote databases thru =
xml-rpc using the phpxmlrpc lib...)

This would imho avoid a lot of duplication of effort and be a solid base =
for higher-level frameworks, such as CMS frameworks.

I must confess never using the 'templating' part of phplib (I was not =
into teplates at the time), so I cannot testity for Smarty against =
phplib, I just downloaded the templating engine with the biggest =
marketshare.

I also never upgraded to the latest version of phplib mostly because:
- never ever fully understood if the lib was 100% ok with =
register_globals off
- never ever fully understood if the lib was 100% fine with php4 =
sessions and which were the good files to use in that case

Cheers
Gaetano

> -----Messaggio originale-----
> Da: php...@li...
> [mailto:php...@li...]Per conto di=20
> Nathaniel
> Price
> Inviato: lunedi 12 aprile 2004 18:30
> A: php...@li...
> Oggetto: Re: [Phplib-users] extensions to oohforms, table
>=20
>=20
> On 4/9/2004 3:18 PM, Clark Freifeld wrote :
>=20
> >Hi Phplibbers,
> >
> >Way back in 1999, Eric Ries and I made some extensions to=20
> the oohforms
> >component of phplib, version 6.4 to be precise. These included some
> >fancier validation techniques and some fancier widgets,=20
> including a few
> >types of database-backed widgets. I have just recently=20
> re-integrated these
> >changes into PHPLib version 7.4, and I was wondering if=20
> anybody would be
> >interested in taking a look at them. The code is definitely=20
> not at release
> >level, but there are some nifty features.
> >
> >Anyway, if people are interested, I'll throw together a=20
> little Web page
> >with the files and some documentation on how to drop them in=20
> on top of
> >your PHPLib installation and how to use them.
> >
> >I also have made some enhancements to the table class,=20
> namely, integrating
> >it with the DB class and providing sorting via clicking on column
> >header links and more formatting flexibility. Would love to=20
> share that
> >too.
> >
> >Keep up the good work on PHPLib. I've been a loyal user for=20
> five years
> >now.
> > =20
> >
> I'd be very interested to see what you've come up with...=20
> I've worked on=20
> my own extension to oohforms that I'm using in-house for a=20
> few things,=20
> but it was mostly just a code cleanup with a couple of new=20
> features more=20
> than anything else.
>=20
> I haven't mucked around with the table class very much, but the=20
> functionality you've described sounds like it would be a very useful=20
> addition.
>=20
> PHPlib development seems to be pretty much stagnant as of=20
> late. I'm glad=20
> to see someone working on it.
>=20
> This is a bit off of the topic, but one of the main reasons I like=20
> PHPlib is because its components work together well. However, when=20
> looking around at other code libraries like PEAR and ADOdb that are=20
> actively maintained, and seeing PHPlib mostly still using=20
> code designed=20
> to work with PHP3, I'm beginning to wonder if it might be worth=20
> migrating to get a more fully featured database abstraction layer.=20
> However, I wouldn't want to sacrifice the flexability that the=20
> auth/perm/user functionality offers. Does anyone have any=20
> thoughts as to=20
> what code out there to "replace" phplib? Would it be=20
> worthwhile to try=20
> to rewrite PHPlib to get rid of crufty code and add new features, or=20
> would that be duplicating efforts from other projects too much to be=20
> worth it?
>=20
> Thanks in advance...
>=20
> --=20
> ___________________________
> Nathaniel Price
> http://www.tesserportal.net
> Webmaster
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] extensions to oohforms, table

[Nathaniel P. <np...@te...>]

On 4/9/2004 3:18 PM, Clark Freifeld wrote :

>Hi Phplibbers,
>
>Way back in 1999, Eric Ries and I made some extensions to the oohforms
>component of phplib, version 6.4 to be precise. These included some
>fancier validation techniques and some fancier widgets, including a few
>types of database-backed widgets. I have just recently re-integrated these
>changes into PHPLib version 7.4, and I was wondering if anybody would be
>interested in taking a look at them. The code is definitely not at release
>level, but there are some nifty features.
>
>Anyway, if people are interested, I'll throw together a little Web page
>with the files and some documentation on how to drop them in on top of
>your PHPLib installation and how to use them.
>
>I also have made some enhancements to the table class, namely, integrating
>it with the DB class and providing sorting via clicking on column
>header links and more formatting flexibility. Would love to share that
>too.
>
>Keep up the good work on PHPLib. I've been a loyal user for five years
>now.
>  
>
I'd be very interested to see what you've come up with... I've worked on 
my own extension to oohforms that I'm using in-house for a few things, 
but it was mostly just a code cleanup with a couple of new features more 
than anything else.

I haven't mucked around with the table class very much, but the 
functionality you've described sounds like it would be a very useful 
addition.

PHPlib development seems to be pretty much stagnant as of late. I'm glad 
to see someone working on it.

This is a bit off of the topic, but one of the main reasons I like 
PHPlib is because its components work together well. However, when 
looking around at other code libraries like PEAR and ADOdb that are 
actively maintained, and seeing PHPlib mostly still using code designed 
to work with PHP3, I'm beginning to wonder if it might be worth 
migrating to get a more fully featured database abstraction layer. 
However, I wouldn't want to sacrifice the flexability that the 
auth/perm/user functionality offers. Does anyone have any thoughts as to 
what code out there to "replace" phplib? Would it be worthwhile to try 
to rewrite PHPlib to get rid of crufty code and add new features, or 
would that be duplicating efforts from other projects too much to be 
worth it?

Thanks in advance...

-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

[Phplib-users] extensions to oohforms, table

[Clark F. <cl...@th...>]

Hi Phplibbers,

Way back in 1999, Eric Ries and I made some extensions to the oohforms
component of phplib, version 6.4 to be precise. These included some
fancier validation techniques and some fancier widgets, including a few
types of database-backed widgets. I have just recently re-integrated these
changes into PHPLib version 7.4, and I was wondering if anybody would be
interested in taking a look at them. The code is definitely not at release
level, but there are some nifty features.

Anyway, if people are interested, I'll throw together a little Web page
with the files and some documentation on how to drop them in on top of
your PHPLib installation and how to use them.

I also have made some enhancements to the table class, namely, integrating
it with the DB class and providing sorting via clicking on column
header links and more formatting flexibility. Would love to share that
too.

Keep up the good work on PHPLib. I've been a loyal user for five years
now.

Clark

Re: [Phplib-users] Use phplib session in cgi scripts

[Peter C. <li...@cr...>]

Another thought - don't know if it's relevant (are you using Perl CGI?), but
 I have worked on a project where the Perl programmer used
 Apache::Session::PHP to get at the PHP authorisation info and session data
 (didnt try changing any session data though). Saves reinventing the wheel
 and is transparent to PHP.

Peter

R: [Phplib-users] Use phplib session in cgi scripts

[Gaetano G. <giu...@se...>]

You can extend or modify the session class, possibly in conjunction with =
the user (auth?) and storage container class, to extend data saved along =
with the session.

I have e.g. the client IP and user name (if auth is used) saved beside =
the session name and ID and the serialized session data, so it's easy to =
whip up a query to see how many clients are logged in and since when:

1 - created a stored proc to do the insert of session data in an =
extended table: I like it better than putting plain table-acccess SQL in =
PHP

2 - created a new CT_sql class, with a modified ac_store function
    + in that function used global var $REMOTE_ADDR as extra parameter =
for the stored proc,
    + and added some optional fourth parameter (user id) to the call =
signature

3 - created a new user class that would call this->that->ac_store =
passing along the user ID


Hope this helps

gaetano
> -----Messaggio originale-----
> Da: php...@li...
> [mailto:php...@li...]Per conto di Jan
> Inviato: lunedi 16 febbraio 2004 7:57
> A: php...@li...
> Oggetto: [Phplib-users] Use phplib session in cgi scripts
>=20
>=20
> Hi All,
>=20
> yes, it's a strange topic but it's really a problem:
>=20
> I have a webserver, which displays mrtg cgi sites.
> As we're migrating our internal portal site to a new auth system with=20
> phplib, we have the problem to integrate these cgi sites.
> The first idea was to work with the user and the session id from the=20
> database, but in the database is no direct connection between=20
> a userid=20
> and a session.
>=20
> Has anyone ever thought about this or knows a possible=20
> solution for this?
>=20
> Thanks in advance and have a nice weekend
>=20
> Jan
>=20
> (Hell knows why my exchange thinks this list isn't valid. So=20
> I'm using a=20
> new account.)
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] Use phplib session in cgi scripts

[Jan <jaa...@ne...>]

Hi All,

yes, it's a strange topic but it's really a problem:

I have a webserver, which displays mrtg cgi sites.
As we're migrating our internal portal site to a new auth system with 
phplib, we have the problem to integrate these cgi sites.
The first idea was to work with the user and the session id from the 
database, but in the database is no direct connection between a userid 
and a session.

Has anyone ever thought about this or knows a possible solution for this?

Thanks in advance and have a nice weekend

Jan

(Hell knows why my exchange thinks this list isn't valid. So I'm using a 
new account.)

RE: [Phplib-users] num_rows in db_oracle.inc

[<Jan...@be...>]

> -----Original Message-----
> From: Jan...@be... [mailto:Jan...@be...]
> Sent: Friday, February 06, 2004 11:08 AM
>
> Hi All,
> 
> it took me a while to figure out that my knowledge about SQL 
> was not totally
> nonsense, but the num_rows function seems to be not working properly.

Sorry, forget it.
I used db_oci8.inc instead of db_oracle.inc, which produced the error.
db_oracle.inc works fine.

Sorry for disturbing you.

Regards

Jan

Re: [Phplib-users] num_rows in db_oracle.inc

[Gerry P. <g.w...@ab...>]

>it took me a while to figure out that my knowledge about SQL was not totally
>nonsense, but the num_rows function seems to be not working properly.
>
>When I'm using this statement:
>
>SELECT ALL * FROM auth_group_md5 WHERE groupname like '%ll%'
>(ALL is optional)
>
>and trying to receive the affected rows with
>
>$db->query($query)
>echo $db->num_rows();
>
>I'm always reveiving a "0". By using the SQL statement under sqlplus I'm
>getting one result (which is the expected one).
>
>My question:
>Is this a known problem? I've seen that there is a bug description, but I
>don't think that it should be affected by my statement.
>By the way: I'm using 7.4 of phplib.

If I recall correctly this only works for some databases - I had a problem with
Oracle but somebody else said mysql was ok.  If you use Oracle then a possible
solution is to use select count(*)... in a second query.

Gerry

[Phplib-users] num_rows in db_oracle.inc

[<Jan...@be...>]

Hi All,

it took me a while to figure out that my knowledge about SQL was not =
totally
nonsense, but the num_rows function seems to be not working properly.

When I'm using this statement:

SELECT ALL * FROM auth_group_md5 WHERE groupname like '%ll%'
(ALL is optional)

and trying to receive the affected rows with

$db->query($query)
echo $db->num_rows();

I'm always reveiving a "0". By using the SQL statement under sqlplus =
I'm
getting one result (which is the expected one).

My question:
Is this a known problem? I've seen that there is a bug description, but =
I
don't think that it should be affected by my statement.
By the way: I'm using 7.4 of phplib.

Thanks in advance.

Kind regards

Jan Albrecht
System Administration / NMI-DC / Global 24
------------------------------------------
arvato systems GmbH
An der Autobahn 18
D-33311 G=FCtersloh
http://www.arvato-systems.de

jan...@be...
Tel.: +49 (0) 5241/80-88404
Fax.: +49 (0) 5241/80-688404
Mobil: +49 (0) 172/2978914

[Phplib-users] Problem with Test without cookies

[Heino E. <he...@lu...>]

when I switch off "Allow Cookies" in my Browser (Firebird 0.7) I cant 
see any SessionID in the URL and the example with the increasing value 
on index.php3 isn`t working too.
I cant even login!
But I followed every step of the "Quick Installation Guide".

my Host:
PHP Version 4.3.3, phplib-7.4, Apache/1.3.29, Debian Linux 2.4.23

Any Ideas, what could be misconfigured @ my host??
Everything works after doing the "Testing of the PHPLib Installation", 
but only when I got "Cookies enabled" in my browser!

Thx.
Heino

RE: [Phplib-users] phpLIB 7.4 PRE2 just stopped processing logins

[Corbin B. S. <csi...@1n...>]

I ended up recompiling and re-installing PHP 4.3.4, and the problem went
away.  Everything is functional once again.

Interesting note:  The client browser was not getting cookies from the
server.  However, one of the other virtual sites (not phplib) was
sending out cookies properly.  I doubt anything in phpLIB was the cause,
rather it must have been something in PHP.

Corbin

-----Original Message-----
From: Nathaniel Price [mailto:np...@te...]=20
Sent: Monday, January 12, 2004 4:05 PM
To: Corbin B. Siddall
Cc: php...@li...
Subject: Re: [Phplib-users] phpLIB 7.4 PRE2 just stopped processing
logins

Ach! I must have missed the original email... My previous email assumed=20
that *nothing* was working and I see that that's not actually the case.=20
The steps I outlined in my email may still be useful, but I'm not sure=20
that would be the best way to approach the problem.

I would agree with Layne Weathers (who posted elsewhere in this thread),

that session problems seem to be the root of the problem. Since you are=20
using the MD5 challenge_crypt authentication, sessions have to be=20
working perfectly to allow anyone to login.

If you're using the PHP4-sessions (i.e. the actual session data is=20
handled by PHP4, and PHPlib just wraps itself around PHP4's session=20
handling with local4.inc and session4.inc), I'd check to make sure that=20
sessions are enabled and working properly in PHP4. Check the PHP=20
documentation on sessions for more info:
http://www.php.net/manual/en/ref.session.php

Also (this applies to both PHP3 and PHP4), check to make sure that=20
cookies are in fact being passed around as they should. You can check=20
this by enabling cookie notification on your browser, or by looking at=20
the HTTP headers that your browser sends to make sure it's sending the=20
cookie that PHPlib sets. If you use fallback_mode, make sure your=20
scripts add the session id to any links/urls with $sess->purl() or=20
something. Documentation:
http://www.sanisoft.com/phplib/manual/sessionMethods.php

If there's any proxy server in between you and your server, make sure=20
that it isn't interfering with cookies or anything.

Hope this helps! Sorry about the earlier post.



On 1/12/2004 1:41 PM, Nathaniel Price wrote :

> On 1/12/2004 1:07 PM, Corbin B. Siddall wrote :
>
>> [snip]
>> 4. All pages do indeed have a proper open_page() that references the
>> appropriate extended class as well as ending close_page() tags.
>> =20
>>
> Unless you've changed it, the syntax should be page_open() and=20
> page_close(). However, if you say that it has been running without any

> changes at all for 11 months, that would mean one of two things:
> --page.inc or page4.inc was changed to have open_page() and=20
> close_page() functions wrap around the real functions, or the names of

> the functions themselves were changed, and somehow, your page(4).inc=20
> got reverted to the default. If page_open() isn't executed, your=20
> PHPlib-dependent scripts won't work at all.
> --You mistyped the function names in your email and the problem is=20
> something else. In that case, forget what I just said.
>
> In any case, since it sounds like PHPlib is not working at all, the=20
> best way to go about finding the problem would be to do the following:
> --If you've set PHP's error reporting so that it doesn't report=20
> errors, or reports fewer than the default, set it back to report E_ALL

> errors. (Remember to set it back when you're finished)
> --Make sure that prepend.php (or prepend.php3) is being included on=20
> all of your PHPlib-dependent scripts. If you use the auto_prepend_file

> php setting to include it, make sure that PHP is, in fact, doing that.

> If not, make sure that your include_path is set up to point to your=20
> phplib installation. The phpinfo() function is very useful in checking

> for this sort of thing.
> --Make sure that your local4.inc (or local.inc) configuration is set=20
> up correctly, and that your prepend.php (or prepend.php3) file is=20
> including the right set of classes for your installation.
> --Make sure that page_open() and page_close() are being executed on=20
> these pages. Make sure that the functions aren't being overridden by=20
> some other included php file that has a function of the same name=20
> within it.
> --Make sure that the class files (the *.inc files) themselves haven't=20
> been modified, or that any modifications are expected and desired (and

> bug-free, of course).
>
> Hate to say this, but generally things don't just "stop working".=20
> Something must have changed--I would go over things with a=20
> fine-toothed comb to find out what. If you have backups of your phplib

> installation, I'd look over those to see if there are differences with

> what you have currently.
>
> Hope this helps... Let us know if you find out anything more.
>
> ___________________________
> Nathaniel Price
> http://www.tesserportal.net
> Webmaster
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>


--=20
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

Re: [Phplib-users] phpLIB 7.4 PRE2 just stopped processing logins

[Nathaniel P. <np...@te...>]

Ach! I must have missed the original email... My previous email assumed 
that *nothing* was working and I see that that's not actually the case. 
The steps I outlined in my email may still be useful, but I'm not sure 
that would be the best way to approach the problem.

I would agree with Layne Weathers (who posted elsewhere in this thread), 
that session problems seem to be the root of the problem. Since you are 
using the MD5 challenge_crypt authentication, sessions have to be 
working perfectly to allow anyone to login.

If you're using the PHP4-sessions (i.e. the actual session data is 
handled by PHP4, and PHPlib just wraps itself around PHP4's session 
handling with local4.inc and session4.inc), I'd check to make sure that 
sessions are enabled and working properly in PHP4. Check the PHP 
documentation on sessions for more info:
http://www.php.net/manual/en/ref.session.php

Also (this applies to both PHP3 and PHP4), check to make sure that 
cookies are in fact being passed around as they should. You can check 
this by enabling cookie notification on your browser, or by looking at 
the HTTP headers that your browser sends to make sure it's sending the 
cookie that PHPlib sets. If you use fallback_mode, make sure your 
scripts add the session id to any links/urls with $sess->purl() or 
something. Documentation:
http://www.sanisoft.com/phplib/manual/sessionMethods.php

If there's any proxy server in between you and your server, make sure 
that it isn't interfering with cookies or anything.

Hope this helps! Sorry about the earlier post.



On 1/12/2004 1:41 PM, Nathaniel Price wrote :

> On 1/12/2004 1:07 PM, Corbin B. Siddall wrote :
>
>> [snip]
>> 4. All pages do indeed have a proper open_page() that references the
>> appropriate extended class as well as ending close_page() tags.
>>  
>>
> Unless you've changed it, the syntax should be page_open() and 
> page_close(). However, if you say that it has been running without any 
> changes at all for 11 months, that would mean one of two things:
> --page.inc or page4.inc was changed to have open_page() and 
> close_page() functions wrap around the real functions, or the names of 
> the functions themselves were changed, and somehow, your page(4).inc 
> got reverted to the default. If page_open() isn't executed, your 
> PHPlib-dependent scripts won't work at all.
> --You mistyped the function names in your email and the problem is 
> something else. In that case, forget what I just said.
>
> In any case, since it sounds like PHPlib is not working at all, the 
> best way to go about finding the problem would be to do the following:
> --If you've set PHP's error reporting so that it doesn't report 
> errors, or reports fewer than the default, set it back to report E_ALL 
> errors. (Remember to set it back when you're finished)
> --Make sure that prepend.php (or prepend.php3) is being included on 
> all of your PHPlib-dependent scripts. If you use the auto_prepend_file 
> php setting to include it, make sure that PHP is, in fact, doing that. 
> If not, make sure that your include_path is set up to point to your 
> phplib installation. The phpinfo() function is very useful in checking 
> for this sort of thing.
> --Make sure that your local4.inc (or local.inc) configuration is set 
> up correctly, and that your prepend.php (or prepend.php3) file is 
> including the right set of classes for your installation.
> --Make sure that page_open() and page_close() are being executed on 
> these pages. Make sure that the functions aren't being overridden by 
> some other included php file that has a function of the same name 
> within it.
> --Make sure that the class files (the *.inc files) themselves haven't 
> been modified, or that any modifications are expected and desired (and 
> bug-free, of course).
>
> Hate to say this, but generally things don't just "stop working". 
> Something must have changed--I would go over things with a 
> fine-toothed comb to find out what. If you have backups of your phplib 
> installation, I'd look over those to see if there are differences with 
> what you have currently.
>
> Hope this helps... Let us know if you find out anything more.
>
> ___________________________
> Nathaniel Price
> http://www.tesserportal.net
> Webmaster
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>


-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

Re: [Phplib-users] phpLIB 7.4 PRE2 just stopped processing logins

[Nathaniel P. <np...@te...>]

On 1/12/2004 1:07 PM, Corbin B. Siddall wrote :

>[snip]
>4. All pages do indeed have a proper open_page() that references the
>appropriate extended class as well as ending close_page() tags.
>  
>
Unless you've changed it, the syntax should be page_open() and 
page_close(). However, if you say that it has been running without any 
changes at all for 11 months, that would mean one of two things:
--page.inc or page4.inc was changed to have open_page() and close_page() 
functions wrap around the real functions, or the names of the functions 
themselves were changed, and somehow, your page(4).inc got reverted to 
the default. If page_open() isn't executed, your PHPlib-dependent 
scripts won't work at all.
--You mistyped the function names in your email and the problem is 
something else. In that case, forget what I just said.

In any case, since it sounds like PHPlib is not working at all, the best 
way to go about finding the problem would be to do the following:
--If you've set PHP's error reporting so that it doesn't report errors, 
or reports fewer than the default, set it back to report E_ALL errors. 
(Remember to set it back when you're finished)
--Make sure that prepend.php (or prepend.php3) is being included on all 
of your PHPlib-dependent scripts. If you use the auto_prepend_file php 
setting to include it, make sure that PHP is, in fact, doing that. If 
not, make sure that your include_path is set up to point to your phplib 
installation. The phpinfo() function is very useful in checking for this 
sort of thing.
--Make sure that your local4.inc (or local.inc) configuration is set up 
correctly, and that your prepend.php (or prepend.php3) file is including 
the right set of classes for your installation.
--Make sure that page_open() and page_close() are being executed on 
these pages. Make sure that the functions aren't being overridden by 
some other included php file that has a function of the same name within 
it.
--Make sure that the class files (the *.inc files) themselves haven't 
been modified, or that any modifications are expected and desired (and 
bug-free, of course).

Hate to say this, but generally things don't just "stop working". 
Something must have changed--I would go over things with a fine-toothed 
comb to find out what. If you have backups of your phplib installation, 
I'd look over those to see if there are differences with what you have 
currently.

Hope this helps... Let us know if you find out anything more.

___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster