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

Re: [Phplib-users] Basic authentication

[Peter K. <su...@si...>]

Hello Chris,
here some ideas on your problems:

> 1) Get the user name in the combined web server log.  (I use apache, and
> have not had any luck with other methods.)  This is lower priority.

I do not understand the phrase "... in the combined server log" ?

> "single signon" capability -- that is, they logged in at the other site, and
> the URL needs to contain the information that they logged in with.  As you
> know, the standard URL form is something like:
> 
> [protocol]://[username]:[password]@host.domain.name:[port]/document_path

I never ever would send passwords in an URL - very good opportunity for hackers!

My plan (not realized yet!) to provide a single-sign-on:

On server A there is a user database.
On another server B the user U calls a page first time.
B recognizes, that U isn't logged in and redirects the URL to a log on page at A. The URL must 
contain information that this request comes from B.
U logs on.
A opens a session with phplib and redirects the URL back to B including the session-id.
B uses a tool like XML/RPC to establish a connection to A and reading the user information 
required. Instead of XML/RPC you may force A to write a file with the necessary user information 
and B can do a simple fopen.

Further actions depend on your demands: If you do not use session variables, all is perfect.

Every page on B can check if the user is still logged in at A. Or you have a phplib at B also to check 
that.

This is a raw outline. In fact you have to do some more customizing. E.g. the server A must not give 
access to the user-files mentioned from other servers than B ...

Sounds complicated, I know. But its very secure (I hope so at least ;-))

Peter Kursawe

www.learn4use.com

Re: [Phplib-users] Basic authentication

[Lindsay H. <fm...@fm...>]

Thus spake Chris Johnson on Thu, Jan 31, 2002 at 09:38:30PM CST
> 
> 2)  Provide a method for users linking in from another site to have a
> "single signon" capability -- that is, they logged in at the other site, and
> the URL needs to contain the information that they logged in with.  As you
> know, the standard URL form is something like:
> 
>  [protocol]://[username]:[password]@host.domain.name:[port]/document_path

There are only some protocols (called "schemes" in RFCs) which support
this format, I believe.  AFAIK HTTP isn't one of them.  An HTTP request in
this format will simply drop the "@" symbol and everything in front of it.

See RFC2616, which says...

3.2.2 http URL

     The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and semantics for
http URLs. 

     http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

Re: [Phplib-users] Basic authentication

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

Well, I read that bit of the documentation so long ago, that I'd completely
forgotten all those points.

What I'm really trying to accomplish is 2 things:

1) Get the user name in the combined web server log.  (I use apache, and
have not had any luck with other methods.)  This is lower priority.

2)  Provide a method for users linking in from another site to have a
"single signon" capability -- that is, they logged in at the other site, and
the URL needs to contain the information that they logged in with.  As you
know, the standard URL form is something like:

 [protocol]://[username]:[password]@host.domain.name:[port]/document_path

So, uh, the username/password portion seemed like an obvious place to put
that information, and HTTP Basic Authentication would work with minimal
work.

But having re-read the Auth section of the PHPLIB docs, there are a couple
of drawbacks I don't think I want to live with:

1)  No "log out" -- well, it could be kludged by forcing a login to a
different realm, but that would be crude.

2)  No expire.  These users are accessing private data, so I'd better be
sure that people can't just wander by and use their PC's while they are out
of the office, etc.

3)  Not per page.  Not too much of a problem, since all of my Perm levels
are per directory at the moment, but could be a nuisance in the future.

So, I'm open to suggestions on how to solve my 2 problems at the top instead
of hacking Basic Auth into PHPLIB.  Any ideas?

Thanks,
..chris

----- Original Message -----
From: "Tarique Sani <ta...@sa...>" <ro...@sa...>


On Wed, 30 Jan 2002, Chris Johnson wrote:

> Has anybody modified PHPLIB to use HTTP basic authentication (i.e.
"realms")
> instead of the default standalone login page stuff?

Err ... If you read the manual you must have noted that in-line
authentication of PHPlib was written the over come the short commings of
Basic HTTP authentication

Care to explain why you want to turn the wheel back?

Tarique

--
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com
The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

Re: [Phplib-users] Basic authentication

[nathan r. h. <dst...@ds...>]

On Thu, 31 Jan 2002, Tarique Sani <ta...@sa...> wrote:

> On Wed, 30 Jan 2002, Chris Johnson wrote:
> 
> > Has anybody modified PHPLIB to use HTTP basic authentication (i.e. "realms")
> > instead of the default standalone login page stuff?
> 
> Err ... If you read the manual you must have noted that in-line
> authentication of PHPlib was written the over come the short commings of
> Basic HTTP authentication
> 
> Care to explain why you want to turn the wheel back?
> 

You can sort of simulate HTTP basic auth by creting a script that looks
like:

<?php
// This is the acces modifier script
include("prepend.inc");
page_open(array("sess"=>"someSess", "auth"=>"someAuth"));
// If you want some perms stuff here, feel free to use it.
page_close();
?>

