phplib-trackers Mailing List for PHPLIB (Page 23)
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-trackers — List for monitoring the phplib SourceForge trackers.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(91) |
Sep
(12) |
Oct
(26) |
Nov
(16) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(37) |
Feb
(22) |
Mar
(39) |
Apr
(74) |
May
(14) |
Jun
(17) |
Jul
(81) |
Aug
(32) |
Sep
(28) |
Oct
(18) |
Nov
(8) |
Dec
(6) |
| 2003 |
Jan
(6) |
Feb
(11) |
Mar
(5) |
Apr
(4) |
May
(6) |
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
(8) |
Oct
(4) |
Nov
(2) |
Dec
(2) |
| 2004 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
(8) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(41) |
Nov
|
Dec
(78) |
|
From: <no...@so...> - 2001-08-30 07:48:47
|
Bugs item #456634, was opened at 2001-08-29 12:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=456634&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Duplicate >Priority: 1 Submitted By: Purodha B Blissenbach (purodha) >Assigned to: Richard Archer (richardarcher) Summary: DOS line ends in file ct_dbm.inc , v7.2 Initial Comment: In the version 7.2 download, file ct_dbm.inc has ^M characters just before each line ends (DOS Line ends) No known impact, as the file is not being used in my environment. purodha <pu...@us...> ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-30 00:48 Message: Logged In: YES user_id=279311 Duplicate of bug ID 450387. The problem is cosmetic only as far as I can tell, but it will be fixed shortly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=456634&group_id=31885 |
|
From: <no...@so...> - 2001-08-29 19:26:44
|
Bugs item #456634, was opened at 2001-08-29 12:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=456634&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Purodha B Blissenbach (purodha) Assigned to: Nobody/Anonymous (nobody) Summary: DOS line ends in file ct_dbm.inc , v7.2 Initial Comment: In the version 7.2 download, file ct_dbm.inc has ^M characters just before each line ends (DOS Line ends) No known impact, as the file is not being used in my environment. purodha <pu...@us...> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=456634&group_id=31885 |
|
From: <no...@so...> - 2001-08-29 07:32:43
|
Bugs item #450712, was opened at 2001-08-13 23:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450712&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Richard Archer (richardarcher) Summary: cross site scripting attack Initial Comment: reposted from mailing list At 2:06 PM +0100 28/2/01, Daniel Naber wrote: >Hi, > >with PHP lib 7.2b (and it seems no different in CVS) there's a cross site >scripting attack possible. > >Anyone can use such a link to break out of the input field: >http://server/home.php?username=X">YYY >(home.php needs to be a page that's protected with my_Auth) > >This is a problem since any code, escpecially javascript code, can then be >placed on the page. This can be used to get a user's password. > >More general information is here: >http://www.cert.org/advisories/CA-2000-02.html > >The attached patch is supposed to fix the problem for crloginform.ihtml. >It would be great if someone with CVS write access could check + apply it >(also for at least the other login form file. I don't know about other >places, since I'm not so familiar with PHP lib). > >Regards > Daniel > >-- >Daniel Naber, Paul-Gerhardt-Str. 2, 33332 Guetersloh, Germany >Tel. 05241-59371, Mobil 0170-4819674 ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-29 00:32 Message: Logged In: YES user_id=279311 Modifications have been made in both the -devel and -stable trees to address this issue: From the commit log: Changes to prevent cross-site scripting attacks: Encode dangerous characters in session URLs Pass user input through htmlentities before output Should fix it, I believe. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-28 01:28 Message: Logged In: YES user_id=279311 I have confirmed this bug. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-15 04:02 Message: Logged In: YES user_id=279311 OK. I've read up on the vulnerability and it looks to me as if it is only relevant if the inserted data is being displayed on a page presented to an unsuspecting user. If this is the case, this is a non-issue, as the data entered here can only ever be shown to the person who entered it. And there's no point trying to capture your own password. I must admit, I find this vulnerability rather confusing so I might have this wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450712&group_id=31885 |
|
From: <no...@so...> - 2001-08-28 08:28:10
|
Bugs item #450712, was opened at 2001-08-13 23:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450712&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) >Assigned to: Richard Archer (richardarcher) Summary: cross site scripting attack Initial Comment: reposted from mailing list At 2:06 PM +0100 28/2/01, Daniel Naber wrote: >Hi, > >with PHP lib 7.2b (and it seems no different in CVS) there's a cross site >scripting attack possible. > >Anyone can use such a link to break out of the input field: >http://server/home.php?username=X">YYY >(home.php needs to be a page that's protected with my_Auth) > >This is a problem since any code, escpecially javascript code, can then be >placed on the page. This can be used to get a user's password. > >More general information is here: >http://www.cert.org/advisories/CA-2000-02.html > >The attached patch is supposed to fix the problem for crloginform.ihtml. >It would be great if someone with CVS write access could check + apply it >(also for at least the other login form file. I don't know about other >places, since I'm not so familiar with PHP lib). > >Regards > Daniel > >-- >Daniel Naber, Paul-Gerhardt-Str. 2, 33332 Guetersloh, Germany >Tel. 05241-59371, Mobil 0170-4819674 ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-28 01:28 Message: Logged In: YES user_id=279311 I have confirmed this bug. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-15 04:02 Message: Logged In: YES user_id=279311 OK. I've read up on the vulnerability and it looks to me as if it is only relevant if the inserted data is being displayed on a page presented to an unsuspecting user. If this is the case, this is a non-issue, as the data entered here can only ever be shown to the person who entered it. And there's no point trying to capture your own password. I must admit, I find this vulnerability rather confusing so I might have this wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450712&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 18:28:55
|
Patches item #455851, was opened at 2001-08-27 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 Category: None Group: None >Status: Deleted Resolution: None >Priority: 1 Submitted By: Bob Gorman (rag56) Assigned to: Nobody/Anonymous (nobody) Summary: Failures with register_globals off Initial Comment: PHPLib should work when register_globals is off. See bug #446455. Many PHPLib scripts depend on PHP automatically registering variables into the global name space. If we set register_globals to off via .htaccess (or another method) for security reasons then portions of PHPLib fail to function properly. In bug #446455 I document a short-term work around. It would be better if the PHPLib scripts would work properly regardless to the setting of register_globals. In specific PHPLib should use the HTTP_*_VARS to gather the values of variables passed from the client. For example: In function auth_validatelogin() we see: global $username, $password; This should be re-coded as: global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; Or even better is: $username = isset($HTTP_POST_VARS ["username"]) ? $HTTP_POST_VARS["username"] : ""; $password = isset($HTTP_POST_VARS ["password"]) ? $HTTP_POST_VARS["password"] : ""; Use of isset() is added to prevent errors when using E_NOTICE. The script session.inc is coded pretty well. Others are not. I think this is important for the long-term viablility of PHPLib. ---------------------------------------------------------------------- >Comment By: Bob Gorman (rag56) Date: 2001-08-27 11:28 Message: Logged In: YES user_id=285806 I meant to add this under Feature Requests, this is not a patch. Well, not yet anyhow... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 18:27:09
|
Feature Requests item #455856, was opened at 2001-08-27 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403614&aid=455856&group_id=31885 Category: None Group: Next Release (example) Status: Open >Priority: 7 Submitted By: Bob Gorman (rag56) Assigned to: Nobody/Anonymous (nobody) Summary: PHPLib fails with register_globals off Initial Comment: PHPLib should work when register_globals is off. See bug #446455. (Also submitted accidently as patch #455851, oops). Many PHPLib scripts depend on PHP automatically registering variables into the global name space. If we set register_globals to off via .htaccess (or another method) for security reasons then portions of PHPLib fail to function properly. In bug #446455 I document a short-term work around. It would be better if the PHPLib scripts would work properly regardless to the setting of register_globals. In specific PHPLib should use the HTTP_*_VARS to gather the values of variables passed from the client. For example: In function auth_validatelogin() we see: global $username, $password; This should be re-coded as: global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; Or even better is: $username = isset($HTTP_POST_VARS ["username"]) ? $HTTP_POST_VARS["username"] : ""; $password = isset($HTTP_POST_VARS ["password"]) ? $HTTP_POST_VARS["password"] : ""; Use of isset() is added to prevent errors when using E_NOTICE. The script session.inc is coded pretty well. Others are not. I think this is important for the long-term viablility of PHPLib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403614&aid=455856&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 18:26:32
|
Feature Requests item #455856, was opened at 2001-08-27 11:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403614&aid=455856&group_id=31885 Category: None Group: Next Release (example) Status: Open Priority: 5 Submitted By: Bob Gorman (rag56) Assigned to: Nobody/Anonymous (nobody) Summary: PHPLib fails with register_globals off Initial Comment: PHPLib should work when register_globals is off. See bug #446455. (Also submitted accidently as patch #455851, oops). Many PHPLib scripts depend on PHP automatically registering variables into the global name space. If we set register_globals to off via .htaccess (or another method) for security reasons then portions of PHPLib fail to function properly. In bug #446455 I document a short-term work around. It would be better if the PHPLib scripts would work properly regardless to the setting of register_globals. In specific PHPLib should use the HTTP_*_VARS to gather the values of variables passed from the client. For example: In function auth_validatelogin() we see: global $username, $password; This should be re-coded as: global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; Or even better is: $username = isset($HTTP_POST_VARS ["username"]) ? $HTTP_POST_VARS["username"] : ""; $password = isset($HTTP_POST_VARS ["password"]) ? $HTTP_POST_VARS["password"] : ""; Use of isset() is added to prevent errors when using E_NOTICE. The script session.inc is coded pretty well. Others are not. I think this is important for the long-term viablility of PHPLib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403614&aid=455856&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 18:19:57
|
Patches item #455851, was opened at 2001-08-27 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Bob Gorman (rag56) Assigned to: Nobody/Anonymous (nobody) Summary: Failures with register_globals off Initial Comment: PHPLib should work when register_globals is off. See bug #446455. Many PHPLib scripts depend on PHP automatically registering variables into the global name space. If we set register_globals to off via .htaccess (or another method) for security reasons then portions of PHPLib fail to function properly. In bug #446455 I document a short-term work around. It would be better if the PHPLib scripts would work properly regardless to the setting of register_globals. In specific PHPLib should use the HTTP_*_VARS to gather the values of variables passed from the client. For example: In function auth_validatelogin() we see: global $username, $password; This should be re-coded as: global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; Or even better is: $username = isset($HTTP_POST_VARS ["username"]) ? $HTTP_POST_VARS["username"] : ""; $password = isset($HTTP_POST_VARS ["password"]) ? $HTTP_POST_VARS["password"] : ""; Use of isset() is added to prevent errors when using E_NOTICE. The script session.inc is coded pretty well. Others are not. I think this is important for the long-term viablility of PHPLib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 18:16:40
|
Patches item #455851, was opened at 2001-08-27 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Gorman (rag56) Assigned to: Nobody/Anonymous (nobody) Summary: Failures with register_globals off Initial Comment: PHPLib should work when register_globals is off. See bug #446455. Many PHPLib scripts depend on PHP automatically registering variables into the global name space. If we set register_globals to off via .htaccess (or another method) for security reasons then portions of PHPLib fail to function properly. In bug #446455 I document a short-term work around. It would be better if the PHPLib scripts would work properly regardless to the setting of register_globals. In specific PHPLib should use the HTTP_*_VARS to gather the values of variables passed from the client. For example: In function auth_validatelogin() we see: global $username, $password; This should be re-coded as: global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; Or even better is: $username = isset($HTTP_POST_VARS ["username"]) ? $HTTP_POST_VARS["username"] : ""; $password = isset($HTTP_POST_VARS ["password"]) ? $HTTP_POST_VARS["password"] : ""; Use of isset() is added to prevent errors when using E_NOTICE. The script session.inc is coded pretty well. Others are not. I think this is important for the long-term viablility of PHPLib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=455851&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 14:33:05
|
Bugs item #446455, was opened at 2001-07-31 09:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=446455&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Failures with register_globals off Initial Comment: PHPLib should work when register_globals is off. Below is a work around, I added this to prepend.php3 // If we set "phpflags register_globals off" in .htaccess then the variable name // space can not be spammed by rogue clients. As a side effect certain PHPLib // scripts fail. Poor engineering on thier part. Below are the variables that // are need, that I have tracked down so far. These can be retrieved via the // HTTP_SERVER_VARS array. I may have missed some. HTTPS is suspect because I // don't have a secure server to test against. Here I make my own versions // globaly available from the HTTP_SERVER_VARS array $HTTPS = $HTTP_SERVER_VARS["HTTPS"]; $HTTP_HOST = $HTTP_SERVER_VARS["HTTP_HOST"]; $HTTP_REFERER = $HTTP_SERVER_VARS["HTTP_REFERER"]; $HTTP_USER_AGENT = $HTTP_SERVER_VARS ["HTTP_USER_AGENT"]; $PHP_SELF = $HTTP_SERVER_VARS["PHP_SELF"]; $QUERY_STRING = $HTTP_SERVER_VARS["QUERY_STRING"]; $REMOTE_ADDR = $HTTP_SERVER_VARS["REMOTE_ADDR"]; ---------------------------------------------------------------------- Comment By: Bob Gorman (rag56) Date: 2001-08-27 07:33 Message: Logged In: YES user_id=285806 richardarcher said: > This is a very effective short term fix, but wouldn't > it be better in the long term to change all the > references to these variables to use the > HTTP_(SERVER|GET|POST)_VARS arrays? Yes! Can we get this added into the queue for future enhancements? As an example of good coding; session.inc does a nice job working with HTTP_*_VARS. That script gets variables from the HTTP_*_VARS arrays and ALSO checks them with an isset() function call. That is reduces un-needed output when E_NOTICE is set for error reporting. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-12 02:30 Message: Logged In: YES user_id=279311 This is a very effective short term fix, but wouldn't it be better in the long term to change all the references to these variables to use the HTTP_(SERVER|GET|POST)_VARS arrays? If the user prefers to have register_globals off it's a little rude of us to define all these globals :) It certainly runs into the problem of overlapping name-space. ---------------------------------------------------------------------- Comment By: Bob Gorman (rag56) Date: 2001-08-02 07:23 Message: Logged In: YES user_id=285806 I will code up fixes for this issue and submit them if you want me to. JLMK. ---------------------------------------------------------------------- Comment By: Bob Gorman (rag56) Date: 2001-08-02 07:21 Message: Logged In: YES user_id=285806 This also has ramifactions in local.inc. In Example_Auth the function auth_validatelogin() needs to declare and extract $username and $password from $HTTP_POST_VARS. For example: function auth_validatelogin() { global $username, $password; global $HTTP_POST_VARS; $username = $HTTP_POST_VARS["username"]; $password = $HTTP_POST_VARS["password"]; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=446455&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 10:17:00
|
Patches item #450738, was opened at 2001-08-14 02:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450738&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Richard Archer (richardarcher) >Assigned to: Richard Archer (richardarcher) Summary: ct_ldap.inc Initial Comment: reposted from mailing list From: "Dimitry Gashinsky" <Di...@ma...> To: <kk...@ne...>, <sa...@sc...> Subject: ct_ldap.inc Date: Wed, 4 Apr 2001 17:39:55 -0400 Hi Kristian, I noticed that ct_ldap.inc container class was broken. I fixed it and it works on my machine with horde and imp. I am not sure if I broke anything else. I thought it my worth something to others. Regards, Dima ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-27 03:17 Message: Logged In: YES user_id=279311 Committed these changes completely untested. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450738&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 08:33:01
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Archer (richardarcher) >Assigned to: Richard Archer (richardarcher) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-27 01:32 Message: Logged In: YES user_id=279311 This has been fixed, but somewhat more elegantly, I hope. ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-24 00:06 Message: Logged In: YES user_id=295363 Looks good to me. :-) (Hope this doesn't turn up twice. Had some browsertrouble) ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-23 23:57 Message: Logged In: YES user_id=295363 Looks good to me. :-) ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-23 14:52 Message: Logged In: YES user_id=279311 Attached a fixed db_sql.inc file from Guillaume ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 22:21 Message: Logged In: YES user_id=295363 I agree that deriving a new db class would be the correct way to go, but I also think that phplib should be able to handle a user which manually switches database. AFAIR there is also an issue with PHP/MySQL being "confused" when your having two db-classes with two different databases if you use the same username/password combination for those two. I am not sure if this is related to using mysql_pconnect as I have not tried it myself. Should be easy to test though... ---------------------------------------------------------------------- Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 08:31:38
|
Patches item #450758, was opened at 2001-08-14 04:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Richard Archer (richardarcher) Summary: Support multiple database Initial Comment: To support multiple database add if (!@mysql_select_db($this->Database,$this->Link_ID)) { $this->halt("cannot use database ".$this->Database); } before each mysql_query() in db_mysql.inc ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-27 01:31 Message: Logged In: YES user_id=279311 Done, but not using the method advised :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885 |
|
From: <no...@so...> - 2001-08-27 07:44:25
|
Bugs item #450727, was opened at 2001-08-14 01:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450727&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Archer (richardarcher) >Assigned to: Richard Archer (richardarcher) Summary: problems and solutions for db_odbc Initial Comment: reposted from mailing list See attached file... two postings discussing ODBC driver problems that seem to be unresolved in the current classes. I have access to an ODBC machine, so I might have a stab at this at some stage... but anyone else is welcome to them :) ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-27 00:44 Message: Logged In: YES user_id=279311 I have made extensive changes to both the -devel and -stable ODBC classes. -stable should have the outright bugs fixed. -devel also has new code to implement pseudo-locking and sequence numbers. Very untested. Please post any further bugs in a new bug report. This "bug" is too wide ranging and is now closed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450727&group_id=31885 |
|
From: <no...@so...> - 2001-08-26 04:56:53
|
Bugs item #450648, was opened at 2001-08-13 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450648&group_id=31885 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Richard Archer (richardarcher) Summary: Warning: Call-time pass-by-reference Initial Comment: Repost of a "bug" posted to NetUSE bugs forum. This one will take a little investigating. -- Warning: Call-time pass-by-reference has been depr [66] by Roxy web...@ya... on Thursday, July 12 @12:31AM Are there any plans to update PHPLIB to be compatible with PHP4.04? It is the defacto library, however beyond PHP 4 it gets a little hairy. ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-25 21:56 Message: Logged In: YES user_id=279311 Fixed it again :) ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-20 18:19 Message: Logged In: YES user_id=279311 Re-opening this bug. Looks like all the calls to serialize have to have the ampersands removed from the $str arg. To test this problem, put this in a .htaccess file: php_value allow_call_time_pass_reference off ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-18 01:30 Message: Logged In: YES user_id=279311 Fixed in my working copy and will be committed soon. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-13 18:27 Message: Logged In: YES user_id=279311 In the -devel tree, unsup/phplib-4/(session4.inc|user4.inc) have the same problem. Isn't this whole directory (unsup/phplib-4) obsolete? Isn't Maxim's session4.inc "the one". ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-13 17:46 Message: Logged In: YES user_id=279311 The API description of session.inc/Session->serialize() reads: serialize($prefix, &$str) but the function is declared: function serialize($prefix, $str) { All calls I can find to this function pass the variable by reference, so there shouldn't be any problems changing the function declaration to ...&$str. This is how it is in the -devel tree. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450648&group_id=31885 |
|
From: <no...@so...> - 2001-08-26 04:56:21
|
Bugs item #450640, was opened at 2001-08-13 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450640&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Richard Archer (richardarcher) >Assigned to: Richard Archer (richardarcher) Summary: Typo in OOHForm.inc Initial Comment: Nathan's bug report from the NetUSE bugs forum line 278: if (true == $falg_nametranslation) should be if (true == $flag_nametranslation) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450640&group_id=31885 |
|
From: <no...@so...> - 2001-08-24 07:06:57
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-24 00:06 Message: Logged In: YES user_id=295363 Looks good to me. :-) (Hope this doesn't turn up twice. Had some browsertrouble) ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-23 23:57 Message: Logged In: YES user_id=295363 Looks good to me. :-) ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-23 14:52 Message: Logged In: YES user_id=279311 Attached a fixed db_sql.inc file from Guillaume ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 22:21 Message: Logged In: YES user_id=295363 I agree that deriving a new db class would be the correct way to go, but I also think that phplib should be able to handle a user which manually switches database. AFAIR there is also an issue with PHP/MySQL being "confused" when your having two db-classes with two different databases if you use the same username/password combination for those two. I am not sure if this is related to using mysql_pconnect as I have not tried it myself. Should be easy to test though... ---------------------------------------------------------------------- Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-24 06:57:10
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-23 23:57 Message: Logged In: YES user_id=295363 Looks good to me. :-) ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2001-08-23 14:52 Message: Logged In: YES user_id=279311 Attached a fixed db_sql.inc file from Guillaume ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 22:21 Message: Logged In: YES user_id=295363 I agree that deriving a new db class would be the correct way to go, but I also think that phplib should be able to handle a user which manually switches database. AFAIR there is also an issue with PHP/MySQL being "confused" when your having two db-classes with two different databases if you use the same username/password combination for those two. I am not sure if this is related to using mysql_pconnect as I have not tried it myself. Should be easy to test though... ---------------------------------------------------------------------- Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-23 21:52:12
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2001-08-23 14:52 Message: Logged In: YES user_id=279311 Attached a fixed db_sql.inc file from Guillaume ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 22:21 Message: Logged In: YES user_id=295363 I agree that deriving a new db class would be the correct way to go, but I also think that phplib should be able to handle a user which manually switches database. AFAIR there is also an issue with PHP/MySQL being "confused" when your having two db-classes with two different databases if you use the same username/password combination for those two. I am not sure if this is related to using mysql_pconnect as I have not tried it myself. Should be easy to test though... ---------------------------------------------------------------------- Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-22 05:21:04
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 22:21 Message: Logged In: YES user_id=295363 I agree that deriving a new db class would be the correct way to go, but I also think that phplib should be able to handle a user which manually switches database. AFAIR there is also an issue with PHP/MySQL being "confused" when your having two db-classes with two different databases if you use the same username/password combination for those two. I am not sure if this is related to using mysql_pconnect as I have not tried it myself. Should be easy to test though... ---------------------------------------------------------------------- Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-21 19:09:20
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- >Comment By: Giancarlo Pinerolo (pingus) Date: 2001-08-21 12:09 Message: Logged In: YES user_id=163488 But shouldn't one be supposed to derive a new db class if using a different database? This is the correct way, I think. One class, one db. Two db? Two subclasses. Giancarlo ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-21 17:59:00
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:58 Message: Logged In: YES user_id=295363 As I see it we have two options here: 1) In page_close change the database back to the original. This isn't "nice" as it's a rather nasty side-effect. On the other hand page_close is usually called in the end of a script and therefore it usually wouldn't matter if we change the database. 2) In CT_SQL.inc we could fully qualify the tablenames with "database.tablename" instead of "tablename". I guess this would also solve the problem? I guess option 2 is the "cleanest" but I might have missed something... ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-21 17:42:56
|
Bugs item #450642, was opened at 2001-08-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Nobody/Anonymous (nobody) Summary: db_mysql.inc loses database Initial Comment: Nathan's bug report from the NetUSE bugs forum. Sorry about the whacked formatting... it didn't copy/paste well.-- Problem: When using phplib with mysql, phplib sets the default database. If the application uses another database, then phplib fails on page_close(); Fix: the following diff db_mysql.inc.new db_mysql.inc.old show the changes that allow phplib to access the database defined in local.inc independently of what the application uses for a database. This problem probably on show up if the user/pass is the same on both databases because mysql reuses the connection handle. This fix avoids the problem. diff db_mysql.inc db_mysql.inc.save 80,83c80,83 < # if (!@mysql_select_db($Database,$this->Link_ID)) { < # $this->halt("cannot use database ".$this->Database); < # return 0; < # } --- > if (!@mysql_select_db($Database,$this->Link_ID)) { > $this->halt("cannot use database ".$this->Database); > return 0; > } 117c117 < $this->Query_ID = @mysql_db_query($this->Database, $Query_String,$this->Link_ID); --- > $this->Query_ID = @mysql_query($Query_String,$this->Link_ID); 185c185 < $res = @mysql_db_query($this->Database, $query, $this->Link_ID); --- > $res = @mysql_query($query, $this->Link_ID); 196c196 < $res = @mysql_query("unlock tables", $this->Link_ID); # unrelated fix --- > $res = @mysql_query("unlock tables"); 244c244 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 254c254 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); 263c263 < $id = @mysql_db_query($this->Database, $q, $this->Link_ID); --- > $id = @mysql_query($q, $this->Link_ID); ---------------------------------------------------------------------- Comment By: Martin Larsen (mlarsen) Date: 2001-08-21 10:42 Message: Logged In: YES user_id=295363 For some reason unknow to me mysql_db_query is marked deprecated since PHP 4.0.6. The manual suggest using mysql_use_db() and mysql_query() instead but in that case we seems to miss a mysql_get_current_db() function. It wouldn't be "nice" to just switch the database with mysql_use_db() without setting it back but I can't see any way for us to know which database the user switched to. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=450642&group_id=31885 |
|
From: <no...@so...> - 2001-08-21 12:51:27
|
Bugs item #452346, was opened at 2001-08-17 20:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=452346&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guillaume Desclaux (gdesclaux) Assigned to: Richard Archer (richardarcher) Summary: DB_Generic_Sql not defined... Initial Comment: Hi, In phplib/php-lib/php/db/db_mysql and in phplib/php- lib/php/db/mysql/db_mysql : DB_MySQL_Sql extends DB_Generic_Sql BUT : where is defined this DB_Generic_Sql ??? Moreover : in phplib/php-lib/php/prepend.php3 : require($_PHPLIB["libdir"] . "auth/auth.inc"); should be replace by : require($_PHPLIB["libdir"] . "auth/auth" . (($_PHPLIB["version"] == "4") ? "4" : "") // use user4.inc if PHP4 . ".inc"); And finally... require($_PHPLIB["libdir"] . "local.inc"); should be replace by : require($_PHPLIB["libdir"] . "local" . (($_PHPLIB["version"] == "4") ? "4" : "") // use user4.inc if PHP4 . ".inc"); Guillaume ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=452346&group_id=31885 |
|
From: <no...@so...> - 2001-08-21 12:49:24
|
Bugs item #453089, was opened at 2001-08-19 15:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=453089&group_id=31885 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Archer (richardarcher) Assigned to: Richard Archer (richardarcher) Summary: devel mysql/db_sql.inc missing functions Initial Comment: At 4:09 PM +0200 19/8/01, Guillaume Desclaux wrote: >Hi > >In php-lib/php/db/mysql/db_sql.inc > > /* public: shorthand notation */ > function nf() { > return $this->num_rows(); > } > > function np() { > print $this->num_rows(); > } > > function f($Name) { > return $this->Record[$Name]; > } > > function p($Name) { > print $this->Record[$Name]; > } > >are missing... > >Guillaume > ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=453089&group_id=31885 |
115 messages has been excluded from this view by a project administrator.
