Thread: Please help: PHP4/postgres db woes
Any postgre experts out there? We have a PHP4 site that worked fine under a previous RedHat build, but we just can't get it working on this Debian build. Here's what we're running: Debian 3.0r1 "woody" Kernel 2.4.18-bf2.4 Apache 1.3.26-0woo postgres 7.2.1-2wood php 4.1.2-6wood We've applied a script sent to us by the original programmers, that installed several logins and passwords. But when we go to login to our PHP site, our login is rejected. I've taken the following actions: 1) Checked to see that the database (called "ourdb") is in fact available by entering "psql ourdb." The database opens up to an "ourdb" prompt. 2) Made sure that postgresql is running by outputting ps ax: xxx ? S 0:00 /usr/lib/postgresql/bin/postmaster xxx ? S 0:00 postgres: stats buffer process xxx ? S 0:00 postgres: stats collector process 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect the following, and re-started postgre: #local all ident sameuser local all trust host all 127.0.0.1 255.0.0.0 ident sameuser host all 0.0.0.0 0.0.0.0 reject 4) Made sure that the php4-pgsql module is present -- I did an "apt-get" for this last week 5) Examined the postgres.log for clues -- the log file is empty, indicating that no login attempts have been made -- I suppose because the auth.php has not found the DB? 6) pg_exec call deprecated under PHP 4.2.0 and replaced with pg_query: since we're using php 4.1.2-6wood, it seems that this does not apply to our setup. Correct? All suggestions welcome. Solution guaranteed posted to the list. - Danny O'Brien
On Fri, 5 Mar 2004, Danny O'Brien wrote: > Any postgre experts out there? We have a PHP4 site that worked fine > under a previous RedHat build, but we just can't get it working on this > Debian build. > > Here's what we're running: > > Debian 3.0r1 "woody" > Kernel 2.4.18-bf2.4 > Apache 1.3.26-0woo > postgres 7.2.1-2wood > php 4.1.2-6wood If you can upgrade the above to the latest, that would be a good thing. Especially postgresql. At the very least, upgrade postgresql to 7.2.5 or whatever the last version of 7.2 was. > We've applied a script sent to us by the original programmers, that > installed several logins and passwords. > But when we go to login to our PHP site, our login is rejected. How are logins handled, via apache authentication, or custom PHP code? do you mean apache / web site authentication, or pgsql authentication is failing? > I've taken the following actions: ... > 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect the > following, and re-started postgre: > > #local all ident > sameuser > local all trust > host all 127.0.0.1 255.0.0.0 ident > sameuser > host all 0.0.0.0 0.0.0.0 reject You might want to try setting it to just trust on local and host 127.0.0.1/255.0.0.0 for testing to see if that lets you in. > 4) Made sure that the php4-pgsql module is present -- I did an > "apt-get" for this last week If you make a simple page that has this in it: <?php phpinfo(); ?> what do you get (look in the apache httpd.conf file for the extensions php is setup to handle. you may need to edit this and restart apache. > 5) Examined the postgres.log for clues -- the log file is empty, > indicating that no login attempts have been made -- I suppose because > the auth.php has not found the DB? If auth.php is not finding the db, what kind of error is it giving. More details make it easier to troubleshoot your problem. > 6) pg_exec call deprecated under PHP 4.2.0 and replaced with pg_query: > since we're using php 4.1.2-6wood, it seems that this does not apply to > our setup. Correct? Not a problem. While the function name is deprecate, it is still supported, at least through php 4.3.4, which I'm running on my workstation: $ php -v PHP 4.3.4 (cli) (built: Dec 4 2003 11:34:30) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies $ php -q <?php pg_exec(); ?> PHP Warning: Wrong parameter count for pg_exec() in - on line 2 Warning: Wrong parameter count for pg_exec() in - on line 2 So it sees it as a valid command. > All suggestions welcome. Solution guaranteed posted to the list. Post your error messages.
On Sat, 2004-03-06 at 07:18, Danny O'Brien wrote: > Any postgre experts out there? We have a PHP4 site that worked fine > under a previous RedHat build, but we just can't get it working on this > Debian build. We run heaps of PHP based sites on this codebase. If you want to upgrade to 7.4.1, Oliver Elphick (the Debian maintainer) has produced packages for Woody that we also use in some situations: deb http://people.debian.org/~elphick/debian/ stable main It seems most likely to me that your webserver is attempting to authenticate as www-data using 127.0.0.1 (rather than 'local' - i.e. no host spec in pg_connect) and that you are not allowing that in your pg_hba.conf, but the notes below do not give a lot of information to work from. Perhaps send the auth.php (with usernames / passwords munged), a "select * from pg_user" (ditto) Cheers, Andrew McMillan > > Here's what we're running: > > Debian 3.0r1 "woody" > Kernel 2.4.18-bf2.4 > Apache 1.3.26-0woo > postgres 7.2.1-2wood > php 4.1.2-6wood > > We've applied a script sent to us by the original programmers, that > installed several logins and passwords. > But when we go to login to our PHP site, our login is rejected. > > I've taken the following actions: > > 1) Checked to see that the database (called "ourdb") is in fact > available by entering "psql ourdb." The database opens up to an "ourdb" > prompt. > > 2) Made sure that postgresql is running by outputting ps ax: > > xxx ? S 0:00 /usr/lib/postgresql/bin/postmaster > xxx ? S 0:00 postgres: stats buffer process > xxx ? S 0:00 postgres: stats collector process > > 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect the > following, and re-started postgre: > > #local all ident > sameuser > local all trust > host all 127.0.0.1 255.0.0.0 ident > sameuser > host all 0.0.0.0 0.0.0.0 reject > > 4) Made sure that the php4-pgsql module is present -- I did an > "apt-get" for this last week > > 5) Examined the postgres.log for clues -- the log file is empty, > indicating that no login attempts have been made -- I suppose because > the auth.php has not found the DB? > > 6) pg_exec call deprecated under PHP 4.2.0 and replaced with pg_query: > since we're using php 4.1.2-6wood, it seems that this does not apply to > our setup. Correct? > > All suggestions welcome. Solution guaranteed posted to the list. > > - Danny O'Brien > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings ------------------------------------------------------------------------- Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: +64(4)499-2267 It is truth which you cannot contradict; you can without any difficulty contradict Socrates. - Plato -------------------------------------------------------------------------
On Mar 7, 2004, at 2:59 PM, Andrew McMillan wrote: > On Sat, 2004-03-06 at 07:18, Danny O'Brien wrote: >> Any postgre experts out there? We have a PHP4 site that worked fine >> under a previous RedHat build, but we just can't get it working on >> this >> Debian build. > > We run heaps of PHP based sites on this codebase. If you want to > upgrade to 7.4.1, Oliver Elphick (the Debian maintainer) has produced > packages for Woody that we also use in some situations: > > deb http://people.debian.org/~elphick/debian/ stable main > > It seems most likely to me that your webserver is attempting to > authenticate as www-data using 127.0.0.1 (rather than 'local' - i.e. no > host spec in pg_connect) and that you are not allowing that in your > pg_hba.conf, but the notes below do not give a lot of information to > work from. > > Perhaps send the auth.php (with usernames / passwords munged), a > "select > * from pg_user" (ditto) > > Cheers, > Andrew McMillan Hi Andrew, Thanks for your response. Below is the contents of auth.php, per your suggestion, if you feel like vetting the code. I'm not a PHP programmer -- we've hired one to mod the site, but he seems incapable of resolving the database issue. I'm responsible for getting the site running. I've been able to do it before, under RedHat, but not this time. When I set up the database (named identically to the previous), I ran a script called "create_tables.sql" that the original programmers gave me. This presumably provided the db with all necessary columns. I then followed that with a script called "fake_data.sql," also from the original programmers. This script contains a series of logins and passwords that correspond to the columns in the create_tables.sql. My conclusion from these actions is that we should now have a functioning database with usable logins and passwords. Is there any way for me to crack open the database to make sure that the columns, logins, and passwords are all positioned properly? Could it be that the scripts named above did not function properly, and we have what amounts to a non-functioning database? ********************************** auth.php: <? include('dbconnect.php'); include('util.php'); include( 'login.php' ); if( $real_login ) { $sql = "select fname, lname, password, admin_flag, client_id from usr where login = " . xxxxx($real_login); $result = pg_exec( $link, $sql ); if( $result && pg_numrows( $result ) == 1 ) { $row = pg_fetch_row( $result, 0 ); $pw = $row[2]; if( $row[2] == crypt( $real_password, $row[2] ) ) { setCookie( "srp_auth", "auth_login=$real_login&auth_password=$pw" ); $auth_user_name = $row[0] . " " . $row[1]; $auth_admin_flag = $row[3]; $auth_client_id = $row[4]; $sql = "update usr set last_login='now' where login=" . xxxxx( $real_login ); pg_exec( $sql ); } else { show_login( "<BR><B>We're sorry but that is incorrect. Please try again.</B>"); } } else { show_login( "<BR><B>We're sorry but that is incorrect. Please try again.</B>"); } } else if( $srp_auth ) { parse_str( $srp_auth ); $sql = "select fname, lname, admin_flag, client_id from usr where login = " . xxxxx( $auth_login ) . " and password = " . xxxxx( $auth_password ) ; $result = pg_exec( $link, $sql ); if( $result && pg_numrows( $result ) == 1 ) { $row = pg_fetch_row( $result, 0 ); $auth_user_name = $row[0] . " " . $row[1]; $auth_admin_flag = $row[2]; $auth_client_id = $row[3]; } else { show_login( "<BR><B>We're sorry but that is incorrect. Please try again.</B>"); } } else { show_login( "" ); } if( $auth_admin_flag == "A" ) { $auth_admin_flag = "P"; } if (isset($client_id) && $auth_client_id != 1 && $client_id != $auth_client_id) { show_login("Invalid data passed to form. Please log in again"); } if (isset($category_id)) { $sql = "select descr, client_id from category where id = $category_id"; $result = pg_exec($link, $sql); if ($auth_client_id != 1) { if (pg_result($result, 0, 1) != $auth_client_id) { show_login("Invalid data passed to form. Please log in again"); } } if (!isset($category_descr)) { $category_descr = pg_result($result, 0, 0); } } ?> Original post: >> >> Here's what we're running: >> >> Debian 3.0r1 "woody" >> Kernel 2.4.18-bf2.4 >> Apache 1.3.26-0woo >> postgres 7.2.1-2wood >> php 4.1.2-6wood >> >> We've applied a script sent to us by the original programmers, that >> installed several logins and passwords. >> But when we go to login to our PHP site, our login is rejected. >> >> I've taken the following actions: >> >> 1) Checked to see that the database (called "ourdb") is in fact >> available by entering "psql ourdb." The database opens up to an >> "ourdb" >> prompt. >> >> 2) Made sure that postgresql is running by outputting ps ax: >> >> xxx ? S 0:00 /usr/lib/postgresql/bin/postmaster >> xxx ? S 0:00 postgres: stats buffer process >> xxx ? S 0:00 postgres: stats collector process >> >> 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect the >> following, and re-started postgre: >> >> #local all ident >> sameuser >> local all trust >> host all 127.0.0.1 255.0.0.0 ident >> sameuser >> host all 0.0.0.0 0.0.0.0 reject >> >> 4) Made sure that the php4-pgsql module is present -- I did an >> "apt-get" for this last week >> >> 5) Examined the postgres.log for clues -- the log file is empty, >> indicating that no login attempts have been made -- I suppose because >> the auth.php has not found the DB? >> >> 6) pg_exec call deprecated under PHP 4.2.0 and replaced with pg_query: >> since we're using php 4.1.2-6wood, it seems that this does not apply >> to >> our setup. Correct? >> >> All suggestions welcome. Solution guaranteed posted to the list. >> >> - Danny O'Brien >> >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 7: don't forget to increase your free space map settings > ----------------------------------------------------------------------- > -- > Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, > Wellington > WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis > St > DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: > +64(4)499-2267 > It is truth which you cannot contradict; you can without any difficulty > contradict Socrates. - Plato > ----------------------------------------------------------------------- > -- >
Hi Scott, Thanks very much for your response. Please see my responses below. On Mar 5, 2004, at 1:47 PM, scott.marlowe wrote: > On Fri, 5 Mar 2004, Danny O'Brien wrote: > >> Any postgre experts out there? We have a PHP4 site that worked fine >> under a previous RedHat build, but we just can't get it working on >> this >> Debian build. >> >> Here's what we're running: >> >> Debian 3.0r1 "woody" >> Kernel 2.4.18-bf2.4 >> Apache 1.3.26-0woo >> postgres 7.2.1-2wood >> php 4.1.2-6wood > > If you can upgrade the above to the latest, that would be a good thing. > Especially postgresql. At the very least, upgrade postgresql to 7.2.5 > or > whatever the last version of 7.2 was. > >> We've applied a script sent to us by the original programmers, that >> installed several logins and passwords. >> But when we go to login to our PHP site, our login is rejected. > > How are logins handled, via apache authentication, or custom PHP code? I don't know. There's an auth.php file, which would lead me to conclude the latter. > > do you mean apache / web site authentication, or pgsql authentication > is > failing? My feeling is that either the site is not "seeing" the database, or, more likely, the database itself is not properly set up. > >> I've taken the following actions: > ... >> 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect the >> following, and re-started postgre: >> >> #local all ident >> sameuser >> local all trust >> host all 127.0.0.1 255.0.0.0 ident >> sameuser >> host all 0.0.0.0 0.0.0.0 reject > > You might want to try setting it to just trust on local and host > 127.0.0.1/255.0.0.0 for testing to see if that lets you in. I took this suggestion -- login still fails. > >> 4) Made sure that the php4-pgsql module is present -- I did an >> "apt-get" for this last week > > If you make a simple page that has this in it: > > <?php > phpinfo(); > ?> > > what do you get (look in the apache httpd.conf file for the extensions > php is setup to handle. you may need to edit this and restart apache. After following the above suggestion, the URL based on the above returns a comprehensive PHP configuration info page. > >> 5) Examined the postgres.log for clues -- the log file is empty, >> indicating that no login attempts have been made -- I suppose because >> the auth.php has not found the DB? > > If auth.php is not finding the db, what kind of error is it giving. > More details make it easier to troubleshoot your problem. The site returns only the standard error contained in the auth.php: "We're sorry but that is incorrect. Please try again." Thanks again for your help. -- Danny O'Brien
Hi Bruce,
Thanks for your assistance. Please see my responses below.
On Mar 8, 2004, at 12:21 PM, bruce wrote:
> danny...
>
> you might want to take a direct look at the actual database using the
> command line functions to determine if there is actual information
> within
> the database. if there is information there.. any reasonable php
> programmer
> can track down the issue...
OK -- one of the tables is called "usr," so I logged into the database
as the original database creator (not root) and entered this:
SELECT * FROM usr;
and it showed me the appropriate data in the proper columns. So it
appears the scripts worked and populated the database. So that answers
that question.
> so make sure the db is actually populated with data, make sure you can
> actually read/write something to the db with the php code.. etc... walk
> through a test plan to isolate what the prob might be...
My next test was an attempt to manually enter values into the database
(called "ourdb" for the sake of this test):
ourdb=# INSERT INTO usr (id, fname, lname, login, password, admin_flag,
client_id) VALUES (4, 'Fred', 'Friendly', 'Fred', 'xxxxx', 'A', 1)
ourdb-#
The database did not accept the new information. Why not? More
questions....
Still, it seems that since we have a working database with actual data,
the problem must be that the PHP code is not checking with the
database, but simply responding with the error. Right?
Here's something interesting from the auth.php:
if( $real_login )
{
$sql = "select fname, lname, password, admin_flag, client_id from usr
where login = " . xxxxx($real_login);
It seems that the above code does not list all the columns in the table
"usr" -- here are those columns:
id | fname | lname | login | password | admin_flag |
client_id |
Should I add 'id' and 'login' to the line $sql = "select fname, lname,
password, admin_flag, client_id from usr where login = " .
xxxxx($real_login);
The complete auth.php is listed below, if you're available to check it
out.
Thanks again for your thoughts.
- Danny O'Brien
>
>
> -----Original Message-----
> From: pgsql-php-owner@postgresql.org
> [mailto:pgsql-php-owner@postgresql.org]On Behalf Of Danny O'Brien
> Sent: Monday, March 08, 2004 8:55 AM
> To: Andrew McMillan
> Cc: pgsql-php@postgresql.orgpgsql-php@postgresql.org
> Subject: Re: [PHP] Please help: PHP4/postgres db woes
>
>
> On Mar 7, 2004, at 2:59 PM, Andrew McMillan wrote:
>
>> On Sat, 2004-03-06 at 07:18, Danny O'Brien wrote:
>>> Any postgre experts out there? We have a PHP4 site that worked fine
>>> under a previous RedHat build, but we just can't get it working on
>>> this
>>> Debian build.
>>
>> We run heaps of PHP based sites on this codebase. If you want to
>> upgrade to 7.4.1, Oliver Elphick (the Debian maintainer) has produced
>> packages for Woody that we also use in some situations:
>>
>> deb http://people.debian.org/~elphick/debian/ stable main
>>
>> It seems most likely to me that your webserver is attempting to
>> authenticate as www-data using 127.0.0.1 (rather than 'local' - i.e.
>> no
>> host spec in pg_connect) and that you are not allowing that in your
>> pg_hba.conf, but the notes below do not give a lot of information to
>> work from.
>>
>> Perhaps send the auth.php (with usernames / passwords munged), a
>> "select
>> * from pg_user" (ditto)
>>
>> Cheers,
>> Andrew McMillan
>
>
> Hi Andrew,
>
> Thanks for your response. Below is the contents of auth.php, per your
> suggestion, if you feel like vetting the code. I'm not a PHP
> programmer.
> I'm responsible for getting the site
> running. I've been able to do it before, under RedHat, but not this
> time.
>
> When I set up the database (named identically to the previous), I ran a
> script called "create_tables.sql" that the original programmers gave
> me. This presumably provided the db with all necessary columns.
>
> I then followed that with a script called "fake_data.sql," also from
> the original programmers. This script contains a series of logins and
> passwords that correspond to the columns in the create_tables.sql. My
> conclusion from these actions is that we should now have a functioning
> database with usable logins and passwords.
>
> Is there any way for me to crack open the database to make sure that
> the columns, logins, and passwords are all positioned properly? Could
> it be that the scripts named above did not function properly, and we
> have what amounts to a non-functioning database?
>
>
>
>
> **********************************
> auth.php:
>
> <?
> include('dbconnect.php');
> include('util.php');
> include( 'login.php' );
>
> if( $real_login )
> {
> $sql = "select fname, lname, password, admin_flag, client_id from usr
> where login = " . xxxxx($real_login);
>
> $result = pg_exec( $link, $sql );
>
> if( $result && pg_numrows( $result ) == 1 )
> {
> $row = pg_fetch_row( $result, 0 );
> $pw = $row[2];
> if( $row[2] == crypt( $real_password, $row[2] ) )
> {
> setCookie( "srp_auth", "auth_login=$real_login&auth_password=$pw"
> );
>
> $auth_user_name = $row[0] . " " . $row[1];
> $auth_admin_flag = $row[3];
> $auth_client_id = $row[4];
>
> $sql = "update usr set last_login='now' where login=" . xxxxx(
> $real_login );
> pg_exec( $sql );
> }
>
> else
> {
> show_login( "<BR><B>We're sorry but that is incorrect. Please try
> again.</B>");
> }
> }
>
> else
> {
> show_login( "<BR><B>We're sorry but that is incorrect. Please try
> again.</B>");
> }
> }
>
> else if( $ourdb_auth )
> {
> parse_str( $ourdb_auth );
>
> $sql = "select fname, lname, admin_flag, client_id from usr where
> login = " . xxxxx( $auth_login ) . " and password = " . xxxxx(
> $auth_password ) ;
>
> $result = pg_exec( $link, $sql );
>
> if( $result && pg_numrows( $result ) == 1 )
> {
> $row = pg_fetch_row( $result, 0 );
> $auth_user_name = $row[0] . " " . $row[1];
> $auth_admin_flag = $row[2];
> $auth_client_id = $row[3];
> }
>
> else
> {
> show_login( "<BR><B>We're sorry but that is incorrect. Please try
> again.</B>");
> }
> }
>
> else
> {
> show_login( "" );
> }
>
>
> if( $auth_admin_flag == "A" )
> {
> $auth_admin_flag = "P";
> }
>
> if (isset($client_id) && $auth_client_id != 1 && $client_id !=
> $auth_client_id)
> {
> show_login("Invalid data passed to form. Please log in again");
> }
>
> if (isset($category_id))
> {
> $sql = "select descr, client_id from category where id =
> $category_id";
> $result = pg_exec($link, $sql);
>
> if ($auth_client_id != 1)
> {
> if (pg_result($result, 0, 1) != $auth_client_id)
> {
> show_login("Invalid data passed to form. Please log in again");
> }
> }
>
> if (!isset($category_descr))
> {
> $category_descr = pg_result($result, 0, 0);
> }
> }
> ?>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Original post:
>
>>>
>>> Here's what we're running:
>>>
>>> Debian 3.0r1 "woody"
>>> Kernel 2.4.18-bf2.4
>>> Apache 1.3.26-0woo
>>> postgres 7.2.1-2wood
>>> php 4.1.2-6wood
>>>
>>> We've applied a script sent to us by the original programmers, that
>>> installed several logins and passwords.
>>> But when we go to login to our PHP site, our login is rejected.
>>>
>>> I've taken the following actions:
>>>
>>> 1) Checked to see that the database (called "ourdb") is in fact
>>> available by entering "psql ourdb." The database opens up to an
>>> "ourdb"
>>> prompt.
>>>
>>> 2) Made sure that postgresql is running by outputting ps ax:
>>>
>>> xxx ? S 0:00 /usr/lib/postgresql/bin/postmaster
>>> xxx ? S 0:00 postgres: stats buffer process
>>> xxx ? S 0:00 postgres: stats collector process
>>>
>>> 3) Altered the pg_hba.conf (located in /etc/postgresql) to reflect
>>> the
>>> following, and re-started postgre:
>>>
>>> #local all ident
>>> sameuser
>>> local all trust
>>> host all 127.0.0.1 255.0.0.0 ident
>>> sameuser
>>> host all 0.0.0.0 0.0.0.0 reject
>>>
>>> 4) Made sure that the php4-pgsql module is present -- I did an
>>> "apt-get" for this last week
>>>
>>> 5) Examined the postgres.log for clues -- the log file is empty,
>>> indicating that no login attempts have been made -- I suppose because
>>> the auth.php has not found the DB?
>>>
>>> 6) pg_exec call deprecated under PHP 4.2.0 and replaced with
>>> pg_query:
>>> since we're using php 4.1.2-6wood, it seems that this does not apply
>>> to
>>> our setup. Correct?
>>>
>>> All suggestions welcome. Solution guaranteed posted to the list.
>>>
>>> - Danny O'Brien
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 7: don't forget to increase your free space map settings
>> ----------------------------------------------------------------------
>> -
>> --
>> Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St,
>> Wellington
>> WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis
>> St
>> DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE:
>> +64(4)499-2267
>> It is truth which you cannot contradict; you can without any
>> difficulty
>> contradict Socrates. - Plato
>> ----------------------------------------------------------------------
>> -
>> --
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
Hello Danny, I can't go through your whole script but I recommend you use Pear::DB as an abstraction layer for the pgsql connection and interaction. This will give you more power with the debug and you can keep everything simple IMHO. More info at http://pear.php.net/manual/en/package.database.php#package.database.db It is default on PHP, so you don't even need to install anything. Cheers Regards, David Costa, PHP-PostgreSQL Advocacy team http://postgresql.org david at postgresql ddoot org gurugeek att php dot net $dsn = 'pgsql://world:most_advanced@localhost/open_source_database'; On Mar 9, 2004, at 4:45 PM, Danny O'Brien wrote: >>> >>> packages for Woody that we also use in some situations: >>> >>> deb http://people.debian.org/~elphick/debian/ stable main >>> >>> It seems most likely to me that your webserver is attempting to >>> authenticate as www-data using 127.0.0.1 (rather than 'local' - i.e. >>> no >>> host spec in pg_connect) and that you are not allowing that in your >>> pg_hba.conf, but the notes below do not give a lot of information to >>> work from. >>> >>> Perhaps send the auth.php (with usernames / passwords munged), a >>> "select >>> * from pg_user" (ditto) >>> >>> Cheers, >>> Andrew McMillan >> >> >> Hi Andrew, >> >> Thanks for your response. Below is the contents of auth.php, per your >> suggestion, if you feel like vetting the code. I'm not a PHP >> programmer. >> I'm responsible for getting the site >> running. I've been able to do it before, under RedHat, but no
Danny O'Brien typed this on 03/09/2004 07:45 AM: > > My next test was an attempt to manually enter values into the database > (called "ourdb" for the sake of this test): > > ourdb=# INSERT INTO usr (id, fname, lname, login, password, admin_flag, > client_id) VALUES (4, 'Fred', 'Friendly', 'Fred', 'xxxxx', 'A', 1) > ourdb-# > Typically, you would end your INSERT statement with a ';' In your example, you do not, otherwise the db would give you back some sort of response. > The database did not accept the new information. Why not? More > questions.... > -Robby -- Robby Russell, | Sr. Administrator / Lead Programmer Command Prompt, Inc. | http://www.commandprompt.com rrussell@commandprompt.com | Telephone: (503) 222.2783
On Mar 9, 2004, at 11:04 AM, Robby Russell wrote: > Danny O'Brien typed this on 03/09/2004 07:45 AM: >> My next test was an attempt to manually enter values into the >> database (called "ourdb" for the sake of this test): >> ourdb=# INSERT INTO usr (id, fname, lname, login, password, >> admin_flag, client_id) VALUES (4, 'Fred', 'Friendly', 'Fred', >> 'xxxxx', 'A', 1) >> ourdb-# > > Typically, you would end your INSERT statement with a ';' Right -- that worked. So the database seems to be completely fine. Thank you. - Danny O'Brien
good suggestion.. however, i would argue that danny should make sure he can do a manual command, and that he can determine that he can actually manually get the "php" sql command to work from the manual command line... once he gets this, then the rest becomes fairly straight forward... -bruce -----Original Message----- From: pgsql-php-owner@postgresql.org [mailto:pgsql-php-owner@postgresql.org]On Behalf Of David Costa Sent: Tuesday, March 09, 2004 8:02 AM To: Danny O'Brien Cc: pgsql-php@postgresql.org Subject: Re: [PHP] Please help: PHP4/postgres db woes Hello Danny, I can't go through your whole script but I recommend you use Pear::DB as an abstraction layer for the pgsql connection and interaction. This will give you more power with the debug and you can keep everything simple IMHO. More info at http://pear.php.net/manual/en/package.database.php#package.database.db It is default on PHP, so you don't even need to install anything. Cheers Regards, David Costa, PHP-PostgreSQL Advocacy team http://postgresql.org david at postgresql ddoot org gurugeek att php dot net $dsn = 'pgsql://world:most_advanced@localhost/open_source_database'; On Mar 9, 2004, at 4:45 PM, Danny O'Brien wrote: >>> >>> packages for Woody that we also use in some situations: >>> >>> deb http://people.debian.org/~elphick/debian/ stable main >>> >>> It seems most likely to me that your webserver is attempting to >>> authenticate as www-data using 127.0.0.1 (rather than 'local' - i.e. >>> no >>> host spec in pg_connect) and that you are not allowing that in your >>> pg_hba.conf, but the notes below do not give a lot of information to >>> work from. >>> >>> Perhaps send the auth.php (with usernames / passwords munged), a >>> "select >>> * from pg_user" (ditto) >>> >>> Cheers, >>> Andrew McMillan >> >> >> Hi Andrew, >> >> Thanks for your response. Below is the contents of auth.php, per your >> suggestion, if you feel like vetting the code. I'm not a PHP >> programmer. >> I'm responsible for getting the site >> running. I've been able to do it before, under RedHat, but no ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
David Costa typed this on 03/09/2004 08:01 AM: > Hello Danny, > I can't go through your whole script but I recommend you use Pear::DB as > an abstraction layer for the pgsql connection and interaction. > This will give you more power with the debug and you can keep everything > simple IMHO. > > More info at > http://pear.php.net/manual/en/package.database.php#package.database.db > > It is default on PHP, so you don't even need to install anything. I'll second this. When he can get the SQL syntax down, then he should play with PEAR. :-) However, I think knowing the standard pg_connect(), pg_query() commands would be useful..then when he goes to try PEAR, he'll see how much time and more useful it can be. my 34 cents, -Robby -- Robby Russell, | Sr. Administrator / Lead Programmer Command Prompt, Inc. | http://www.commandprompt.com rrussell@commandprompt.com | Telephone: (503) 222.2783
В Пнд, 08.03.2004, в 17:55, Danny O'Brien пишет:
> **********************************
> auth.php:
>
> <?
> include('dbconnect.php');
Hi Danny,
if you haven't fixed this already, you can look for a pg_connect
function call in dbconnect.php and remove the @ in front of it - ifg
it's there. (the @ doesn't have to be there neccessarily. It switches
off error reporting for that function call.) Additionally, you can
search the php code for a call to the function error_reporting, which
also controls, which error messages are reported and which not. In
particular, a parameter value of 0 to this function instructs php to
suppress all error output.
Another thing you might want to look at is enabling logging in the
postgresql server / startup script.
--
Markus Bertheau <twanger@bluetwanger.de>