and making the following change in your httpd.conf (of course, you're
using apache, right :)

<Directory /path/to/someDir/>
  php_value auto_prepend_file "/path/to/access_modifier.php"
</Directory>

This will force the phplib login mechanism into loading every time
anything in that directoy is hit (you can also use this in a File
directive or a vhost directive.. :). Instead of using the standard system
dialog from the browser, it will use the settings set in the "someAuth" 
subclass of the Auth object, thus having the same net effect as HHTP basic
auth, but with finer granularity.  You'll need to setup the standard
phplib ath stuff

-n  (Been offline for a while I know.. problems with old hosting
provider)

Re: [Phplib-users] Basic authentication

[Tarique S. <ta...@sa...>]

On Wed, 30 Jan 2002, Chris Johnson wrote:

> Has anybody modified PHPLIB to use HTTP basic authentication (i.e. "realms")
> instead of the default standalone login page stuff?

Err ... If you read the manual you must have noted that in-line
authentication of PHPlib was written the over come the short commings of
Basic HTTP authentication

Care to explain why you want to turn the wheel back?

Tarique

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com
The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

[Phplib-users] Basic authentication

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

Has anybody modified PHPLIB to use HTTP basic authentication (i.e. "realms")
instead of the default standalone login page stuff?

I know it's fairly trivial, but no point in reinventing the wheel if someone
else has already done it.

Thanks,
..chris

[Phplib-users] warning: undefined index: uid in ... auth.inc on line 235

[Peter K. <su...@si...>]

Hello,
it's a warning, but I don't know if it is something to take care of. And I am not 
able to switch off these warnings except setting E_ALL.

php 4.1.1 phplib 7.2d w2k apache mysql

thanx for any response

Peter Kursawe

[Phplib-users] OOH forms: error validating

[Emil M. <em...@pa...>]

There probably is a better and easier way but here is what works=
 for me.

in JavaScript

function isBlank(val) {
  var rxAnyChar =3D /./i;
  return (!rxAnyChar.test((val.replace(/\s/g, "")))) ? true :=
 false;
}

in PHP

function is_blank($val) {
 return (!preg_match("/./i", trim($val))) ? true : false;
}

Cheers
Emil

Re: [Phplib-users] OOH forms: error validating

[Herouth M. <he...@it...>]

