gubed-devel Mailing List for Gubed PHP Debugger (Page 4)
Status: Beta
Brought to you by:
mccabe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(4) |
May
(16) |
Jun
(44) |
Jul
(27) |
Aug
(1) |
Sep
|
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brett S. <tec...@se...> - 2005-06-25 23:13:09
|
After reading both posts, I can see the difficulities of both security and implementation. I agree that what ever is done, must be secure or gubed will not be used. As a thought, we could optionally restrict the DebugServer to 'localhost'. When this restriction is in place, any individuals needing to debug need to either log on and start the debugger locally or run secure shell as previously described to create a local port to bring the session back to their local system. This would give the local system administrator strict control over who could debug, but not what they could debug. On this second point, seems to me that StartSession.php (soft-link or real) must exist at or below the directory to be debugged, while this doesn't control who can debug what, it does limit what can be debugged control by existing access to the host's directory structure. I favor allowing specification of ports on the url for maximum flexibility, presuming the security issue is resolved. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Aaron M. <wmc...@ho...> - 2005-06-25 17:21:48
|
Hello, You're right Linus. My change assumed that the debugger would always be invoked via StartSession.php. I'd be happy to look into it and make the necessary updates to Gubed.php, etc. Here's my two cents on the multi-user stuff. I think allowing the HTTP request to contain the client and port could be a major security risk. This risk could of course be addressed by sysadmins with .htaccess files, etc. but do we really want Gubed to be such a security vulnerability upon installation to a public server? I understand that the presence of the devel directory is a security risk today, but otherwise, Gubed will only send server content to the client that is specified in the localsettings file (correct me if I'm wrong here). Requiring the client and port to be in the localsettings file then means that the user must be able to specify the localsettings file that should be used for the current debug session. I agree that it is kind of a pain to specify a full file path and to create a localsettings file instance for every debug session, but I'm just not very comfortable with the alternative. If it is decided to allow the user to specify the client and port in the request, then I think I like the idea of specifying the user in the request and then looking for say a .gubed file (renamed version of localsettings) in the user's home directory. A problem I see with grabbing the user from the URL (~user) is that scripts within the user's directory could only be debugged by this user. This would not be ideal in a situation where trusted developers may need to help debug each other's scripts. The use of .htaccess files, possibly in combination with php safe mode, would be my preference for preventing users from debugging each other's scripts in an untrusted multi-user environment. Thanks, Aaron McDonald ---------------------------------------------------------------------------------------------------------------------------- Hello! A good idea about using ssh instead of the proxy, that should work much more transparent! Since ssh exists for a number of platforms, I think this means that we can completely disregard the proxy in this discussion since ssh's forwarding makes it look like a local network to Gubed. (in any case, also the proxy should make it look like a local network to Gubed) Adding a port as a request variable to StartSession shouldn't be too much of a problem, Aaron has already added the possibility to specify different localsetting files. The problem with Aarons implementation, that I realized this morning, is that it only works when using StartSession (correct me if I'm wrong Aa). Sometimes it's not possible to use StartSession for Gubed (for example when javascripts are used to execute php scripts), instead you have to manually include Gubed.php in your script. Some of Aarons changes has to be moved to other files to make this possible. Before we proceed with further changes though, I'd like to discuss the optimal way of specifying different users. * I'm toying with the idea of using a localsettingsfile from the users homedirectory automatically if it exists. So if Gubed sees a ~ in the request (or is this too apache-ish?), it would figure out the user home dir from the request and take localsettings.php from there. This would make it easy for the user to alter his/her settings and nothing would need to be specified on the request (exept the script). * Second way of specifying what settings you want to use is by specifying a certain username on the request. Then gubed would use localsettings_{$gbdUser}.php for settings and startsessionhistory_{$gbdUser}.txt as history file. The reason I'd like to have this is because I think it's easier to remember and specify a single name like 'linus' rather than a complete path to a file. (is this a problem if the user uses different computers different days? I think not) * Third way would be to specify a localsettings filename in the request like in Aarons patch. * If no user or settingsfile was specified, the default (like now) is used. (Or should it first look for a file that's localsettings_{REMOTE_ADDR}.php to see if there is a special one for that host?) * Optionally you can override the host or port in whatever settingsfile was chosen by specifying host and port on in the request. This would only be needed if you were debugging several scripts simultaneously. Any comments on this? Is the above giving too many options and just making it harder rather than easier to know what to do? What about security - if you can specify debug host/port on the request will it be easier for a stranger to gain debug access to scripts? Or is this not Gubed's problem, but one of the sysadmin who installs Gubed on a public server? /Linus |
From: Linus M. <Li...@mc...> - 2005-06-25 11:19:58
|
Hello! A good idea about using ssh instead of the proxy, that should work much more transparent! Since ssh exists for a number of platforms, I think this means that we can completely disregard the proxy in this discussion since ssh's forwarding makes it look like a local network to Gubed. (in any case, also the proxy should make it look like a local network to Gubed) Adding a port as a request variable to StartSession shouldn't be too much of a problem, Aaron has already added the possibility to specify different localsetting files. The problem with Aarons implementation, that I realized this morning, is that it only works when using StartSession (correct me if I'm wrong Aa). Sometimes it's not possible to use StartSession for Gubed (for example when javascripts are used to execute php scripts), instead you have to manually include Gubed.php in your script. Some of Aarons changes has to be moved to other files to make this possible. Before we proceed with further changes though, I'd like to discuss the optimal way of specifying different users. * I'm toying with the idea of using a localsettingsfile from the users homedirectory automatically if it exists. So if Gubed sees a ~ in the request (or is this too apache-ish?), it would figure out the user home dir from the request and take localsettings.php from there. This would make it easy for the user to alter his/her settings and nothing would need to be specified on the request (exept the script). * Second way of specifying what settings you want to use is by specifying a certain username on the request. Then gubed would use localsettings_{$gbdUser}.php for settings and startsessionhistory_{$gbdUser}.txt as history file. The reason I'd like to have this is because I think it's easier to remember and specify a single name like 'linus' rather than a complete path to a file. (is this a problem if the user uses different computers different days? I think not) * Third way would be to specify a localsettings filename in the request like in Aarons patch. * If no user or settingsfile was specified, the default (like now) is used. (Or should it first look for a file that's localsettings_{REMOTE_ADDR}.php to see if there is a special one for that host?) * Optionally you can override the host or port in whatever settingsfile was chosen by specifying host and port on in the request. This would only be needed if you were debugging several scripts simultaneously. Any comments on this? Is the above giving too many options and just making it harder rather than easier to know what to do? What about security - if you can specify debug host/port on the request will it be easier for a stranger to gain debug access to scripts? Or is this not Gubed's problem, but one of the sysadmin who installs Gubed on a public server? /Linus |
From: Aaron M. <wmc...@ho...> - 2005-06-24 11:38:54
|
The multi-user mod has been checked into CVS. One issue that I now see with it is that users will be sharing the same history file. I think this would best be addressed by defining the history file in localsettings.php and then referencing this value in StartSession.php. Let me know if you find any issues. Thanks, Aaron McDonald |
From: Aaron M. <wmc...@ho...> - 2005-06-23 20:11:53
|
Brett, it doesn't sound like you're using the multi-user patch that I sent out a few weeks ago. This patch allows each user to define the client IP and port number. As far as I can tell from reading your post, this is essentially what you need and I created this mod after your initial inquiry on the subject. I have discovered that the patch I sent out can no longer be applied to Gubed CVS (I think it still works on 0.2 however) and I hope to get it into CVS as early as tonight. I'll send out a note when CVS has been updated. Thanks, Aaron ----------------------------------------------------------------------------------------------- I'm following up to previous posts, attempting to address similar/same issue. The environment I'm attempting to support is a Linux system with multiple developers, each working out of public_html in their home directories. Resolved so far, Gubed can be installed in a central location, then each user can create a soft-link to StartSession.php, i.e. "ln -s /usr/local/gubed/ServerScripts/StartSession.php StartSession.php". Then to debug any given script in that directory, simply prepend the string "StartSession.php?gbdScript=", i.e. StartSession.php?gbdScript=ScriptToDebug.php. Previously we had worked out changes to localsettings.php that were helpful: "$gbdDebugServer = $_SERVER['REMOTE_ADDR'];". This is a good change, and I'd advocate leaving it in, but the task is more complex. The rub is that StartSession.php 'calls back' the debugger. The server to call back is essentially resolved with the above change, but the specific port is an issue. Before moving on directly to the port, along the way I realized that using secure shell not only provides secure access to the sharedlinux system but removes the need for the gubed proxy and may resolve other issues, potentially the port issue. For instance, one could connect to a Linux server from any accessible point on the Internet with a command like: ssh -X -L 80:localhost:80 -R 8016:localhost:8016 sharedlinux.anywhere.net The "-L 80:localhost:80" allows a local browser to be started (on the initiating system) and browse to "http://localhost/~user" to reach the web server on the sharedlinux system. Under these conditions, when Gubed starts, with the above setting in localsettings.php, it believes is must contact localhost:8016 to reach the debugger, with with the "-R 8016:localhost:8016" this is exactly correct. Secure shell is arranging for the ports to be available. This is 95% of the way to my stated goal. The issue of course is that if multiple users try to do this, only one can be using port 8016 on sharedlinux. Unique ports can be allocated to each user and they can modify the above command, for instance if I was given port 8020, I'd use "-R 8016:localhost:8020" and port 8020 on the sharedlinux box would come back to port 8016 on my local system, which my debugger is waiting on. So the missing item, is how can we tell StartSession.php to use an alternate port? Ultimately I'd like to be able to specify it on the command line like: StartSession.php?gbdScript=ScriptToDebug.php&gbdDebugPort=8020 StartSession.php could be updated to allow a host and port to be specified in addition to the script to debug. Note that such a capability would also allow a given developer to run multiple debug sessions, if so desired. I looked thru the Gubed code (i.e., StartSession.php and related scripts) and see this is easier said than done. It looks like their is a history file that is reconstructed, alternate ports (and hosts?) would need to be stored and retrieved and so on. I believe the code changes are doable, but fairly invasive. Before launching into making this level of changes, I thought I should post and see what others think. I might not know about other changes being contemplated in the same area. Perhaps their is a simpler way to specify unique ports (and hosts) per session? I need to resolve this issue, any help, suggestions appreciated. Thank you, Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Brett S. <tec...@se...> - 2005-06-23 16:58:12
|
I'm following up to previous posts, attempting to address similar/same issue. The environment I'm attempting to support is a Linux system with multiple developers, each working out of public_html in their home directories. Resolved so far, Gubed can be installed in a central location, then each user can create a soft-link to StartSession.php, i.e. "ln -s /usr/local/gubed/ServerScripts/StartSession.php StartSession.php". Then to debug any given script in that directory, simply prepend the string "StartSession.php?gbdScript=", i.e. StartSession.php?gbdScript=ScriptToDebug.php. Previously we had worked out changes to localsettings.php that were helpful: "$gbdDebugServer = $_SERVER['REMOTE_ADDR'];". This is a good change, and I'd advocate leaving it in, but the task is more complex. The rub is that StartSession.php 'calls back' the debugger. The server to call back is essentially resolved with the above change, but the specific port is an issue. Before moving on directly to the port, along the way I realized that using secure shell not only provides secure access to the sharedlinux system but removes the need for the gubed proxy and may resolve other issues, potentially the port issue. For instance, one could connect to a Linux server from any accessible point on the Internet with a command like: ssh -X -L 80:localhost:80 -R 8016:localhost:8016 sharedlinux.anywhere.net The "-L 80:localhost:80" allows a local browser to be started (on the initiating system) and browse to "http://localhost/~user" to reach the web server on the sharedlinux system. Under these conditions, when Gubed starts, with the above setting in localsettings.php, it believes is must contact localhost:8016 to reach the debugger, with with the "-R 8016:localhost:8016" this is exactly correct. Secure shell is arranging for the ports to be available. This is 95% of the way to my stated goal. The issue of course is that if multiple users try to do this, only one can be using port 8016 on sharedlinux. Unique ports can be allocated to each user and they can modify the above command, for instance if I was given port 8020, I'd use "-R 8016:localhost:8020" and port 8020 on the sharedlinux box would come back to port 8016 on my local system, which my debugger is waiting on. So the missing item, is how can we tell StartSession.php to use an alternate port? Ultimately I'd like to be able to specify it on the command line like: StartSession.php?gbdScript=ScriptToDebug.php&gbdDebugPort=8020 StartSession.php could be updated to allow a host and port to be specified in addition to the script to debug. Note that such a capability would also allow a given developer to run multiple debug sessions, if so desired. I looked thru the Gubed code (i.e., StartSession.php and related scripts) and see this is easier said than done. It looks like their is a history file that is reconstructed, alternate ports (and hosts?) would need to be stored and retrieved and so on. I believe the code changes are doable, but fairly invasive. Before launching into making this level of changes, I thought I should post and see what others think. I might not know about other changes being contemplated in the same area. Perhaps their is a simpler way to specify unique ports (and hosts) per session? I need to resolve this issue, any help, suggestions appreciated. Thank you, Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-06-20 19:35:37
|
Very nice! I've added a link on the Gubed website, thanks! /Linus On Monday 20 June 2005 21.19, Ewald wrote: > http://www.very-clever.com/debuggen-quanta-gubed.php |
From: Ewald <in...@ve...> - 2005-06-20 19:19:16
|
I translated my tutorial "Debugging PHP scripts with Quanta Plus and Gubed PHP Debugger": http://www.very-clever.com/quanta-gubed-debugging.php to German: http://www.very-clever.com/debuggen-quanta-gubed.php cheers, Ewald |
From: Brett S. <tec...@se...> - 2005-06-19 23:07:32
|
Appologies for the delayed response, just getting back to this. > > Interestingly, by happenstance yesterday I discovered that the issue > > wasn't with MySQL at all, but rather the failure of php to find the > > entry point. I was going to post this morning, thanks for asking. > > What do you mean by entry point? The actual dynamic linking to the mysql > lib? Yes. > Of course, if you tried several times, chances are slimmer that the same > apache instance was used for gubed and another for non-gubed over and > over again. Yes, this is a great point. I *believe* that caching is occuring as if I make edits to a script and then run it in Gubed, some times it will simply exhibit odd behavior such as not stopping on specific entry points, prematurely exiting and such. If I restart Apache after every edit, not something everyone can do, nor very efficient, I get a 'perfect' debug session every time. > Do you get the same error if you try in a simple script, say > <?php > echo "a"; > s(); > echo b(); > ?> Running this script in Gubed on Fedora Core 3, simply exits, no errors. This is the behavior I orginally described. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-06-14 20:25:10
|
On Tuesday 14 June 2005 14.57, Brett Serkez wrote: > Interestingly, by happenstance yesterday I discovered that the issue > wasn't with MySQL at all, but rather the failure of php to find the > entry point. I was going to post this morning, thanks for asking. What do you mean by entry point? The actual dynamic linking to the mysql lib? If it was working without gubed but not with it _could_ have been because of different apache processes were used - one that was using the new mysql lib and another that was loaded after the update that used the new one. Of course, if you tried several times, chances are slimmer that the same apache instance was used for gubed and another for non-gubed over and over again. > Yesterday I happen to notice this same behavior, when I had mistyped an > entry point in new php code I was writing. When attempting to step You mean you mistyped a function name and gubed just bugged out without showing any error message? If I try to call a function or object method that doesent exists, i get something like: Fatal error: Call to undefined function: s() in /mnt/hdc1/projects/Gubed/Gubed/ServerScripts/Gubed.php(82) : eval()'d code on line 27 Do you get the same error if you try in a simple script, say <?php echo "a"; s(); echo b(); ?> > Thank you for your reply, I hope this informations is useful. It is, thanks for the extensive reply! /Linus |
From: Brett S. <tec...@se...> - 2005-06-14 12:57:54
|
Linus, Welcome back. Yes, Aarons helped me setup the module that made the MySQL calls with gbdNoDebug and all was well, I was by-passing the issue. Interestingly, by happenstance yesterday I discovered that the issue wasn't with MySQL at all, but rather the failure of php to find the entry point. I was going to post this morning, thanks for asking. I'm not sure what exactly was happening on the Fedora box, I had uninstalled the default version of MySQL (which was a 3.x) and installed the latest MySQL V5 beta. With a Windoze box, I would have rebooted, but of source with Linux you simply go about you business, the rpm utility stops and restarts the services (daemons) and off you go. So for whatever reason, apache was correctly locating the new MySQL entry points and thus running fine without Gubed, but when attempting to run the scripts via Gubed, the entry points were not located and all processing simply stopped at that point. The issue *appeared* to be Gubed, which was misleading, as I now see. Yesterday I happen to notice this same behavior, when I had mistyped an entry point in new php code I was writing. When attempting to step (into/over) this entry point, Gubed simply 'exited', the web page being debugged comes back empty and the debugger has no where to go. When I recognized this behavior I took out the gdbNoDebug around my module for MySQL, reproduced the old behavior and then rebooted the fedora system (it had been up for weeks) and then all was well, I too can see the MySQL calls are now just fine. Now when I see this behavior, I know what to look for. I don't know if there is anyway for Gubed to report the missing entry point vs. just exiting? It is a mystery to me as to why the MySQL entry points would be found outside the Gubed environment but not within until the OS was rebooted. Thank you for your reply, I hope this informations is useful. Brett On Tue, 14 Jun 2005 14:01:15 +0200, "Linus McCabe" <Li...@mc...> said: > > Hello! > > Does this happen wether an error occurs in your script or not (ie > connection > error to the db or similar)? > Does your script run all towards the end, or does execution just freeze? > If you comment out the call to mysql_connect(), can you single step past > that > line? > Did Aarons suggestion about putting the script with the db call in > gbdNoDebug > help (was it at all possible?) > > If I try to singlestep through mysql_connect() i have no problem (at > least not > when connection is successfull) > > Are the scripts open source, or available for me to test? > > /Linus > > On Thursday 09 June 2005 01.59, Brett Serkez wrote: > > All, > > > > I've run into an issue using gubed with mysql client calls. When > > mysql_connect() is called, gubed never regains control. Doesn't seem to > > matter if I try to step over this call directly, over a function that > > calls mysql_connect() or attempt to reach a break point past this call. > > > > I have to assume mysql_connect is setting some sort of handler that is > > causing the issue. > > > > Has anyone run into this issue? Any suggestions? The connect to the > > database occurs early, making gubed fairly useless for this project. > > > > :-( > > > > Brett > > ------------------------------------- > > Brett C. Serkez, Technical Trainer > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > > shotput a projector? How fast can you ride your desk chair down the office > > luge track? If you want to score the big prize, get to know the little guy. > > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > > _______________________________________________ > > Gubed-devel mailing list > > Gub...@li... > > https://lists.sourceforge.net/lists/listinfo/gubed-devel > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-06-14 12:01:33
|
Hello! Does this happen wether an error occurs in your script or not (ie connection error to the db or similar)? Does your script run all towards the end, or does execution just freeze? If you comment out the call to mysql_connect(), can you single step past that line? Did Aarons suggestion about putting the script with the db call in gbdNoDebug help (was it at all possible?) If I try to singlestep through mysql_connect() i have no problem (at least not when connection is successfull) Are the scripts open source, or available for me to test? /Linus On Thursday 09 June 2005 01.59, Brett Serkez wrote: > All, > > I've run into an issue using gubed with mysql client calls. When > mysql_connect() is called, gubed never regains control. Doesn't seem to > matter if I try to step over this call directly, over a function that > calls mysql_connect() or attempt to reach a break point past this call. > > I have to assume mysql_connect is setting some sort of handler that is > causing the issue. > > Has anyone run into this issue? Any suggestions? The connect to the > database occurs early, making gubed fairly useless for this project. > > :-( > > Brett > ------------------------------------- > Brett C. Serkez, Technical Trainer > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput a projector? How fast can you ride your desk chair down the office > luge track? If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel |
From: Aaron M. <wmc...@ho...> - 2005-06-09 14:32:19
|
Brett, here's the relevant snippet from localsettings_dist.php that is part of the Gubed installation: // Files we do not wish to debug, use this carefully as it might lead to unexpected results // The filenames are preg_match'ed!! $GLOBALS['gbd']['gbdNoDebug'] = Array( '.*?adodb\.inc\.php', '.*?Smarty\.class\.php', //'PEAR.php', //'DB.php', ); Here's the snippet from my localsettings.php file: $GLOBALS['gbd']['gbdNoDebug'] = Array( '.*?adodb\.inc\.php', '.*?Smarty\.class\.php', 'PEAR.php', 'DB.php', 'db_functions.php', ); db_functions.php is one of my files that contains mysql wrapper functions. Aaron McDonald ----------------------------------------------------------------------------------------------------------------- Aaron, This could be a life saving work around. What is the syntax for the 'No Debug' list? An very short example would be great. I can certain push the mysql calls into a separate file if it will allow me to debug the rest of the application. Thanks! Brett On Thu, 09 Jun 2005 09:26:42 -0400, "Aaron McDonald" <wmc...@ho...> said: >Brett, I think I've experienced this same issue but the projects I've >been debugging have used wrappers for the mysql functions. These wrappers >have been defined in a separate file which I've added to the "No Debug" >list >in localsettings.php. I haven't looked into the issue at all. Maybe Linus >will be able to provide some insight when he gets back from vacation. > >Aaron McDonald > > --------------------------------------------------------------------------------------------------- >All, > >I've run into an issue using gubed with mysql client calls. When >mysql_connect() is called, gubed never regains control. Doesn't seem to >matter if I try to step over this call directly, over a function that >calls mysql_connect() or attempt to reach a break point past this call. > >I have to assume mysql_connect is setting some sort of handler that is >causing the issue. > >Has anyone run into this issue? Any suggestions? The connect to the >database occurs early, making gubed fairly useless for this project. >:-( > >Brett >------------------------------------- >Brett C. Serkez, Technical Trainer |
From: Aaron M. <wmc...@ho...> - 2005-06-09 13:26:43
|
Brett, I think I've experienced this same issue but the projects I've been debugging have used wrappers for the mysql functions. These wrappers have been defined in a separate file which I've added to the "No Debug" list in localsettings.php. I haven't looked into the issue at all. Maybe Linus will be able to provide some insight when he gets back from vacation. Aaron McDonald --------------------------------------------------------------------------------------------------- All, I've run into an issue using gubed with mysql client calls. When mysql_connect() is called, gubed never regains control. Doesn't seem to matter if I try to step over this call directly, over a function that calls mysql_connect() or attempt to reach a break point past this call. I have to assume mysql_connect is setting some sort of handler that is causing the issue. Has anyone run into this issue? Any suggestions? The connect to the database occurs early, making gubed fairly useless for this project. :-( Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Brett S. <tec...@se...> - 2005-06-09 00:00:14
|
All, I've run into an issue using gubed with mysql client calls. When mysql_connect() is called, gubed never regains control. Doesn't seem to matter if I try to step over this call directly, over a function that calls mysql_connect() or attempt to reach a break point past this call. I have to assume mysql_connect is setting some sort of handler that is causing the issue. Has anyone run into this issue? Any suggestions? The connect to the database occurs early, making gubed fairly useless for this project. :-( Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-05-31 20:09:11
|
On Monday 30 May 2005 01.25, Brett Serkez wrote: > I personally use multiple desktops during periods of development and > would use one to run the browser and the other for debugging, but I can > live with the restriction of using the same desktop for both. Yeah, ok.. Well, Aarons patch makes it possible to keep doing that. > Mostly, yes, but it would be nice to be able to specify the port on the > fly. I suppose a system administrator could hand out specific ports to > individual users so that they always start the client on that port and > code their localconfig with that port. Shouldn't be too much work to add ports as a part of the request anyway. Ill put it on the todo... /linus > Brett > ------------------------------------- > Brett C. Serkez, Technical Trainer > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel |
From: Linus M. <Li...@mc...> - 2005-05-31 05:08:54
|
Hello! Thanks for the patch! I've had a quick look at the diffs and they look good, but I dont think Ill have time to test it before I leave tomorrow. In case I don't Ill test soon after I get back /Linus On Tuesday 31 May 2005 02.52, Aaron McDonald wrote: > Here is the multi-user mod that I promised. I was waiting to send it out > with some thoughts that I have concerning running Gubed securely but I'm > still sorting out a few things with that so here's just the mod for now. > > Apply the patch by running the following in the ServerScripts directory > (Gubed version 0.2 or CVS): > patch -p0 < GubedUserSpecificSettings.patch > > Here are the mod details. I decided not to enforce any user restrictions in > Gubed, as this is more appropriately handled at the PHP or server level. > > StartSession.php > - Added a "LocalSettings" input parameter > - Ensured that gbdURI always ends in a slash so that when a directory in a > user's webspace is submitted, the links to the potential files are valid > - Changed error message when $gbdTmp doesn't exist to actually print > $gbdTmp rather than {$gbdBase}{$GLOBALS['gbd']['Script']} since $gbdBase is > likely inaccurate at this point > - Prepopulated the gbdScript input box first with gbdURI if it is available > > GubedFunctions.php and GubedGlobals.php > - Changed to handle new "LocalSettings" parameter > > I've tested it between a single server and client and I was able to have > concurrent debug sessions on separate ports. Let me know if you encounter > any issues. > > Thanks, > Aaron McDonald |
From: Aaron M. <wmc...@ho...> - 2005-05-31 00:53:36
|
Here is the multi-user mod that I promised. I was waiting to send it out with some thoughts that I have concerning running Gubed securely but I'm still sorting out a few things with that so here's just the mod for now. Apply the patch by running the following in the ServerScripts directory (Gubed version 0.2 or CVS): patch -p0 < GubedUserSpecificSettings.patch Here are the mod details. I decided not to enforce any user restrictions in Gubed, as this is more appropriately handled at the PHP or server level. StartSession.php - Added a "LocalSettings" input parameter - Ensured that gbdURI always ends in a slash so that when a directory in a user's webspace is submitted, the links to the potential files are valid - Changed error message when $gbdTmp doesn't exist to actually print $gbdTmp rather than {$gbdBase}{$GLOBALS['gbd']['Script']} since $gbdBase is likely inaccurate at this point - Prepopulated the gbdScript input box first with gbdURI if it is available GubedFunctions.php and GubedGlobals.php - Changed to handle new "LocalSettings" parameter I've tested it between a single server and client and I was able to have concurrent debug sessions on separate ports. Let me know if you encounter any issues. Thanks, Aaron McDonald |
From: Brett S. <tec...@se...> - 2005-05-29 23:25:18
|
All, > I'm trying to think of reasonable reasons why the user wouldn't run both > the browser and client on the same box. Are there any good examples of this > or is it a thoretical problem only? I personally use multiple desktops during periods of development and would use one to run the browser and the other for debugging, but I can live with the restriction of using the same desktop for both. I have not yet have need for the proxy, but I could see the appearance of the browser and client as being on different systems with the proxy in use. > Also, if several users use the same box, it's only the port that needs to > be specified if the above is used to specify client address. (why is the > variable called gbdDebug>server< anyway? :) > > With Aarons promised patch for multiple localconfigs, I assume this > problem is out of the way in any case. Mostly, yes, but it would be nice to be able to specify the port on the fly. I suppose a system administrator could hand out specific ports to individual users so that they always start the client on that port and code their localconfig with that port. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Linus M. <Li...@mc...> - 2005-05-29 20:35:25
|
Hello! I just thought I'd mention I'm going away on wednesday and Ill be gone for about two weeks so I wont be able to answer any mails during that period. /Linus |
From: Linus M. <Li...@mc...> - 2005-05-29 17:54:14
|
Hello! Thanks for this patch! I chose to go for the "clean" version - very nice of you to give me the options ;) You've supplied me with a few nice fixes lately - would you like CVS access? /Linus On Thursday 26 May 2005 00.44, Aaron McDonald wrote: > Linus, thanks for the direction on this. I looked again and found that it > was only failing when __FILE__ was within an include or similar statement > such as: > include(dirname(__FILE__) . '/bootstrap.inc'); > require_once(dirname(__FILE__) . '/init.inc'); > > I've attached a patch for GuberParserTokenizer.php that fixes the issue and > since I didn't know how you'd like to handle the gbdAddUntilNext signature > change, I've sent 2 versions of the patch. > > cleanSigMod.diff - adds $gbdThisScript as the first parameter in > gbdAddUntilNext so it's like the gbdAddBlock signature > > quickSigMod.diff - adds $gbdThisScript as an optional third parameter in > gbdAddUntilNext > > Thanks, > Aaron |
From: Linus M. <Li...@mc...> - 2005-05-29 17:14:23
|
On Friday 27 May 2005 14.24, Brett Serkez wrote: > $gbdDebugServer = $_SERVER['REMOTE_ADDR']; > > This works well in most cases as long as each user is working from a > unique system and start both the debugger and web browser on that > system. Better but still doesn't account for multiple users on the same > system or the case of the need to use the proxy. I'm trying to think of reasonable reasons why the user wouldn't run both the browser and client on the same box. Are there any good examples of this or is it a thoretical problem only? Also, if several users use the same box, it's only the port that needs to be specified if the above is used to specify client address. (why is the variable called gbdDebug>server< anyway? :) With Aarons promised patch for multiple localconfigs, I assume this problem is out of the way in any case. /Linus > Brett > > ------------------------------------- > Brett C. Serkez, Technical Trainer |
From: Brett S. <tec...@se...> - 2005-05-27 14:00:49
|
Aaron, These changes sound wonderful... I'm not so sure they wouldn't be useful to others. The setup and control of utilities such as debuggers should be the responsibility of the system administrator, just as are other aspects of the environment. These changes are milestones along the way towards this capability. Thank you! Brett On Fri, 27 May 2005 09:46:48 -0400, "Aaron McDonald" <wmc...@ho...> said: > I'm working on a mod that might resolve the issue with localsettings.php > and > allow Gubed to be run in a multi-user environment. The mod will include > at > least the following: > > 1. Allow user to specify the path of the localsettings.php file that > should > be used. If a user does not specify a file then the localsettings.php > file > in the same directory as StartSession.php will be used. > > 2. When StartSession.php is invoked from ~home/public_html, the user will > only be allowed to debug scripts that are accessible from > ~home/public_html. > This will prevent users from debugging any server content other than > their > own scripts. > > The mod should be ready by tomorrow and then I'll send it out. > > I think these changes may be too limiting for most Gubed users and may > not > belong in the code base, but I think Brett will find them useful. > > Thanks, > Aaron McDonald > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Gubed-devel mailing list > Gub...@li... > https://lists.sourceforge.net/lists/listinfo/gubed-devel ------------------------------------- Brett C. Serkez, Technical Trainer |
From: Aaron M. <wmc...@ho...> - 2005-05-27 13:46:54
|
I'm working on a mod that might resolve the issue with localsettings.php and allow Gubed to be run in a multi-user environment. The mod will include at least the following: 1. Allow user to specify the path of the localsettings.php file that should be used. If a user does not specify a file then the localsettings.php file in the same directory as StartSession.php will be used. 2. When StartSession.php is invoked from ~home/public_html, the user will only be allowed to debug scripts that are accessible from ~home/public_html. This will prevent users from debugging any server content other than their own scripts. The mod should be ready by tomorrow and then I'll send it out. I think these changes may be too limiting for most Gubed users and may not belong in the code base, but I think Brett will find them useful. Thanks, Aaron McDonald |
From: Brett S. <tec...@se...> - 2005-05-27 12:24:26
|
All, Making some progress on the first issue, that of multiple users and a single localsettings.php: > The debug server and port are read from the single file > localsettings.php in the ServerScripts directory. I tried adding > ?gbdDebugServer=mysystem to the reference, but it didn't work. Looks > like GubedGlobals.php could be modified to look first in the current > directory for localsettings.php and/or take the debug server/port as an > option. I used a suggestion from Linus and have modified my localsettings.php: $gbdDebugServer = $_SERVER['REMOTE_ADDR']; This works well in most cases as long as each user is working from a unique system and start both the debugger and web browser on that system. Better but still doesn't account for multiple users on the same system or the case of the need to use the proxy. Brett ------------------------------------- Brett C. Serkez, Technical Trainer |