Menu
▾
▴
phppgadmin-help — For broadcasting of forum and big reports to developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(19) |
May
(131) |
Jun
(48) |
Jul
(81) |
Aug
(23) |
Sep
(78) |
Oct
(37) |
Nov
(50) |
Dec
(21) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(39) |
Feb
(56) |
Mar
(56) |
Apr
(40) |
May
(59) |
Jun
(56) |
Jul
(103) |
Aug
(77) |
Sep
(60) |
Oct
(40) |
Nov
(37) |
Dec
(58) |
| 2004 |
Jan
(76) |
Feb
(56) |
Mar
(23) |
Apr
(34) |
May
(25) |
Jun
(49) |
Jul
(30) |
Aug
(53) |
Sep
(28) |
Oct
(22) |
Nov
(46) |
Dec
(26) |
| 2005 |
Jan
(48) |
Feb
(93) |
Mar
(41) |
Apr
(57) |
May
(38) |
Jun
(42) |
Jul
(22) |
Aug
(65) |
Sep
(20) |
Oct
(19) |
Nov
(67) |
Dec
(34) |
| 2006 |
Jan
(35) |
Feb
(11) |
Mar
(24) |
Apr
(30) |
May
(12) |
Jun
(11) |
Jul
(15) |
Aug
(14) |
Sep
(16) |
Oct
(21) |
Nov
(14) |
Dec
(11) |
| 2007 |
Jan
(29) |
Feb
(22) |
Mar
(27) |
Apr
(127) |
May
(12) |
Jun
(44) |
Jul
(44) |
Aug
(8) |
Sep
(6) |
Oct
(52) |
Nov
(17) |
Dec
(16) |
| 2008 |
Jan
(25) |
Feb
(14) |
Mar
(21) |
Apr
(15) |
May
(5) |
Jun
(13) |
Jul
(42) |
Aug
(31) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(24) |
| 2009 |
Jan
(8) |
Feb
(16) |
Mar
(183) |
Apr
(586) |
May
(8) |
Jun
(4) |
Jul
(12) |
Aug
(7) |
Sep
(7) |
Oct
(12) |
Nov
(8) |
Dec
(3) |
| 2010 |
Jan
(42) |
Feb
(1) |
Mar
(10) |
Apr
(1) |
May
(10) |
Jun
(12) |
Jul
(7) |
Aug
(25) |
Sep
(47) |
Oct
(45) |
Nov
(11) |
Dec
(19) |
| 2011 |
Jan
(4) |
Feb
(4) |
Mar
(6) |
Apr
(5) |
May
(11) |
Jun
(8) |
Jul
(14) |
Aug
(4) |
Sep
(8) |
Oct
(17) |
Nov
(42) |
Dec
(13) |
| 2012 |
Jan
(21) |
Feb
(20) |
Mar
(5) |
Apr
(10) |
May
(5) |
Jun
(4) |
Jul
(14) |
Aug
(3) |
Sep
(6) |
Oct
(11) |
Nov
(29) |
Dec
(6) |
| 2013 |
Jan
(9) |
Feb
(3) |
Mar
(8) |
Apr
(5) |
May
(6) |
Jun
(4) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2012-04-13 23:45:14
|
Bugs item #3517603, was opened at 2012-04-13 16:45 Message generated for change (Tracker Item Submitted) made by iktus1818 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3517603&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web Site Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: LightBe Corp (iktus1818) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot Access phpPgAdmin At All Initial Comment: I am attempting to use both versions 5.0.3 & 5.0.4 on a Mac Mini running Lion Server. I was using 5.0.3 successfully until today. I was able to display the home page where I could log in and access the database. When I tried today I got a strange page. I am a novice when it comes to PHP so I was not able to figure out what was up. Here is what displayed when I tried to go to localhost/phpPgAdmin. <?php /** * Main access point to the app. * * $Id: index.php,v 1.13 2007/04/18 14:08:48 mr-russ Exp $ */ // Include application functions $_no_db_connection = true; include_once('./libraries/lib.inc.php'); $misc->printHeader('', null, true); $rtl = (strcasecmp($lang['applangdir'], 'rtl') == 0); $cols = $rtl ? '*,'.$conf['left_width'] : $conf['left_width'].',*'; $mainframe = '<frame src="intro.php" name="detail" id="detail" frameborder="0" />' ?> <frameset cols="<?php echo $cols ?>"> <?php if ($rtl) echo $mainframe; ?> <frame src="browser.php" name="browser" id="browser" frameborder="0" /> <?php if (!$rtl) echo $mainframe; ?> <noframes> <body> <?php echo $lang['strnoframes'] ?><br /> <a href="intro.php"><?php echo $lang['strnoframeslink'] ?></a> </body> </noframes> </frameset> <?php $misc->printFooter(false); ?> At this point I decided to try and run version 5.0.4. I got the same error. I am able to access the services which require PostgreSQL without any problems. I did a sudo serveradmin fullstatus postgres command in the terminal. I got the following results. postgres:dataDirHasBeenInitialized = yes postgres:PG_VERSION = "9.0.5" postgres:dataDir = "/var/pgsql" postgres:postgresIsResponding = yes postgres:dataDirIsDirectory = yes postgres:PGserverVersion = 90005 postgres:dataDirExists = yes postgres:setStateVersion = 1 postgres:state = "RUNNING" I do not know where else to look. I do not know if it is an issue with Lion or a setting in my configuration.Again I was successful accessing this until today. I have not changed anything relating to phpPgAdmin at all. Any help would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3517603&group_id=37132 |
|
From: <joy...@re...> - 2012-04-09 01:35:08
|
The following data was submitted on 2012/04/09 01:35. ====== E-mail ====== Name Joy Kar PostgreSQL ver. 8.1.23 phpPgAdmin ver. 5.0.3 Comments Dear Sir/Madam i have developed a trigger in postgresql 9.1 and whenever i transfer this to webbased phppgAdmin i face some problem. so i request you to e-mail me an example of a simple trigger executing a procedure which has any return type. |
|
From: <hp...@ps...> - 2012-03-26 19:57:24
|
The following data was submitted on 2012/03/26 19:57. ====== E-mail ====== Name Henry Pfeil PostgreSQL ver. n/a phpPgAdmin ver. n/a Comments Page affected - http://phppgadmin.sourceforge.net/doku.php?id=download Name: "The PostgreSQL Yum Repository" Link: http://yum.pgsqlrpms.org/ Pgsqlrpms is a dead link. It redirects to http://domains.googlesyndication.com/apps/domainpark I thought I'd investigate gophp5, but http://gophp5.org/ somehow lands on musicroller.com. Dig shows they both have the same IP address. Fedora 16+ maintains its own phppgadmin rpm files. Yum will find them in fedora.repo and fedora-updates.repo, or on its distribution mirror sites. -- Obquote: "Something's afoot, and it's not attached to my ankle." -Musings of Psnarf, 3.14;159 |
|
From: SourceForge.net <no...@so...> - 2012-03-22 12:46:25
|
The following forum message was posted by ioguix at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4977986: Hello, Do you have an error message of any kind ? did you check in your PHP log files if you have errors as well ? My best theory would be that your path to pg_dump is wrong or that pg_dump is not available on your phppgadmin server. Make sure to set "$conf['servers'][0]['pg_dump_path']" and "$conf['servers'][0]['pg_dump_path']" correctly in your "conf/config.inc.php". If this is the error, I'm wondering why you don't have errors but only a blank page... |
|
From: SourceForge.net <no...@so...> - 2012-03-12 12:18:28
|
The following forum message was posted by scharon at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4801691: I still have my problem, [u]but[/u], I think I've found where is the real problem. I told that permission was correctly setted, remember? Well, in fact I discovered that there's an issue with the inheritance of the permissions in the sub folders... I've never seen the MS Server 2008 doing this. Maybe a problem of compatibility between MS Server and PostgreSQL? However, I must find more time to investigate about this strange problem... (in an other hand, my chief is talking about buying MS SQL server and get rid off PostrgeSQL for other reasons. So...) I realise that I made an error earlier, in a reply. The version of PostrgeSQL we use is "PostgreSQL 9.0.1, compiled by Visual C++ build 1500, 64-bit" An I forgot to answer a question: we have some relation regularly dropped. Once or twice a week a table is dropped. |
|
From: SourceForge.net <no...@so...> - 2012-03-05 23:19:52
|
The following forum message was posted by ffrstar777 at http://sourceforge.net/projects/phppgadmin/forums/forum/115883/topic/5091552: hi, i installed the bitnami package and tried to access phppgadmin, but somehow i get a 500 internal server error. the logs show this: [code][Mon Mar 05 14:11:33 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" (pid 26156) terminated with exit with status '0' [Mon Mar 05 14:11:38 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" restarted (pid 7188) [Mon Mar 05 14:11:38 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" (pid 7188) terminated with exit with status '0' [Mon Mar 05 14:11:44 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" restarted (pid 24420) [Mon Mar 05 14:11:44 2012] [error] [client 127.0.0.1] (OS 109)The pipe has been ended. : FastCGI: comm with server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" aborted: GetOverlappedResult() failed [Mon Mar 05 14:11:44 2012] [error] [client 127.0.0.1] FastCGI: incomplete headers (0 bytes) received from server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" [Mon Mar 05 14:11:44 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" (pid 24420) terminated with exit with status '0' [Mon Mar 05 14:11:49 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" restarted (pid 16864) [Mon Mar 05 14:11:49 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" (pid 16864) terminated with exit with status '0' [Mon Mar 05 14:11:54 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" restarted (pid 33716) [Mon Mar 05 14:11:54 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" (pid 33716) terminated with exit with status '0' [Mon Mar 05 14:11:59 2012] [warn] FastCGI: server "C:/server/bitnami/apache2/cgi-bin/php-cgi.exe" restarted (pid 23560)[/code] is there any way i can fix this? thanks for your help |
|
From: SourceForge.net <no...@so...> - 2012-03-04 10:07:57
|
Bugs item #3347174, was opened at 2011-06-30 10:06 Message generated for change (Comment added) made by gallaecio You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3347174&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Constraints Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Adrián Chaves Fernández (gallaecio) Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: I can’t create a Foreign Key contraint through from GUI Initial Comment: At the step where I’ supposed to choose the field that is primary key in the external table, I can’t select any of the table columns. Same process with PostgreSQL code is possible. phpPgAdmin version: 5.0.2. PostgreSQL version: 9.0.4. Locale: gl_ES. ---------------------------------------------------------------------- >Comment By: Adrián Chaves Fernández (gallaecio) Date: 2012-03-04 02:07 Message: My former tests were in Rekonq 0.8.0 IIRC. I have just tried to reproduce it now and could not, it works like a charm. I am currently using: Web browser: Rekonq 0.9.0 PorsgreSQL: 9.1.2 phpPgAdmin: 5.0.3 ---------------------------------------------------------------------- Comment By: Adrián Chaves Fernández (gallaecio) Date: 2012-03-04 02:07 Message: Thank you for your bug report. We have been unable to duplicate your report. Please provide more specific information such as the following (if you have not already): 1. Operating System (both server and client) 2. PHP version 3. PostgreSQL version 4. Browser and Version Then please identify the exact steps to duplicating this bug. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2011-11-29 14:46 Message: Hello, I cannot reproduce your bug. Could you please provide the schema of both tables so we can try to reproduce this bug ? What is your browser and its version ? When you say you cannot select any of the table column, do you mean the list is disabled ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3347174&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-29 17:42:39
|
Bugs item #3495749, was opened at 2012-02-29 09:42 Message generated for change (Tracker Item Submitted) made by igossage You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3495749&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 5.0.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Isaac Gossage (igossage) Assigned to: Nobody/Anonymous (nobody) Summary: SQL broken across multiple browser tabs Initial Comment: It is no longer possible to open sql query pages within multiple tabs of a browser to run and edit differing queries without the query in the 1st tab being "overwritten" by the subsequent query of the 2nd tab. Example: phpPgAdmin -> Select a Server -> Select a Database: Open "SQL" link in 1st tab. Open "SQL" link in 2nd tab. in the first tab, enter query into sql text box: SELECT 'Alpha'; Click [Execute] button, the results should be: ?column? Alpha in the second tab, enter query into sql text box: SELECT 'Beta'; Click [Execute] button, the results should be: ?column? Beta Go back to the first tab, click "Edit Sql" link at the bottom of the results, UNEXPECTEDLY the query that you're presented with is now: SELECT 'Beta'; Whereas, the expected (correct) result would be: Select 'Alpha'; This makes phpPgAdmin virtually unusable in an evironment where one would wish to compare multiple queries, for example. I've only been able to compare with phpPgAdmin version 4.2.x ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3495749&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 20:12:53
|
Feature Requests item #3495412, was opened at 2012-02-28 12:12 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418983&aid=3495412&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Open Priority: 5 Private: No Submitted By: () Assigned to: Christopher Kings-Lynne (chriskl) Summary: Change configuration to separate files Initial Comment: For my company it was needed to get the per server config in seperated files. So i edited conf/config.inc.php and removed all the $conf['servers'][0][vars] references and replaced it with: $confdir="/var/www/html/phpggadmin/conf/conf.d/"; $snum=0; foreach (glob($confdir . "*.php") as $filename) { include($filename); $snum++; } In the conf.d directory i created a file 0000default.php with the following code: $conf['servers'][$snum]['desc'] = 'Server description'; $conf['servers'][$snum]['host'] = ''; $conf['servers'][$snum]['port'] = 5432; $conf['servers'][$snum]['sslmode'] = 'allow'; $conf['servers'][$snum]['defaultdb'] = 'template1'; $conf['servers'][$snum]['pg_dump_path'] = '/usr/bin/pg_dump'; $conf['servers'][$snum]['pg_dumpall_path'] = '/usr/bin/pg_dumpall'; $conf['servers'][$snum]['slony_support'] = false; $conf['servers'][$snum]['slony_sql'] = '/usr/share/pgsql'; hence, the per server config is removed from the main config file. This way version control and distributed configuration management (like with puppet) is much easier for us. I already posted this in a mailing list and this was the answer: Splitting configuration files might be a good idea yes. However, I have two concerns: * how confusing it could be for users to have multiple configuration files ? Today, some of them barely read (when they read it) the only configuration file... * security issue. If including any kind of PHP files from this folder, it might lead to a security issue where any kind PHP of code might be executed. The second point could be solved by using ini files instead of plain PHP. > Is there a change this minor change will make it to the next release? Considering the security issue, no, it will not be included in the next release. However, if moving to ini file, yes, we could probably consider it it there's no other issue. We just need to rethink the whole conf file though... Could you please post a feature request on sf.net if possible ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418983&aid=3495412&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 15:57:14
|
The following forum message was posted by ioguix at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4801691: Ok, Please, keep us informed about how it is going with such permissions... |
|
From: SourceForge.net <no...@so...> - 2012-02-28 15:30:30
|
Bugs item #3468882, was opened at 2012-01-03 02:02 Message generated for change (Comment added) made by dikr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Dirk Kraemer (dikr) Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: UPDATE single row with varchar key: empty where clause Initial Comment: Version: phpPgAdmin-5.0.3-1.el5 (CentOS release 5.7) We observed a problem when updating a row in a table with a varchar key column. The where clause in the generated UPDATE statement is totally missing an the statement would update all rows instead of only the current one. Some details in following example: We have a table with a single varchar key column 'pcname'. We want to update a row with value of 'msh100' with phppgadmin. The generated page where we can see and edit the columns values contains a hidden field with the key values: <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:6:"msh100";}" /> This looks like a serialzed version of $key = array ("pcname" => "msh100"); However: Occurrences of quotes '"' are replaced by 'quot;'. It seems that the replacement of '"' with '"' make the unserialization fail. This is done e.g. in line 173,174 of display.php: 173 $status = $data->editRow($_POST['table'], $_POST['values'], $_POST['nulls'], 174 $_POST['format'], $_POST['types'], unserialize($_POST['key'])); So the result of unserialize is not an array and the where-clause is not where pcname='msh100' but empty. This is just a quick guess. Don't know internals of phppgadmin enough to give more hints. Hope this report is sufficient. Thanks and regards Dirk ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-02-28 07:30 Message: Yes, now it seems to work correctly. Thanks again for this fix and also for your other work in this project. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-28 07:01 Message: Oops, you were right. I just fixed and pushed the DoDelRow action in our official repository. Here is the url: https://github.com/phppgadmin/phppgadmin/commit/2905458c43549768b218fdac019407e3cc0a2490 Thank you again, it helps having people testing and double checking ;) ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-02-28 03:09 Message: Thank your for that fix. I changed the affected lines within display.php in out current installation. Updates seem to work correctly now. However, we still seem to have problems when trying to delete rows. Shouldn't we add similar patches to function deDelRow echo "<input type=\"hidden\" name=\"key\" value=\"", htmlspecialchars(serialize($_REQUEST['key'])), "\" />\n"; ...... $status = $data->deleteRow($_POST['table'], unserialize($_POST['key'])); ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-27 16:00 Message: I fixed the bug in our official git repository. See: https://github.com/phppgadmin/phppgadmin/commit/c1f24fad465047d71b8cca29ad3bf20256a72436 It will be available in our next release and a snapshot can be downloaded from the following link: https://github.com/phppgadmin/phppgadmin/zipball/REL_5-0 Thank you for your report. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 11:10 Message: Thank you for your investigation ! So I'm now able to reproduce your bug and found what happen, at least on my side. Using a string with a newline, when serializing it, the newline was "\n". But when POST-ing it to the serveur, this newline becomes "\r\n", I guess because of the HTTP protocol. So on the other side, when unserializing the array, this string is one char longer. As the serialization algorithm keeps track of each string parameters size, the unserialize function fail because the value sounds different. I have been able to validate that adding the following line in the beginning of the doEditRow function: $_REQUEST['key'] = preg_replace('@\r\n@', "\n", $_REQUEST['key']); which fix the bug. So the trick is to encode newlines so they are not replaced on the way. So far, I have been able to fix this bug combining (un)serialize with base64_encode/decode OR urlencode/decode. I'll think a bit more about the best solution, and look for some other places in the code which might be impacted as well, then produce a bug fix. Thank you for your help and report, stay tuned for the fix soon ! ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-01-05 08:21 Message: First of all: Thank you very much for searching. I tried to reproduce the error and I think i found a hint: Indeed the problem does not occur if there is only a normal value in key column. So my example was not sufficient, sorry for that. But if there is a newline character at the end and try to update we have a problem. I put the value 'mypc<newline>' into key column. Hidden field is now <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:5:"mypc ";}" /> When we click save button we get: Message in web interface: SQL error: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »spss_pkey« (double key value violates Unique constraint) In statement: UPDATE "public"."spss" SET "pcname"='mypc ', "einrichtungskennzeichen"='RZS ', "nummer"='69', "lizenz_beginn"='2012-01-05', "lizenz_ende"='2012-01-06', "spss_version"='20 ', "win_version"='- ', "rechnungsdatum"=NULL, "bemerkung"='' The same error message can be found within postgres logfile. The where clause is missing in update statement. We also find errors in web server's log file complaining about errors in unserialize function and invalid argument for foreach. I will post these separately in a small file. Sorry, i had not noticed that the row which led to the error had the newline character in the key column, while my example had not. I should have checked my bug report better before posting. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:26 Message: According to the PHP doc, unserialize should rise a E_NOTICE when it fails. Could you check your httpd log files or try to setup your php.ini to catch it ? see: http://php.net/unserialize thank you. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:24 Message: So I tried to reproduce the bug without success (PostgreSQL 9.1.2, PPA 5.0.3, PHP 5.3.3, lighttpd 1.4.28 and FF 8.0). I used a single column table, with type 'text' and a PK on it. Update on a row went fine. «It seems that the replacement of '"' with '"' » This is normal, we must escape the serialized array before putting it in a HTML attribute. If quotes were not escaped, we would break the html code. However, data are sent non-escaped by any browser (usually). Do you have any other information abou tthis bug which would lead me to the real bug ? ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-03 03:22 Message: Hello, This is a pretty ugly bug, I don't understand why we never found/heard about it :( I'll work on this tonight and try to fix this as soon as possible. Thank you for this report ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 15:01:25
|
Bugs item #3468882, was opened at 2012-01-03 02:02 Message generated for change (Comment added) made by ioguix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Dirk Kraemer (dikr) Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: UPDATE single row with varchar key: empty where clause Initial Comment: Version: phpPgAdmin-5.0.3-1.el5 (CentOS release 5.7) We observed a problem when updating a row in a table with a varchar key column. The where clause in the generated UPDATE statement is totally missing an the statement would update all rows instead of only the current one. Some details in following example: We have a table with a single varchar key column 'pcname'. We want to update a row with value of 'msh100' with phppgadmin. The generated page where we can see and edit the columns values contains a hidden field with the key values: <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:6:"msh100";}" /> This looks like a serialzed version of $key = array ("pcname" => "msh100"); However: Occurrences of quotes '"' are replaced by 'quot;'. It seems that the replacement of '"' with '"' make the unserialization fail. This is done e.g. in line 173,174 of display.php: 173 $status = $data->editRow($_POST['table'], $_POST['values'], $_POST['nulls'], 174 $_POST['format'], $_POST['types'], unserialize($_POST['key'])); So the result of unserialize is not an array and the where-clause is not where pcname='msh100' but empty. This is just a quick guess. Don't know internals of phppgadmin enough to give more hints. Hope this report is sufficient. Thanks and regards Dirk ---------------------------------------------------------------------- >Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-28 07:01 Message: Oops, you were right. I just fixed and pushed the DoDelRow action in our official repository. Here is the url: https://github.com/phppgadmin/phppgadmin/commit/2905458c43549768b218fdac019407e3cc0a2490 Thank you again, it helps having people testing and double checking ;) ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-02-28 03:09 Message: Thank your for that fix. I changed the affected lines within display.php in out current installation. Updates seem to work correctly now. However, we still seem to have problems when trying to delete rows. Shouldn't we add similar patches to function deDelRow echo "<input type=\"hidden\" name=\"key\" value=\"", htmlspecialchars(serialize($_REQUEST['key'])), "\" />\n"; ...... $status = $data->deleteRow($_POST['table'], unserialize($_POST['key'])); ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-27 16:00 Message: I fixed the bug in our official git repository. See: https://github.com/phppgadmin/phppgadmin/commit/c1f24fad465047d71b8cca29ad3bf20256a72436 It will be available in our next release and a snapshot can be downloaded from the following link: https://github.com/phppgadmin/phppgadmin/zipball/REL_5-0 Thank you for your report. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 11:10 Message: Thank you for your investigation ! So I'm now able to reproduce your bug and found what happen, at least on my side. Using a string with a newline, when serializing it, the newline was "\n". But when POST-ing it to the serveur, this newline becomes "\r\n", I guess because of the HTTP protocol. So on the other side, when unserializing the array, this string is one char longer. As the serialization algorithm keeps track of each string parameters size, the unserialize function fail because the value sounds different. I have been able to validate that adding the following line in the beginning of the doEditRow function: $_REQUEST['key'] = preg_replace('@\r\n@', "\n", $_REQUEST['key']); which fix the bug. So the trick is to encode newlines so they are not replaced on the way. So far, I have been able to fix this bug combining (un)serialize with base64_encode/decode OR urlencode/decode. I'll think a bit more about the best solution, and look for some other places in the code which might be impacted as well, then produce a bug fix. Thank you for your help and report, stay tuned for the fix soon ! ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-01-05 08:21 Message: First of all: Thank you very much for searching. I tried to reproduce the error and I think i found a hint: Indeed the problem does not occur if there is only a normal value in key column. So my example was not sufficient, sorry for that. But if there is a newline character at the end and try to update we have a problem. I put the value 'mypc<newline>' into key column. Hidden field is now <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:5:"mypc ";}" /> When we click save button we get: Message in web interface: SQL error: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »spss_pkey« (double key value violates Unique constraint) In statement: UPDATE "public"."spss" SET "pcname"='mypc ', "einrichtungskennzeichen"='RZS ', "nummer"='69', "lizenz_beginn"='2012-01-05', "lizenz_ende"='2012-01-06', "spss_version"='20 ', "win_version"='- ', "rechnungsdatum"=NULL, "bemerkung"='' The same error message can be found within postgres logfile. The where clause is missing in update statement. We also find errors in web server's log file complaining about errors in unserialize function and invalid argument for foreach. I will post these separately in a small file. Sorry, i had not noticed that the row which led to the error had the newline character in the key column, while my example had not. I should have checked my bug report better before posting. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:26 Message: According to the PHP doc, unserialize should rise a E_NOTICE when it fails. Could you check your httpd log files or try to setup your php.ini to catch it ? see: http://php.net/unserialize thank you. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:24 Message: So I tried to reproduce the bug without success (PostgreSQL 9.1.2, PPA 5.0.3, PHP 5.3.3, lighttpd 1.4.28 and FF 8.0). I used a single column table, with type 'text' and a PK on it. Update on a row went fine. «It seems that the replacement of '"' with '"' » This is normal, we must escape the serialized array before putting it in a HTML attribute. If quotes were not escaped, we would break the html code. However, data are sent non-escaped by any browser (usually). Do you have any other information abou tthis bug which would lead me to the real bug ? ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-03 03:22 Message: Hello, This is a pretty ugly bug, I don't understand why we never found/heard about it :( I'll work on this tonight and try to fix this as soon as possible. Thank you for this report ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 11:12:16
|
The following forum message was posted by scharon at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4801691: Oups. I shouldn't have write this (too optimist) : The problem occured again this morning. Now, I've tried to change permissions of the postrges user on the database folder: It no longer have all the permissions on it. Only read and write. It do not have the "change permissions" right. I didn't do that before because one said to me that postgres user [u]must[/u] have [u]all[/u] the permissions on the database folder, otherwise it won't work. I've done some tests and PosgresSQL work perfectly with only read and write permissions. I hope this will be the solution to my problem. |
|
From: SourceForge.net <no...@so...> - 2012-02-28 11:09:16
|
Bugs item #3468882, was opened at 2012-01-03 02:02 Message generated for change (Comment added) made by dikr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Dirk Kraemer (dikr) Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: UPDATE single row with varchar key: empty where clause Initial Comment: Version: phpPgAdmin-5.0.3-1.el5 (CentOS release 5.7) We observed a problem when updating a row in a table with a varchar key column. The where clause in the generated UPDATE statement is totally missing an the statement would update all rows instead of only the current one. Some details in following example: We have a table with a single varchar key column 'pcname'. We want to update a row with value of 'msh100' with phppgadmin. The generated page where we can see and edit the columns values contains a hidden field with the key values: <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:6:"msh100";}" /> This looks like a serialzed version of $key = array ("pcname" => "msh100"); However: Occurrences of quotes '"' are replaced by 'quot;'. It seems that the replacement of '"' with '"' make the unserialization fail. This is done e.g. in line 173,174 of display.php: 173 $status = $data->editRow($_POST['table'], $_POST['values'], $_POST['nulls'], 174 $_POST['format'], $_POST['types'], unserialize($_POST['key'])); So the result of unserialize is not an array and the where-clause is not where pcname='msh100' but empty. This is just a quick guess. Don't know internals of phppgadmin enough to give more hints. Hope this report is sufficient. Thanks and regards Dirk ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-02-28 03:09 Message: Thank your for that fix. I changed the affected lines within display.php in out current installation. Updates seem to work correctly now. However, we still seem to have problems when trying to delete rows. Shouldn't we add similar patches to function deDelRow echo "<input type=\"hidden\" name=\"key\" value=\"", htmlspecialchars(serialize($_REQUEST['key'])), "\" />\n"; ...... $status = $data->deleteRow($_POST['table'], unserialize($_POST['key'])); ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-27 16:00 Message: I fixed the bug in our official git repository. See: https://github.com/phppgadmin/phppgadmin/commit/c1f24fad465047d71b8cca29ad3bf20256a72436 It will be available in our next release and a snapshot can be downloaded from the following link: https://github.com/phppgadmin/phppgadmin/zipball/REL_5-0 Thank you for your report. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 11:10 Message: Thank you for your investigation ! So I'm now able to reproduce your bug and found what happen, at least on my side. Using a string with a newline, when serializing it, the newline was "\n". But when POST-ing it to the serveur, this newline becomes "\r\n", I guess because of the HTTP protocol. So on the other side, when unserializing the array, this string is one char longer. As the serialization algorithm keeps track of each string parameters size, the unserialize function fail because the value sounds different. I have been able to validate that adding the following line in the beginning of the doEditRow function: $_REQUEST['key'] = preg_replace('@\r\n@', "\n", $_REQUEST['key']); which fix the bug. So the trick is to encode newlines so they are not replaced on the way. So far, I have been able to fix this bug combining (un)serialize with base64_encode/decode OR urlencode/decode. I'll think a bit more about the best solution, and look for some other places in the code which might be impacted as well, then produce a bug fix. Thank you for your help and report, stay tuned for the fix soon ! ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-01-05 08:21 Message: First of all: Thank you very much for searching. I tried to reproduce the error and I think i found a hint: Indeed the problem does not occur if there is only a normal value in key column. So my example was not sufficient, sorry for that. But if there is a newline character at the end and try to update we have a problem. I put the value 'mypc<newline>' into key column. Hidden field is now <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:5:"mypc ";}" /> When we click save button we get: Message in web interface: SQL error: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »spss_pkey« (double key value violates Unique constraint) In statement: UPDATE "public"."spss" SET "pcname"='mypc ', "einrichtungskennzeichen"='RZS ', "nummer"='69', "lizenz_beginn"='2012-01-05', "lizenz_ende"='2012-01-06', "spss_version"='20 ', "win_version"='- ', "rechnungsdatum"=NULL, "bemerkung"='' The same error message can be found within postgres logfile. The where clause is missing in update statement. We also find errors in web server's log file complaining about errors in unserialize function and invalid argument for foreach. I will post these separately in a small file. Sorry, i had not noticed that the row which led to the error had the newline character in the key column, while my example had not. I should have checked my bug report better before posting. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:26 Message: According to the PHP doc, unserialize should rise a E_NOTICE when it fails. Could you check your httpd log files or try to setup your php.ini to catch it ? see: http://php.net/unserialize thank you. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:24 Message: So I tried to reproduce the bug without success (PostgreSQL 9.1.2, PPA 5.0.3, PHP 5.3.3, lighttpd 1.4.28 and FF 8.0). I used a single column table, with type 'text' and a PK on it. Update on a row went fine. «It seems that the replacement of '"' with '"' » This is normal, we must escape the serialized array before putting it in a HTML attribute. If quotes were not escaped, we would break the html code. However, data are sent non-escaped by any browser (usually). Do you have any other information abou tthis bug which would lead me to the real bug ? ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-03 03:22 Message: Hello, This is a pretty ugly bug, I don't understand why we never found/heard about it :( I'll work on this tonight and try to fix this as soon as possible. Thank you for this report ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 07:08:39
|
Feature Requests item #3495226, was opened at 2012-02-27 23:08 Message generated for change (Tracker Item Submitted) made by meo63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418983&aid=3495226&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Permissions Group: None Status: Open Priority: 5 Private: No Submitted By: meo bogliolo (meo63) Assigned to: Christopher Kings-Lynne (chriskl) Summary: Showing only owned schemas Initial Comment: I need to show only owned schema to casual users. The patch is quite easy and very similar to showing only owned databases. Here it is (based on 5.0.3): conf/config.inc.php-dist 95a96,99 > // Only show owned schemas? > // Note: This will simply hide other schemas in the list > $conf['owned_schema_only'] = false; > classes/database/Postgres.php.new 861c861 < global $conf, $slony; --- > global $conf, $slony, $misc; 872a873,880 > > $server_info = $misc->getServerInfo(); > if (isset($conf['owned_schema_only']) && $conf['owned_schema_only'] && !$this->isSuperUser($server_info['username'])) { > $username = $server_info['username']; > $this->clean($username); > $where .= " AND pu.rolname='{$username}' "; > } > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418983&aid=3495226&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 00:05:33
|
Bugs item #3429633, was opened at 2011-10-28 00:02 Message generated for change (Comment added) made by ioguix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3429633&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General >Group: GIT >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: "Back" link from "Browse" leads to error Initial Comment: Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 461 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 463 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 465 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 475 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 544 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 549 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 554 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 559 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 564 Notice: Undefined index: table in /var/www/html/pgadmin/tblproperties.php on line 583 If you click on "Browse" again, you get this: SQL error: ERROR: relation "<br /><b>Notice</b>: Undefined index: table in <b>/var/www/ht" does not exist In statement: SELECT COUNT(*) AS total FROM (SELECT * FROM "<br /><b>Notice</b>: Undefined index: table in <b>/var/www/html/pgadmin/tblproperties.php</b> on line <b>572</b><br />") AS sub ---------------------------------------------------------------------- >Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-27 16:05 Message: Hi, This bug has been fixed in our current GIT reposotory. See : https://github.com/phppgadmin/phppgadmin/commit/18ae4fb7e1ff62da9cc98d9237431db72107033f The snapshot of the next 5.0.4 is available here: https://github.com/phppgadmin/phppgadmin/zipball/master Thank you for your report ! ---------------------------------------------------------------------- Comment By: Arnaud Daret (arnocertic) Date: 2011-11-04 10:58 Message: Ok so another way keeping return_url may be : 1) urldecode the return_url 2) explode the string using "&" 3) array_map the result array using htmlspecialchars 4) implode array using "&" ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2011-11-04 10:49 Message: "But maybe there's another cases of "return_url" more difficult than this one..." Indeed. When browsing, the return_url might point to the table properties, the column properties, the "select" page, the query form, ...and probably a bunch of some more... ---------------------------------------------------------------------- Comment By: Arnaud Daret (arnocertic) Date: 2011-11-04 10:21 Message: URL query : I talk about the part of URL behind the "?" character To show a table from left tree, you click on http://localhost/phppgadmin/redirect.php?subject=table&server=localhost%3A5432%3Aallow&database=db_test&schema=public&table=storage_doc It gives you the table properties When you choose to browse the table rows, the return_url value in URL "return link" will be : tblproperties.php%3Fserver%3Dlocalhost%253A5432%253Aallow%26amp%3Bdatabase%3Dcamis_www%26amp%3Bschema%3Dpublic%26amp%3Btable%3Dstorage_doc All parameters contained into this return_url are allready known in the page (server, database, schema and table), so the return_url could be rebuild by getting current page url query parameters. But maybe there's another cases of "return_url" more difficult than this one... ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2011-11-04 08:46 Message: Yes, rebuild the url based on some session variables... what you mean by simply "with url query" ? ---------------------------------------------------------------------- Comment By: Arnaud Daret (arnocertic) Date: 2011-11-04 08:43 Message: So as you said, it may usefull (and more secure) to drop this return_url parameter and to rebuild url with session or simply with url query ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2011-11-04 08:36 Message: About your fix proposal, using urldecode instead of htmlspecialchars open a XSS security issue. Check with this url (edit to fit your setup): http://localhostdisplay.php?server=localhost%3A5432%3Aallow&database=postgres&schema=pg_catalog&table=pg_stat_database&subject=table&return_url=%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E&return_desc=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2011-11-04 08:30 Message: Hey, Thank you for the report, I found that bug as well, but hadn't time to fix it yet... I'll take care of that as soon as I find some time, but patch are welcome. The overall idea would be to drop the return_url parameter from the url itself...(put it in session ?) ---------------------------------------------------------------------- Comment By: Arnaud Daret (arnocertic) Date: 2011-11-04 08:18 Message: Replacing the line 581 in display.php echo "\t<li><a href=\"". htmlspecialchars($_REQUEST['return_url']) ."\">". htmlspecialchars($_REQUEST['return_desc']) ."</a></li>\n"; By echo "\t<li><a href=\"". urldecode($_REQUEST['return_url']) ."\">". htmlspecialchars($_REQUEST['return_desc']) ."</a></li>\n"; resolves the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3429633&group_id=37132 |
|
From: SourceForge.net <no...@so...> - 2012-02-28 00:00:44
|
Bugs item #3468882, was opened at 2012-01-03 02:02 Message generated for change (Comment added) made by ioguix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Dirk Kraemer (dikr) Assigned to: J.Guillaume (ioguix) de Rorthais (ioguix) Summary: UPDATE single row with varchar key: empty where clause Initial Comment: Version: phpPgAdmin-5.0.3-1.el5 (CentOS release 5.7) We observed a problem when updating a row in a table with a varchar key column. The where clause in the generated UPDATE statement is totally missing an the statement would update all rows instead of only the current one. Some details in following example: We have a table with a single varchar key column 'pcname'. We want to update a row with value of 'msh100' with phppgadmin. The generated page where we can see and edit the columns values contains a hidden field with the key values: <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:6:"msh100";}" /> This looks like a serialzed version of $key = array ("pcname" => "msh100"); However: Occurrences of quotes '"' are replaced by 'quot;'. It seems that the replacement of '"' with '"' make the unserialization fail. This is done e.g. in line 173,174 of display.php: 173 $status = $data->editRow($_POST['table'], $_POST['values'], $_POST['nulls'], 174 $_POST['format'], $_POST['types'], unserialize($_POST['key'])); So the result of unserialize is not an array and the where-clause is not where pcname='msh100' but empty. This is just a quick guess. Don't know internals of phppgadmin enough to give more hints. Hope this report is sufficient. Thanks and regards Dirk ---------------------------------------------------------------------- >Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-02-27 16:00 Message: I fixed the bug in our official git repository. See: https://github.com/phppgadmin/phppgadmin/commit/c1f24fad465047d71b8cca29ad3bf20256a72436 It will be available in our next release and a snapshot can be downloaded from the following link: https://github.com/phppgadmin/phppgadmin/zipball/REL_5-0 Thank you for your report. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 11:10 Message: Thank you for your investigation ! So I'm now able to reproduce your bug and found what happen, at least on my side. Using a string with a newline, when serializing it, the newline was "\n". But when POST-ing it to the serveur, this newline becomes "\r\n", I guess because of the HTTP protocol. So on the other side, when unserializing the array, this string is one char longer. As the serialization algorithm keeps track of each string parameters size, the unserialize function fail because the value sounds different. I have been able to validate that adding the following line in the beginning of the doEditRow function: $_REQUEST['key'] = preg_replace('@\r\n@', "\n", $_REQUEST['key']); which fix the bug. So the trick is to encode newlines so they are not replaced on the way. So far, I have been able to fix this bug combining (un)serialize with base64_encode/decode OR urlencode/decode. I'll think a bit more about the best solution, and look for some other places in the code which might be impacted as well, then produce a bug fix. Thank you for your help and report, stay tuned for the fix soon ! ---------------------------------------------------------------------- Comment By: Dirk Kraemer (dikr) Date: 2012-01-05 08:21 Message: First of all: Thank you very much for searching. I tried to reproduce the error and I think i found a hint: Indeed the problem does not occur if there is only a normal value in key column. So my example was not sufficient, sorry for that. But if there is a newline character at the end and try to update we have a problem. I put the value 'mypc<newline>' into key column. Hidden field is now <input type="hidden" name="key" value="a:1:{s:6:"pcname";s:5:"mypc ";}" /> When we click save button we get: Message in web interface: SQL error: FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »spss_pkey« (double key value violates Unique constraint) In statement: UPDATE "public"."spss" SET "pcname"='mypc ', "einrichtungskennzeichen"='RZS ', "nummer"='69', "lizenz_beginn"='2012-01-05', "lizenz_ende"='2012-01-06', "spss_version"='20 ', "win_version"='- ', "rechnungsdatum"=NULL, "bemerkung"='' The same error message can be found within postgres logfile. The where clause is missing in update statement. We also find errors in web server's log file complaining about errors in unserialize function and invalid argument for foreach. I will post these separately in a small file. Sorry, i had not noticed that the row which led to the error had the newline character in the key column, while my example had not. I should have checked my bug report better before posting. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:26 Message: According to the PHP doc, unserialize should rise a E_NOTICE when it fails. Could you check your httpd log files or try to setup your php.ini to catch it ? see: http://php.net/unserialize thank you. ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-05 07:24 Message: So I tried to reproduce the bug without success (PostgreSQL 9.1.2, PPA 5.0.3, PHP 5.3.3, lighttpd 1.4.28 and FF 8.0). I used a single column table, with type 'text' and a PK on it. Update on a row went fine. «It seems that the replacement of '"' with '"' » This is normal, we must escape the serialized array before putting it in a HTML attribute. If quotes were not escaped, we would break the html code. However, data are sent non-escaped by any browser (usually). Do you have any other information abou tthis bug which would lead me to the real bug ? ---------------------------------------------------------------------- Comment By: J.Guillaume (ioguix) de Rorthais (ioguix) Date: 2012-01-03 03:22 Message: Hello, This is a pretty ugly bug, I don't understand why we never found/heard about it :( I'll work on this tonight and try to fix this as soon as possible. Thank you for this report ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3468882&group_id=37132 |
|
From: Jehan-Guillaume (i. de R. <io...@fr...> - 2012-02-27 21:40:17
|
Hello, On 27/02/2012 21:44, jo...@me... wrote: > phpPgAdmin ver. > 4.2.3 (PHP 5.2.9) This is not the latest version of phpPgAdmin > Comments: > Hi There, > > I am having problems exporting my database. Every time i try export the database it is 0 kilobytes. When my database is 27mb.... > > what could the problem be? Your urgency on this will be appreciated. Make sure you set up your path to pg_dump and/or pg_dumpall correctly in your "conf/config.inc.php". Please upgrade your version of phpPgAdmin as you might hit an old bug as well. > > Thank you |
|
From: <jo...@me...> - 2012-02-27 20:45:05
|
The following data was submitted on 2012/02/27 20:44. ====== E-mail ====== Name John Burk PostgreSQL ver. 8.4.9 phpPgAdmin ver. 4.2.3 (PHP 5.2.9) Comments Hi There, I am having problems exporting my database. Every time i try export the database it is 0 kilobytes. When my database is 27mb.... what could the problem be? Your urgency on this will be appreciated. Thank you |
|
From: Jehan-Guillaume (i. de R. <io...@fr...> - 2012-02-27 18:27:01
|
On 27/02/2012 17:01, ma...@gm... wrote: > Hello, Hello, > I really love phpPgAdmin and for the company i work with use it a lot! Thank you ! > I couldn't help to notice there isn't any donation button. Is there a means by which we can make a donation of some sort? As far as I know, no. You could make a donation to the PostgreSQL group itself though, see http://www.postgresql.org/about/donate/ As instance, donations to the PostgreSQL group helped last year to sponsors some students that contributed to PostgreSQL and some satellites projects (including phpPgAdmin) to attend some PostgreSQL related conferences. > [...] > > hence, the per server config is removed from the main config file. This way version control and distributed configuration management (like with puppet) is much easier for us. Splitting configuration files might be a good idea yes. However, I have two concerns: * how confusing it could be for users to have multiple configuration files ? Today, some of them barely read (when they read it) the only configuration file... * security issue. If including any kind of PHP files from this folder, it might lead to a security issue where any kind PHP of code might be executed. The second point could be solved by using ini files instead of plain PHP. > Is there a change this minor change will make it to the next release? Considering the security issue, no, it will not be included in the next release. However, if moving to ini file, yes, we could probably consider it it there's no other issue. We just need to rethink the whole conf file though... Could you please post a feature request on sf.net if possible ? http://sourceforge.net/tracker/?group_id=37132&atid=418983 > Please keep up the good work! Thank you for your support and suggestion ! > Kind regards, > > Martijn de Groot |
|
From: <ma...@gm...> - 2012-02-27 16:01:21
|
The following data was submitted on 2012/02/27 16:01.
====== E-mail ======
Name
Martijn de Groot
PostgreSQL ver.
-
phpPgAdmin ver.
5.03
Comments
Hello,
I really love phpPgAdmin and for the company i work with use it a lot! I couldn't help to notice there isn't any donation button. Is there a means by which we can make a donation of some sort?
Also please let me make the following suggestion. For my company it was needed to get the per server config in seperated files. So i edited conf/config.inc.php and removed all the $conf['servers'][0][vars] references and replaced it with:
$confdir="/var/www/html/phpPgAdmin/conf/conf.d/";
$snum=0;
foreach (glob($confdir . "*.php") as $filename) {
include($filename);
$snum++;
}
In the conf.d directory i created a file 0000default.php with the following code:
$conf['servers'][$snum]['desc'] = 'try-logger';
$conf['servers'][$snum]['host'] = '';
$conf['servers'][$snum]['port'] = 5432;
$conf['servers'][$snum]['sslmode'] = 'allow';
$conf['servers'][$snum]['defaultdb'] = 'template1';
$conf['servers'][$snum]['pg_dump_path'] = '/usr/bin/pg_dump';
$conf['servers'][$snum]['pg_dumpall_path'] = '/usr/bin/pg_dumpall';
$conf['servers'][$snum]['slony_support'] = false;
$conf['servers'][$snum]['slony_sql'] = '/usr/share/pgsql';
hence, the per server config is removed from the main config file. This way version control and distributed configuration management (like with puppet) is much easier for us. Is there a change this minor change will make it to the next release?
Please keep up the good work!
Kind regards,
Martijn de Groot
|
|
From: SourceForge.net <no...@so...> - 2012-02-27 08:42:45
|
The following forum message was posted by scharon at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4801691: In fact, I just didn't have enough time to work on it... But, somehow, the problem ceased to occur. I don't know why (which is a bit annoying). It wasn't an antivirus problem (no antivirus on this server) and all permissions were correctly set. Juste for information: The server is a Window Server Entreprise 2008 (64bits), with Postgres 8.1.4 Indeed, I made a vacuum command on some tables (for other purposes), but I do not know if it is it that resolved the problem. Thanks to all. PS: And I apologize for my approximate English ! |
|
From: SourceForge.net <no...@so...> - 2012-02-26 12:15:14
|
The following forum message was posted by feqma at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/4801691: I am not sure how this user made out, but I found this error after making some database drops and adds to provide PostGIS module upgrades. I was able to clear this issue with a vacuum of the databases. |
|
From: SourceForge.net <no...@so...> - 2012-02-15 05:06:05
|
The following forum message was posted by radknee at http://sourceforge.net/projects/phppgadmin/forums/forum/115884/topic/5020603: Had it setup previously so my clients could execute a report or view, and then export the data to file to load into local spreadsheet. Wondering if this feature was removed from current version? Using version 5.03. |
|
From: SourceForge.net <no...@so...> - 2012-02-07 17:22:59
|
Bugs item #3485423, was opened at 2012-02-07 09:22 Message generated for change (Settings changed) made by inull You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3485423&group_id=37132 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Functions Group: 5.0.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: null (inull) Assigned to: Christopher Kings-Lynne (chriskl) >Summary: Functions returning the 'table' type are handled incorrectly Initial Comment: If the function is created as returning the 'table' type, phpPgAdmin treats it as returning the 'setof record'. And when I try to modify the function I get the 'cannot change return type of existing function' error because it tries to alter it with a wrong return type. ex CREATE OR REPLACE FUNCTION "public"."getvalues" (int p1) RETURNS TABLE (val1 integer, val2 integer) AS .... ERROR: cannot change return type of existing function DETAIL: Row type defined by OUT parameters is different. HINT: Use DROP FUNCTION first. in CREATE OR REPLACE FUNCTION "public"."getvalues" (int p1) RETURNS SETOF record AS .... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=418980&aid=3485423&group_id=37132 |
667 messages has been excluded from this view by a project administrator.