You wrote:
> > "Tarique Sani wrote:
> > > On Tue, 29 Jan 2002, Matt Williams wrote:
> > >
> > > You have to manually validate textareas of OOH form in your
> > > code
> > >
> > > :-(
> >
> > That, or modify the of_textarea to have a similar functionality
> > to that of of_text (without the 'multiple' option).
> >
> > I just did the above for multiple checkboxes (if valid_e exists,
> > it checks that at least one checkbox is selected). Not too hard,
> > especially in non-multiple mode, where the ndx array is rather
> > simple.
>
> Thanks.
>
> So I just add a self_validate function to the bottom of
> of_textarea.inc and this should check?

No, there are two things you have to add:

One is self_get_js(), whose parameter is $ndx_array - an array of 
element numbers within the form. You then write the validation in 
Javascript. Take a look at of_text for an example, just notice what 
it does for non-multiple text fields.

The other is self_validate(), whose parameter is the value to 
validate. This function is called on the server side (in case the 
user disabled javascript). If it returns false, then the validation 
SUCCEEDED. Otherwise, it must return the error message (Like 
$this->valid_e or $this->length_e, depending on whether you are 
checking regexp or length).

Again, you may take a look at of_text for an example what to do. It 
may be that for regexps you'll have to change modifiers to deal with 
the fact that multiple lines are allowed.

Herouth

RE: [Phplib-users] OOH forms: error validating

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

> "Tarique Sani wrote:
> > On Tue, 29 Jan 2002, Matt Williams wrote:
> >
> > You have to manually validate textareas of OOH form in your code
> > :-(
>
> That, or modify the of_textarea to have a similar functionality to
> that of of_text (without the 'multiple' option).
>
> I just did the above for multiple checkboxes (if valid_e exists, it
> checks that at least one checkbox is selected). Not too hard,
> especially in non-multiple mode, where the ndx array is rather simple.
>


Thanks.

So I just add a self_validate function to the bottom of of_textarea.inc and
this should check?

I tried this and couldn't get it to work. I even went as far as making the
function

function self_validate($val) {
    if ($this->valid_e) {
	return $this->valid_e;
    }
    return false;
  }

just to return the error if valid_e was set without checking the value. My
add_element looks like this

$f->add_element(array("type"=>"textarea",
"name"=>"description",
"valid_e"=>"Please Enter a Description",
"rows"=>6,
"cols"=>25));

it just skips the check and validates the form

m:

Re: [Phplib-users] OOH forms: error validating

[Herouth M. <he...@it...>]

"Tarique Sani wrote:
> On Tue, 29 Jan 2002, Matt Williams wrote:
>
> You have to manually validate textareas of OOH form in your code
> :-(

That, or modify the of_textarea to have a similar functionality to 
that of of_text (without the 'multiple' option).

I just did the above for multiple checkboxes (if valid_e exists, it 
checks that at least one checkbox is selected). Not too hard, 
especially in non-multiple mode, where the ndx array is rather simple.

Herouth

Re: [Phplib-users] OOH forms: error validating

[Tarique S. <ta...@sa...>]

On Tue, 29 Jan 2002, Matt Williams wrote:

You have to manually validate textareas of OOH form in your code :-(

HTH

Tarique


-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

[Phplib-users] OOH forms: error validating

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

I have a textarea defined as a form element.

I need to test if this field has been filled. I don't care if it is a single
character, text with symbols, as long as the field has been entered.

Before switching to forms I just used to do a !$field to make sure it a
value has been entered.

I've tried "^[[:alnum:]].?$", "^[a-zA-Z0-9]+$" for valid_regex but it won't
catch it.

How can I check wether a value has been entered or not

m:

Re: [Phplib-users] tpl_form -- how to erase frozen values?

[Herouth M. <he...@it...>]

On 2002 January  25 ,Friday 01:03, you wrote:
> Okay, I've been moving right along converting my site to use
> tpl_form and I'm slowly become less and less convinced that it was
> a good idea. 

Well, I'm working with tpl_form, and I did need to make a couple of 
changes and wrappers, but it is really a good tool once you have it 
set up properly.

The main issue is setting up defaults when you use it for update 
rather than new records.

This issue is related to your problem.

> I have a form that submits to itself.  Sometimes I want to erase
> the value that the user entered before the form gets redisplayed.

You can do one of two things:

1. Change the value of the global variable before you display the 
form. Maybe you even need to do that before you create the form. 
Certainly before get_values().

The form gets the values to display the second time around from 
whatever you submitted. However, it doesn't use HTTP_POST_VARS (or 
_POST), but the simple global variables. So changing the variable's 
value should do the trick.

2. Change the value of the variable in the ooh_forms element. This 
method is "unsupported" in that you are not supposed to know how 
ooh_forms actually work. However, I use it for the "update" 
situation. It is a good method even after you have used get_values.

Say your form is $f, and the field name is 'email' then

$f->form_data->elements['email']['ob']->value = '';

HTH,
Herouth

Re: [Phplib-users] tpl_form -- how to erase frozen values?

[Tarique S. <ta...@sa...>]

On Thu, 24 Jan 2002, Carl Youngblood wrote:

> Okay, I've been moving right along converting my site to use tpl_form and
> I'm slowly become less and less convinced that it was a good idea.  The
> problem that I'm dealing with right now is:
Sad to hear about your problems, I usually dont use tpl_forms BUT OOH
forms with templates and then write a custom validator after the OOH form
has validated the syntax BUT

> entered gets displayed again.  Under certain conditions, I want to blank out
> the element and display nothing, even after the form has been submitted, but
> I can't figure out how to do it.

load_defaults function in OOH forms supports an arguement as an array
containing list of elements you want the default values to be loaded into 
just dont pass the fields which you dont want the defaults to load 

Hope this helps

Tarique Sani

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

[Phplib-users] MySQL error 1062 - (Duplicate entry / sessions

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

hi,
i am 'borrowing' a PHPLIB usertable from other regular PHP pages, so i 
am not very deep into PHPLIB and i never set up a system. 

Now with location headers i get this MySQL Error:
 MySQL Error: 1062 (Duplicate entry 'Session_UoD-
 dd6c24a7ea831ff10d2f541d51c538f0' for key 1)
 Session halted.

It seems to be linked with a header / location call
       include(page_close.inc);
       header("Location: volgendefile.php");

Possibly the page_close is not ready when the next page tries to 
page_open. This was suggested by the bloke who made this particular 
PHPLIB installation.

Anyone seen this before, anyone solved this?
cheers,
Chris

PS cc: to chayes @ antenna.nl is appreciated-- 
 ! 		please check my email address 			!  
 ! 	only my email ch...@an... works 		!
 ! 	email ch...@xs... is a black hole since januari 2002 !

Chris Hayes - Droef 35 - Wageningen

[Phplib-users] Thanks!

[Lindsay H. <fm...@fm...>]

I'd like to thank everyone on this list who gave me timely and relevant
information, accurate references and links w. regard to my recent question
on php3, php4 and phplib 6.1.  While no one was able to answer my question
directly, I received a number of responses, both via the list and privately,
from individuals who had contributed to the development of phplib, or who
had worked with it and had sound knowledge of its workings, of specific
security problems with it, and with php in general.  Although I didn't get a
complete answer to my original question, I have a number of references
bookmarked and a number of notes for further study.

Thanks again, y'all.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

RE: [Phplib-users] phplib 6.1, php3 and php4

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

>Bullsh*t.  The article you cited above is the first piece of solid 3rd
party
>information I've received from anyone on this list, and I would be totally
>remiss in my responsibilities to my business if I made decisions based on
>"you ought to do this or that" from people about whose backgrounds,
>experience and credentials I know nothing.

Lindsay, let's try to remember that the whole point of this list is to help
each other use PHPLib effectively. You didn't pay Michael or any of the
others for their advice, and they gave it, like grandpa, in an effort to
help you. It sounds like you were lucky enough to get plenty of responses so
why not just take what you need and ignore the rest-- or even better, thank
the people for taking the time to offer you suggestions.

-----Original Message-----
From: Lindsay Haisley [mailto:fm...@fm...]
Sent: Wednesday, January 23, 2002 9:52 PM
To: php...@li...
Subject: Re: [Phplib-users] phplib 6.1, php3 and php4


Thus spake Michael Chaney on Wed, Jan 23, 2002 at 07:30:11PM CST
> On Wed, Jan 23, 2002 at 02:27:39PM -0600, Lindsay Haisley wrote:
> > I appreciate notice that there's some kind of security problem with
phplib
> > 6.1, but until I get something specific w. regard to exactly what this
is, I
> > really can't consider it more than a rumor.  The software isn't broken.
It
> > works fine.  Everyone is happy.  I'd like to upgrade to take advantage
of
> > new features in php4, and I'd really rather hold off on upgrading phplib
> > until v8 comes out which, I understand, will take advantage of native
php4
> > session management.
>  
> |http://www.securereality.com.au/studyinscarlet.txt

This is an excellent document.  Thank you.  I browsed it, and bookmarked it
for further study.  Some of these security issues I've already dealt with,
and others are non-applicable since I have no users doing PHP programming on
the system.  Others certainly merit my further study.  There is no mention,
however, of any vulnerabilities implicit in phplib 6.1 which is the
reference you quote.

> Please see the php.net web site for a full list of vulnerabilities.
> Note also that session management is flakey in 4.0.6, the broken version
> that you wish to upgrade to.

I believe you misunderstood me.  I have no wish to upgrade to a specific
version of php4, and I'm aware that there are problems with early versions
of php4, which is one reason I've held off on upgrading.  Debian stable
offers this version, I believe, as a stock package and having been reminded
by you and other of these problems I'll consider other options.
  
> > I had hoped to get more technical specifics from people on this list,
but
> > all I've received is grandfatherly advice, which really hasn't told me
> > anything I don't already know.
>  
> We're giving you "grandfatherly advice" because you need it.  Sorry to
> sound like I'm looking down my nose at you; I'm not.  But you're making
> some bad decisions which could negatively impact your customers.

Bullshit.  The article you cited above is the first piece of solid 3rd party
information I've received from anyone on this list, and I would be totally
remiss in my responsibilities to my business if I made decisions based on
"you ought to do this or that" from people about whose backgrounds,
experience and credentials I know nothing.  Your claim that I'm making "bad
decisions" bears no weight until you back it up with something more solid
than rumors.  If you know of specific vulnerabilities and problems, cite
references to them.

> > I have a replacement server in the planning stage, and it'll be set up
with
> > php4 (a recent version) and a more recent version of phplib, but unless
and
> > until I get more information on exactly what breaks in phplib 6.1
between
> > php3 and php4 I don't plan to migrate stuff on the existing server.
>  
> Not a bad idea.  Note, folks: we're getting through.

Actually, to poke a bit of a needle in your ego, this move has been in the
planning stages since before I wrote this list, and as usual with such
moves, it offers me an path to a smooth service upgrade without disrupting
anyone's service.

> > If it works, don't fix it.  migration from phplib 6.1 to v7.x involves
> > code rewrites for subclasses so that they can be properly serialized.
Other
> > than a greatly expanded feature set, I have seen no reason to upgrade
and
> > have to do all this work.
>  
> What we're trying to explain to you, and you'll have none of it, is that
> sometimes software looks like it's working, but in fact there are
> potential problems and real problems.  Exploitability is a real problem.

Oh!  I get it.  If it looks like a duck, walks like a duck and quacks like a
duck, it may, indeed, be a chicken ;-)  And I don't believe you speak for
anyone on the list except yourself, since others on this list have written
notes which either passed on my original question or indeed actually
suggested that I stay with older versions of the software.

I'm aware of a number of exploits for PHP, have dealt with a number of these
issues, and will review the article you referenced for further information. 

> > > I suppose that you're still running an
> > > exploitable 2.2 kernel, too.
> >
> > Actually, yes.  Exploits in the 2.2 kernels involve the ability to
install
> > rogue modules from a shell.  There are no shell accounts on the server,
> > other than administrative accounts.  I know of no exploits implicating
the
> > Linux 2.2 kernel involving attack from external sources, except possibly
> > from potentiail DoS attacks.  Frankly, I don't believe there are any.
The
> > system is secure and has never been compromised.
>  
> There are also remote exploits with tcp/ip in some versions, please see
> your favorite security-oriented web site for details.  Sorry, you need
> to learn how to find this stuff out yourself.

Oh, I didn't realize that I didn't know how to research security issues. 
Thank you for enlightening me.  There's a setcap(2) vulnerability in 2.2.16,
IP masq (which I don't use) issues w. 2.2.20, a ptrace problem in 2.2.19
affecting only local users, and I really can't find much else.  There were
TCP/IP issues in the 2.0 series, but not in 2.2 as far as I know.  I'm sure
you're too busy with your important tasks to do more on this, but frankly, I
get the distinct feeling that you're blowing smoke.

> telnetd, and you didn't update it since last July, then it is fully
> exploitable (remote root shell) without needing access to an account on
> the box.

Negatory.  Telnetd is neither part of the kernel, nor for security reasons
related to those you cite, is telnetd running on any server here, nor are
port 23 requests even passed through my firewall.  Nor am I running
sendmail, wu-ftpd, rlogind nor a vulnerable version of ssh.  Thank you for
caring.

> There are plenty of other problems throughout the last couple
> of years, unless you're keeping up with them your box is vulnerable.

I keep up with them.  The problem with phplib which you cited, however,
appears to be nothing more than a rumor.  I'll honestly change my mind on
this if I can see something more solid.
  
> > > I would highly recommend that you get in the habit of upgrading PHP
and
> > > Apache when upgrades are available, and update phplib when upgrades
are
> > > available.  You do your customers a great disservice by not doing
this.
> >
> > A disservice?  How?  No one complains?  No accounts have been
compromised?
> > I really have a very high retention rate for customers, and almost all
my
> > new business comes from referrals from satisficed existing customers.
>  
> Me too, so what?  You've already said your customers know nothing about
> what you're doing.
>  
> > Michael, thank you for your recommendations.  I will take your obvious
> > wisdom and many years of experience as a system administrator into
account
> > when I consider your advice in planning future upgrades here.
>  
> Since you think you're too smart to listen to me, why not listen to
> everybody on here who's saying the exact same thing?

Actually, you're really the only one who has said most of this.

> I've been doing
> Unix administration professionally for well over 10 years now, and
> dynamic web content for 8 years (well, in two weeks, groups.google.com
> for more information), I've picked up a thing or two in that time.  You'd
> be wise to get off the know-it-all kick and listen.

Michael, I respect solid information, and I respect the advice of people
that can provide me with solid information and sound references.  What
you're saying is very weak on citations and references, and smacks seriously
of bravado and bs.  Sorry to be frank about this, but this is how you come
across.  If you've been doing system administration for 10 years and web
content programming for 8, then you should be able to correctly cite at
least a _general_ reference to a supposed security problem in phplib 6.1,
which was state of the art 3 years ago.  Maybe you spent most of your time
as a Windows NT administrator and programmer ;-)  Said security problem
doesn't show up in CERT's database, nor in any of the other security
references I have.  

Insofar as phplib partakes of underlying security problems with PHP then
yes, there are issues, and they have to be managed.  Security isn't an
absolute fix, it's a risk-management problem.  As an experienced system
administrator I'm sure you're aware of this.  I've managed it quite well so
far.  
 
> You've received a lot of excellent suggestions from this group.  I would
> recommend that you consider it all.

Yes, and none of it answered my original question, and some of it is in
direct contradiction to things you've said.  You're the only one who's
saying "exactly the same thing" - over and over....  :-(

I've gathered, or rather had my memory refreshed about some general PHP
issues, which I appreciate, and learned a few things here which were new,
none of them relating to the project at hand, and with the exception of the
security reference above, none of them from your offerings, unfortunately.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] tpl_form -- how to erase frozen values?

[Carl Y. <ca...@yo...>]

Okay, I've been moving right along converting my site to use tpl_form and
I'm slowly become less and less convinced that it was a good idea.  The
problem that I'm dealing with right now is:

I have a form that submits to itself.  Sometimes I want to erase the value
that the user entered before the form gets redisplayed.  Right now, whatever
the user enters is being redisplayed in the form elements.  For example, if
one of the form elements were for the user to enter his/her email, and the
user entered an email, after the form is submitted, the email that the user
entered gets displayed again.  Under certain conditions, I want to blank out
the element and display nothing, even after the form has been submitted, but
I can't figure out how to do it.

Thanks in advance for any help that someone can provide.

Carl Youngblood

Re: [Phplib-users] phplib 6.1, php3 and php4

[Philip S. <ph...@st...>]

I don't think there is a list of known issues anywhere.  The mailing list
archive is the best place to look (not trying to be rude here, but I've been
reading this list for a few years and honestly don't remember this stuff being
documented anywhere).

You mentioned that you are referring to your production server.  So if you don't
want to upgrade your production server right away (clearly this would be a very
bad idea) you should setup another server (perhaps a virtual host or just
another httpd on the same machine or whatever - there are many options) that
contains the new releases of PHP, PHPLIB, etc. and see what happens.  Chances
are that there will be a few problems here and there.

The thing with upgrading is that the longer you wait, the harder or more tedious
it becomes to upgrade.  I myself am still using one of the early 7.x releases
(7.2 perhaps) mainly because I simply haven't had the time to upgrade.  If you
have the time then you should definitely upgrade.  The 6.x release is extremely
old and 7.x is much much closer to a "1.0" release than 6.x was.

Philip



Lindsay Haisley wrote:

> I run professional online web services, some of them mission critical for a
> number of customers.  I use Debian GNU/Linux v2.2, apache 1.3.9, php3 and
> phplib 6.1 - all of which are standard issue in Debian 2.2.  I would like to
> upgrade php to v4.0.3 (the latest version in Debian's stable dist) to take
> advantage of a number of features in v4.  What kind of problems, if any,
> will I run into w. phplib in such an upgrade?
>
> --
> Lindsay Haisley       | "Everything works    |     PGP public key
> FMP Computer Services |       if you let it" |      available at
> 512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
> http://www.fmp.com    |                      |
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] phplib 6.1, php3 and php4

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

At 11:04 PM -0600 23/1/02, Lindsay Haisley wrote:
>Thus spake Richard Archer on Wed, Jan 23, 2002 at 10:35:32PM CST

>> I fixed a cross-site scripting vulnerability in PHPLIB last
>> October. I'm pretty sure that problem would have been there since
>> version 6.1 (although that version pre-dates my use of PHPLIB).
>> Consult the source forge bug tracker for more info.
>
>Did it make it into their database?

I committed it straight into the SourceForge CVS. It was fixed
following a bug report posted to the SourceForge bug tracker,
which is why I referred you there for further information.
It's at (watch the long lines):
http://sourceforge.net/tracker/index.php?func=detail&aid=450712&group_id=31885&atid=403611

You can also read my CVS commit comment and my addition to
the CHANGES file via the SourceForge CVS.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib-stable/CHANGES.diff?r1=1.8&r2=1.9
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib-stable/php/session.inc
(version 1.12)


>> I also re-worked the optional md5 hash login forms. Probably not an
>> issue for you since I don't think this was a feature of 6.1, however
>> it is an example of another security upgrade to PHPLIB.
>
>Yes, it's in 6.1 and I use it, although it's mostly for private pages that
>no one knows about that are for internal company use.  I've reworked the
>form many times.  Is there a security problem of some sort in the md5 hash.

The javascript failed on modern browsers and defaulted to sending the
plain text password. This wasn't apparent unless you used a sniffer or
added debug code to the PHP script to verify exactly what was going on.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib-stable/php/crcloginform.ihtml
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib-stable/php/crloginform.ihtml


>My main misson on this list was
>to find out about incompatibilities between phplib v6.1 and php4, and it
>seems that I struck out on this, but at least a portion of the traffic I've
>received from the list has been helpful in other regards.

Well, I think I made about a dozen changes to 7.2d to fix PHP4 problems.
I bet there are a whole lot more between 6.1 and 7.2d!!!

There used to exist a document with some hints to help with the upgrade
from v6 to v7. I don't seem to be able to find it now. I think it mainly
pointed out the changes in the session database tables.

 ...R.

Re: [Phplib-users] phplib 6.1, php3 and php4

[Lindsay H. <fm...@fm...>]

Thus spake Richard Archer on Wed, Jan 23, 2002 at 10:35:32PM CST
> At 9:52 PM -0600 23/1/02, Lindsay Haisley wrote:
> 
> >If you know of specific vulnerabilities and problems, cite
> >references to them.
> 
> I fixed a cross-site scripting vulnerability in PHPLIB last
> October. I'm pretty sure that problem would have been there since
> version 6.1 (although that version pre-dates my use of PHPLIB).
> Consult the source forge bug tracker for more info.

Did it make it into their database?  I don't see it offhand in either the
bugs or patches pages of the phplib section.  What's the Summary and the
submission alias (if it's there)?
 
> I also re-worked the optional md5 hash login forms. Probably not an
> issue for you since I don't think this was a feature of 6.1, however
> it is an example of another security upgrade to PHPLIB.

Yes, it's in 6.1 and I use it, although it's mostly for private pages that
no one knows about that are for internal company use.  I've reworked the
form many times.  Is there a security problem of some sort in the md5 hash.

> I would be surprised if there hasn't been other security fixes made
> to PHPLIB in the last 3 years. The CVS tree on SourceForge contains
> all the commit comments for the last couple of years... you might
> like to browse that.

I've got the web db open on phplib bugs and patches.  Thanks.  I'll take a
look at it, possibly at the CVS tree too.  My main misson on this list was
to find out about incompatibilities between phplib v6.1 and php4, and it
seems that I struck out on this, but at least a portion of the traffic I've
received from the list has been helpful in other regards.

> If you're going to upgrade to PHP4, I recommend putting in the effort
> to bring your code up to the current release of PHPLIB. Lots of effort
> has been put into making it run cleanly under PHP4. If you want to
> stick with 6.1 under PHP4, you will have to back-port a lot of the
> changes to the old version.

No, as I move sites to a new box I'll migrate them on a site by site basis
and redo the code as necessary to use recent versions of php4 and apache,
making sure everything is cool before I turn on DNS to them.  This is still
a work in the early stages though.

>  ...Richard.

Thanks for your help.  References to your work on phplib would be
appreciated, since I can't find it in the obvious places on sourceforge :-)
I wish everyone on this list were as civil as you are.  Whew!!

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

[Phplib-users] PHPLIB & Oracle

[Mike G. <mi...@op...>]

Hello,

I've noticed the Oracle db wrapper (db_oracle.inc) in phplib and was
wondering if anyone on the list is using Oracle with phplib..

I'd like to know how well it works, if there are any problems with the
install, hints for oracle/php integration would be terrific..

I'd also be interesting in hearing comparisons between Oracle & MySQL.. 
If you had Oracle licenses kicking around would you bother to use them
with a PHP App?

Mike
-- 
Mike Gifford, OpenConcept Consulting, http://www.openconcept.ca
Supporting progressive organizations in online campaigns and tools.
Feature: Women's Learning Partnership http://learningpartnership.org
Truth is that which confirms what we already believe. Northrop  Frye

Re: [Phplib-users] phplib 6.1, php3 and php4

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

At 9:52 PM -0600 23/1/02, Lindsay Haisley wrote:

>If you know of specific vulnerabilities and problems, cite
>references to them.

I fixed a cross-site scripting vulnerability in PHPLIB last
October. I'm pretty sure that problem would have been there since
version 6.1 (although that version pre-dates my use of PHPLIB).
Consult the source forge bug tracker for more info.

I also re-worked the optional md5 hash login forms. Probably not an
issue for you since I don't think this was a feature of 6.1, however
it is an example of another security upgrade to PHPLIB.

I would be surprised if there hasn't been other security fixes made
to PHPLIB in the last 3 years. The CVS tree on SourceForge contains
all the commit comments for the last couple of years... you might
like to browse that.

If you're going to upgrade to PHP4, I recommend putting in the effort
to bring your code up to the current release of PHPLIB. Lots of effort
has been put into making it run cleanly under PHP4. If you want to
stick with 6.1 under PHP4, you will have to back-port a lot of the
changes to the old version.

 ...Richard.

Re: [Phplib-users] phplib 6.1, php3 and php4

[Lindsay H. <fm...@fm...>]

Thus spake Michael Chaney on Wed, Jan 23, 2002 at 07:30:11PM CST
> On Wed, Jan 23, 2002 at 02:27:39PM -0600, Lindsay Haisley wrote:
> > I appreciate notice that there's some kind of security problem with phplib
> > 6.1, but until I get something specific w. regard to exactly what this is, I
> > really can't consider it more than a rumor.  The software isn't broken.  It
> > works fine.  Everyone is happy.  I'd like to upgrade to take advantage of
> > new features in php4, and I'd really rather hold off on upgrading phplib
> > until v8 comes out which, I understand, will take advantage of native php4
> > session management.
>  
> |http://www.securereality.com.au/studyinscarlet.txt

This is an excellent document.  Thank you.  I browsed it, and bookmarked it
for further study.  Some of these security issues I've already dealt with,
and others are non-applicable since I have no users doing PHP programming on
the system.  Others certainly merit my further study.  There is no mention,
however, of any vulnerabilities implicit in phplib 6.1 which is the
reference you quote.

> Please see the php.net web site for a full list of vulnerabilities.
> Note also that session management is flakey in 4.0.6, the broken version
> that you wish to upgrade to.

I believe you misunderstood me.  I have no wish to upgrade to a specific
version of php4, and I'm aware that there are problems with early versions
of php4, which is one reason I've held off on upgrading.  Debian stable
offers this version, I believe, as a stock package and having been reminded
by you and other of these problems I'll consider other options.
  
> > I had hoped to get more technical specifics from people on this list, but
> > all I've received is grandfatherly advice, which really hasn't told me
> > anything I don't already know.
>  
> We're giving you "grandfatherly advice" because you need it.  Sorry to
> sound like I'm looking down my nose at you; I'm not.  But you're making
> some bad decisions which could negatively impact your customers.

Bullshit.  The article you cited above is the first piece of solid 3rd party
information I've received from anyone on this list, and I would be totally
remiss in my responsibilities to my business if I made decisions based on
"you ought to do this or that" from people about whose backgrounds,
experience and credentials I know nothing.  Your claim that I'm making "bad
decisions" bears no weight until you back it up with something more solid
than rumors.  If you know of specific vulnerabilities and problems, cite
references to them.

> > I have a replacement server in the planning stage, and it'll be set up with
> > php4 (a recent version) and a more recent version of phplib, but unless and
> > until I get more information on exactly what breaks in phplib 6.1 between
> > php3 and php4 I don't plan to migrate stuff on the existing server.
>  
> Not a bad idea.  Note, folks: we're getting through.

Actually, to poke a bit of a needle in your ego, this move has been in the
planning stages since before I wrote this list, and as usual with such
moves, it offers me an path to a smooth service upgrade without disrupting
anyone's service.

> > If it works, don't fix it.  migration from phplib 6.1 to v7.x involves
> > code rewrites for subclasses so that they can be properly serialized. Other
> > than a greatly expanded feature set, I have seen no reason to upgrade and
> > have to do all this work.
>  
> What we're trying to explain to you, and you'll have none of it, is that
> sometimes software looks like it's working, but in fact there are
> potential problems and real problems.  Exploitability is a real problem.

Oh!  I get it.  If it looks like a duck, walks like a duck and quacks like a
duck, it may, indeed, be a chicken ;-)  And I don't believe you speak for
anyone on the list except yourself, since others on this list have written
notes which either passed on my original question or indeed actually
suggested that I stay with older versions of the software.

I'm aware of a number of exploits for PHP, have dealt with a number of these
issues, and will review the article you referenced for further information. 

> > > I suppose that you're still running an
> > > exploitable 2.2 kernel, too.
> >
> > Actually, yes.  Exploits in the 2.2 kernels involve the ability to install
> > rogue modules from a shell.  There are no shell accounts on the server,
> > other than administrative accounts.  I know of no exploits implicating the
> > Linux 2.2 kernel involving attack from external sources, except possibly
> > from potentiail DoS attacks.  Frankly, I don't believe there are any. The
> > system is secure and has never been compromised.
>  
> There are also remote exploits with tcp/ip in some versions, please see
> your favorite security-oriented web site for details.  Sorry, you need
> to learn how to find this stuff out yourself.

Oh, I didn't realize that I didn't know how to research security issues. 
Thank you for enlightening me.  There's a setcap(2) vulnerability in 2.2.16,
IP masq (which I don't use) issues w. 2.2.20, a ptrace problem in 2.2.19
affecting only local users, and I really can't find much else.  There were
TCP/IP issues in the 2.0 series, but not in 2.2 as far as I know.  I'm sure
you're too busy with your important tasks to do more on this, but frankly, I
get the distinct feeling that you're blowing smoke.

> telnetd, and you didn't update it since last July, then it is fully
> exploitable (remote root shell) without needing access to an account on
> the box.

Negatory.  Telnetd is neither part of the kernel, nor for security reasons
related to those you cite, is telnetd running on any server here, nor are
port 23 requests even passed through my firewall.  Nor am I running
sendmail, wu-ftpd, rlogind nor a vulnerable version of ssh.  Thank you for
caring.

> There are plenty of other problems throughout the last couple
> of years, unless you're keeping up with them your box is vulnerable.

I keep up with them.  The problem with phplib which you cited, however,
appears to be nothing more than a rumor.  I'll honestly change my mind on
this if I can see something more solid.
  
> > > I would highly recommend that you get in the habit of upgrading PHP and
> > > Apache when upgrades are available, and update phplib when upgrades are
> > > available.  You do your customers a great disservice by not doing this.
> >
> > A disservice?  How?  No one complains?  No accounts have been compromised?
> > I really have a very high retention rate for customers, and almost all my
> > new business comes from referrals from satisficed existing customers.
>  
> Me too, so what?  You've already said your customers know nothing about
> what you're doing.
>  
> > Michael, thank you for your recommendations.  I will take your obvious
> > wisdom and many years of experience as a system administrator into account
> > when I consider your advice in planning future upgrades here.
>  
> Since you think you're too smart to listen to me, why not listen to
> everybody on here who's saying the exact same thing?

Actually, you're really the only one who has said most of this.

> I've been doing
> Unix administration professionally for well over 10 years now, and
> dynamic web content for 8 years (well, in two weeks, groups.google.com
> for more information), I've picked up a thing or two in that time.  You'd
> be wise to get off the know-it-all kick and listen.

Michael, I respect solid information, and I respect the advice of people
that can provide me with solid information and sound references.  What
you're saying is very weak on citations and references, and smacks seriously
of bravado and bs.  Sorry to be frank about this, but this is how you come
across.  If you've been doing system administration for 10 years and web
content programming for 8, then you should be able to correctly cite at
least a _general_ reference to a supposed security problem in phplib 6.1,
which was state of the art 3 years ago.  Maybe you spent most of your time
as a Windows NT administrator and programmer ;-)  Said security problem
doesn't show up in CERT's database, nor in any of the other security
references I have.  

Insofar as phplib partakes of underlying security problems with PHP then
yes, there are issues, and they have to be managed.  Security isn't an
absolute fix, it's a risk-management problem.  As an experienced system
administrator I'm sure you're aware of this.  I've managed it quite well so
far.  
 
> You've received a lot of excellent suggestions from this group.  I would
> recommend that you consider it all.

Yes, and none of it answered my original question, and some of it is in
direct contradiction to things you've said.  You're the only one who's
saying "exactly the same thing" - over and over....  :-(

I've gathered, or rather had my memory refreshed about some general PHP
issues, which I appreciate, and learned a few things here which were new,
none of them relating to the project at hand, and with the exception of the
security reference above, none of them from your offerings, unfortunately.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |