Can't get developer companion to work on my virtual machine -- may be version incompatabilities

[will....@switchsoft.com]

Hi All

I have used developer companion in the past and really appreciated it a great deal. I am on a new box with a fresh install of firefox / firebug /developer companion, using the same code base I used to before when developer companion worked for me but now I don't even see the icon for developer companion appearing in the firebug console.

Here is what I am currently running:

Windows 7 on my host machine, Debian squeeze on my guest machine (the guest machine is where the webpage I am testing is being severed). It may be worth noting that my old box where developer companion was working was an all windows XAMPP set up.

• Firefox version: 17.1
• FirePHP Extension version (if installed): Not installed
  
• DeveloperCompanion version (if installed): 1.0b1rc47
• Firebug version (if installed): 1.11.1
• FirePHP server library name: (typically FirePHPCore or ZendFramework) FirePhpCore, however I am running a ZendFramework application so I could switch to Zends implementation if that's recommended.
  
• FirePHP server library version: 1.0.0b1rc7 (freshly upgraded just in case the error was related).
  
• Were things working before upgrading the client?: This worked on my last box (now dead) but I am not sure what versions of everything I was running on that machine.
  
• How was the client upgraded?: Just to be safe I uninstalled and reinstalled installed firefox and installed just firebug and developer companion as add ons (though my disabled AVG Safe Search some how survived the re installation). I then got the newest version of the server library and replaced the old one I was using on my guest machine.
  
• Is anything FirePHP related working?: The test page at: http://www.firephp.org/ is showing out put.

I did some poking in the server library and came to the conclusion that is reading my credentials file just fine. Just to make sure there were no credentials issues I made everything authorized while I am trying to sort this problem out running on my VM:

{
  "cadorn.org/insight/@meta/config/0": {
    "allow": {
      "ips": [
        "*"
      ],
      "authkeys": [
          "*"
      ]
    }
  }
}   

What is happening in the code its self is that it is getting to line 417 of Insight_Helper and it is detecting the following $clientInfo:

array(1) { ["client"]=> string(7) "firephp" }

This is causing it to set the header of the x-insight-installation-id and then return false.

This appears to indicate that the client is not announcing its self.

Here are my request and response headers:

Response Headers

Cache-Control	no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection	Keep-Alive
Content-Encoding	gzip
Content-Length	1962
Content-Type	text/x-json
Date	Wed, 19 Dec 2012 21:54:40 GMT
Expires	Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive	timeout=15, max=67
Pragma	no-cache
Server	Apache/2.2.16 (Debian)
Set-Cookie	ZDEDebuggerPresent=php,phtml,php3; path=/
Vary	Accept-Encoding
X-Powered-By	PHP/5.3.14 ZendServer/5.0
x-insight-installation-id	com.switchsoft.local

Request Headers

Accept	*/*
Accept-Encoding	gzip, deflate
Accept-Language	en-US,en;q=0.5
Connection	keep-alive
Content-Length	350
Content-Type	application/json; charset=UTF-8
Cookie	ZDEDebuggerPresent=php,phtml,php3; PHPSESSID=5bmbdcksrrjmui0f61o87hb0l0
Host	local.switchsoft.com
Referer	http://local.switchsoft.com/event/reader
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
X-Requested-With	XMLHttpRequest

I notice that on firephp.org the following request headers are sent:

x-insight-client	1
x-request-id	1355945592312772

I am not seeing these headers generated when I test my code.

Just in case it's relevant here is my package.json file as well:

{
    "uid": "http://local.switchsoft.com/",
     "implements": {
        "/": {
            "credentialsPath": "./credentials.json",
            "encoder": {
                "depthNoLimit": true,
                "lengthNoLimit": true,
                "maxDepth": 5,
                "maxStringLength": 15000,
                "maxArrayDepth": 3,
                "maxArrayLength": 100,
                "maxObjectDepth": 3,
                "maxObjectLength": 100,
                "exception.traceMaxLength": -1,
                "trace.maxLength": -1
            }
        }
    }
}

I suspect this may be an issue of incompatible versions of firefox, firebug and developer companion.

Any advice any one can give me would be greatly appreciated.

Thanks in advance and best regards

Will Ferrer

[Christoph Dorn]

Thanks for the detailed report.

Did you setup a workspace for http://local.switchsoft.com/ in DeveloperCompanion? I suspect this is why the headers are not sent properly.

Christoph

[will....@switchsoft.com]

Hi Chrisitoph

Thank you so much for the response. I can get to the developer companion window now but when I try to add the new work space I get this error:

Homepage URL: http://local.switchsoft.com

Response Status: 204

Response Headers:

Date: Mon, 24 Dec 2012 21:55:05 GMT

Server: Apache/2.2.16 (Debian)

X-Powered-By: PHP/5.3.14 ZendServer/5.0

Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/

x-insight-installation-id: com.switchsoft.local

Status: 204 No Content

Vary: Accept-Encoding

Content-Length: 0

Connection: close

Content-Type: text/htm

Any insights you can give me would be greatly appreciated.

I hope you are having a great holiday season.

Best regards

Will Ferrer 

[Christoph Dorn]

The status code of 204 may be the issue. I think the server must return 200 during the workspace setup process.

If that does not fix it ... Is there anything showing in the "Response Body" output when setting up the workspace? How about error log on the server?

To debug further you can set the following constant on the server before loading FirePHP/Insight:

  define('INSIGHT_DEBUG', true);

Christoph

will....@switchsoft.com

24 December, 2012 1:58 PM

Hi Chrisitoph

Thank you so much for the response. I can get to the developer companion window now but when I try to add the new work space I get this error:

Any insights you can give me would be greatly appreciated.

I hope you are having a great holiday season.

Best regards

Will Ferrer 

On Thursday, December 20, 2012 7:18:33 PM UTC-8, Christoph Dorn wrote:

--
You received this message because you are subscribed to the Google Groups "DeveloperCompanion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/devcomp/-/gtIL1ubs_nUJ.
To post to this group, send email to dev...@googlegroups.com.
To unsubscribe from this group, send email to devcomp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/devcomp?hl=en.

Christoph Dorn

20 December, 2012 7:18 PM

Thanks for the detailed report.

Did you setup a workspace for http://local.switchsoft.com/ in DeveloperCompanion? I suspect this is why the headers are not sent properly.

Christoph

On Wednesday, 19 December 2012 14:15:45 UTC-8, will....@switchsoft.com wrote: --
You received this message because you are subscribed to the Google Groups "DeveloperCompanion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/devcomp/-/ZciNElh_aw8J.
To post to this group, send email to dev...@googlegroups.com.
To unsubscribe from this group, send email to devcomp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/devcomp?hl=en.

will....@switchsoft.com

19 December, 2012 2:15 PM

--
You received this message because you are subscribed to the Google Groups "DeveloperCompanion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/devcomp/-/49ouFI7vqbgJ.
To post to this group, send email to dev...@googlegroups.com.
To unsubscribe from this group, send email to devcomp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/devcomp?hl=en.

---

[Will Ferrer]

Hi Christoph

With  define('INSIGHT_DEBUG', true);  on I get: [INSIGHT] Flushing headers

When I try to add the work space I don't see any xhr requests on the page that gives me the error message, so I am not sure how I would check the Response Body output (how is it making the request?).

The php.log gives me just a warn when trying to add a work space (though it may be a clue):

[29-Dec-2012 01:24:11 UTC] PHP Warning:  unlink(/tmp/cadorn.org/insight/_transport/): Is a directory in [path to my php library folder]/firephp/lib/Insight/Helper.php on line 566

the error.log gives this.

[Fri Dec 28 17:28:22 2012] [error] [client 192.168.0.15] Attempt to serve directory: /var/[path to public folder]

This request should be caught by my vhost and redirected to index.

The thing that's odd is a normal request gives a different message in the error.log:

[Fri Dec 28 17:32:39 2012] [error] [client 192.168.0.15] Directory index forbidden by Options directive: /var/[path to public folder]

I wounder if that's a hint as well.

Thank you once again for the prompt and clear response. I really appreciated the assistance getting it up and running again.

I hope you have a great holiday weekend.

Best regards

Will Ferrer

[Christoph Dorn]

It looks like a config related issue.

The package.json file you sent earlier has a key of "/" in the "implements" property where it should be "cadorn.org/insight/@meta/config/0 ".
See: http://sourcemint.com/github.com/firephp/firephp/1/-docs/Configuration/Files

So it should be:

{
    "uid": "http://local.switchsoft.com/",
     "implements": {

        "cadorn.org/insight/@meta/config/0": {

            "credentialsPath": "./credentials.json",
            "encoder": {
                "depthNoLimit": true,
                "lengthNoLimit": true,
                "maxDepth": 5,
                "maxStringLength": 15000,
                "maxArrayDepth": 3,
                "maxArrayLength": 100,
                "maxObjectDepth": 3,
                "maxObjectLength": 100,
                "exception.traceMaxLength": -1,
                "trace.maxLength": -1
            }
        }
    }
}

Will Ferrer

28 December, 2012 5:43 PM

With  define('INSIGHT_DEBUG', true);  on I get: [INSIGHT] Flushing headers

When I try to add the work space I don't see any xhr requests on the page that gives me the error message, so I am not sure how I would check the Response Body output (how is it making the request?).

It should include a "Response Body" section in the result output after clicking "create workspace" in the dialog.

The php.log gives me just a warn when trying to add a work space (though it may be a clue):

[29-Dec-2012 01:24:11 UTC] PHP Warning:  unlink(/tmp/cadorn.org/insight/_transport/): Is a directory in [path to my php library folder]/firephp/lib/Insight/Helper.php on line 566

the error.log gives this.

[Fri Dec 28 17:28:22 2012] [error] [client 192.168.0.15] Attempt to serve directory: /var/[path to public folder]

This request should be caught by my vhost and redirected to index.

The thing that's odd is a normal request gives a different message in the error.log:

[Fri Dec 28 17:32:39 2012] [error] [client 192.168.0.15] Directory index forbidden by Options directive: /var/[path to public folder]

I wounder if that's a hint as well.

Hmm.

So when you access http://local.switchsoft.com/  in your browser you should get a page served by PHP that includes FirePHP/Insight and responds with a status code of 200.
When you use "http://local.switchsoft.com/" in the new workspace dialog it will connect to FirePHP/Insight running at "http://local.switchsoft.com/".

Thank you once again for the prompt and clear response. I really appreciated the assistance getting it up and running again.

No problem. The setup process is not as fault tolerant as I like it yet. I have some ideas to improve it.

If you cannot get it running with the above info feel free to ping me on skype and we can do a shared screen session to see what is going on.
SkypeID: christophdorn

Christoph

[Will Ferrer]

Hi Christoph

The package.json file you sent earlier has a key of "/" in the "implements" property where it should be "cadorn.org/insight/@meta/config/0 ".
See: http://sourcemint.com/github.com/firephp/firephp/1/-docs/Configuration/Files

I tried swapping in this config into the package.json, but it didn't seem to help.
 

It should include a "Response Body" section in the result output after clicking "create workspace" in the dialog.

I don't see a response body in the window any where, I did some looking through the code and figured out why it's blank at least (see below).

Hmm.

So when you access http://local.switchsoft.com/  in your browser you should get a page served by PHP that includes FirePHP/Insight and responds with a status code of 200.
When you use "http://local.switchsoft.com/" in the new workspace dialog it will connect to FirePHP/Insight running at "http://local.switchsoft.com/".

It seems it should be working to me, I can put var_dumps in the inner workings of firephp and see it going. I went ahead and tracked down what is happening when I try to add a workspace and found that line 152 of Insight_Helper is what is causing the blank response body (the exit command is happening):

                // NOTE: This may stop script execution if a server request is detected
                if(self::$instance->server->listen()===true) {
                    self::$swallowDebugMessages = true;
                    exit;
                }

Is there any where in particular I should put in some var_dumps that would shed better light on what is going on when I try to add an workspace?

Also, I thought I should mention that the new environments we are running are using Zend Server when previously I had XAMPP local machine.

In case it's useful here is the code we use to start up firephp:

        define('INSIGHT_CONFIG_PATH', ACCOUNT_PATH.DS.'firephp'.DS.'package.json');
        if(file_exists(INSIGHT_CONFIG_PATH) == true && (!defined('FIREPHP_ACTIVATED') || FIREPHP_ACTIVATED != true)){
            define('FIREPHP_ACTIVATED', true);
            define('INSIGHT_DEBUG', false);
        //    require_once('phar://firephp.phar/FirePHP/Init.php');
            require_once('firephp/lib/FirePHP/Init.php');
           
            //Insight_Helper::getInstance()->registerListener('payload', new PayloadListener());
           
            $firephp = FirePHP::getInstance(true);
           
            $firephp->registerErrorHandler();
            $firephp->registerExceptionHandler();
       
            global $requestConsole;
            //Use firebug
            $pageInspector = FirePHP::to("page");
            $requestConsole = $pageInspector->console('All Comp Error');
            $requestConsole = $requestConsole->nolimit();
        }else{
            define('FIREPHP_ACTIVATED', false);
        }

No problem. The setup process is not as fault tolerant as I like it yet. I have some ideas to improve it.

I understand that feeling completely. It seems like no piece of code is over completely finished.
 

If you cannot get it running with the above info feel free to ping me on skype and we can do a shared screen session to see what is going on.
SkypeID: christophdorn

Thank you. I will add you on skype.

We have it on our short term road map to set up some screen sharing software so I will see if we can get something installed.

I really appreciate how much help and attention you are offering here to help get this up and going again as well as the great work you have put in creating this project to make the rest of our jobs easier.

[Will Ferrer]

Hi Christoph

I decided to take one more stab at tracking this down in the code and wanted to share my findings.

when I try to add a work space, on line 125 of Insight_Server the 204 status is being generated. The reason is because the $_GET array is empty (as is the $_POST array) so the $response variable isn't being populated. Basically when I try to add a work space no "payload" is being sent to the server inside the post data even the code is expecting it.

getallheaders() produces this (in case it's helpful):

array(14) {
["Host"]=>
string(20) "local.switchsoft.com"
["User-Agent"]=>
string(84) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 FirePHP/0.4"
["Accept"]=>
string(63) "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
["Accept-Language"]=>
string(14) "en-US,en;q=0.5"
["Accept-Encoding"]=>
string(13) "gzip, deflate"
["Connection"]=>
string(10) "keep-alive"
["Content-Type"]=>
string(48) "application/x-www-form-urlencoded; charset=UTF-8"
["x-insight"]=>
string(5) "serve"
["Content-Length"]=>
string(3) "144"
["Cookie"]=>
string(71) "ZDEDebuggerPresent=php,phtml,php3; PHPSESSID=lct2o2uo1iejbhd52i6ev2scp7"
["x-insight-client"]=>
string(1) "1"
["x-request-id"]=>
string(16) "1357086686776606"
["Pragma"]=>
string(8) "no-cache"
["Cache-Control"]=>
string(8) "no-cache"
}

I can't figure out why the request contains no get or post data however.

Thanks again for all your great assistance and I hope you had a great new year.

Best regards

Will Ferrer

[Christoph Dorn]

Will Ferrer wrote:

I decided to take one more stab at tracking this down in the code and wanted to share my findings.

when I try to add a work space, on line 125 of Insight_Server the 204 status is being generated. The reason is because the $_GET array is empty (as is the $_POST array) so the $response variable isn't being populated. Basically when I try to add a work space no "payload" is being sent to the server inside the post data even the code is expecting it.

Hmm. Are you including FirePHP/Insight as the first lib in your page? Doing anything with POST data prior?

PHP has some config options to populate the $_POST variable. See: `track_vars ` at http://php.net/manual/en/ini.core.php which must be `on`. Maybe this is turned off on your zend server install. Also see `variables_order ` config option which should contain `P` and `enable_post_data_reading ` must be on.

If you need to keep your config options in an incompatible state you can see if you can get the post data from a different variable. IIRC the $_POST data can be fetched from a different variable.

Hope this helps.

Happy new year to you!

Christoph

[Will Ferrer]

Hi Christoph

I finally managed to fix it though I am still unclear to why exactly it wasn't working.

I used wireshark to see that the correct post data was being sent but even at the very top of my index.php file the post vars were not showing up. I checked all the php.ini settings (some weren't set but were true by default). The rest of our applications are working fine (post data and all) so the problem seems unique to dev companion. 

I then started trying to address the issue that dev companion has a different error message in the error.log file than any other requests by trying to figure out whats causing it.

the error.log gives this for dev companion:

[Fri Dec 28 17:28:22 2012] [error] [client 192.168.0.15] Attempt to serve directory: /var/[path to public folder]

but normal requests give this error:

[Fri Dec 28 17:32:39 2012] [error] [client 192.168.0.15] Directory index forbidden by Options directive: /var/[path to public folder]

Looking at my vhost I noticed that the DirectoryIndex directive was pointed at the old directory index before we made our most recent changes to our directory structure. I tried disabling the DirectoryIndex all together because it shouldn't be needed due to our rewrite rules but this did not fix the error or the problem.

Finally I pointed the DirectoryIndex at the new correct path to our index.php and that made dev companion start working again.

I don't know why this is a problem only for dev companion and not the rest of our applications but I am really glad to have it working again. Any ideas?

Hopefully that info will be helpful to any one else that is having the same issue.

Thank you once again for all your great assistance on the problem and for putting together such a great tool. You really went above and beyond helping us out.

I hope this message finds you well.

Best regards

Will Ferrer

[Christoph Dorn]

Will Ferrer

2 January, 2013 6:00 PM

I finally managed to fix it though I am still unclear to why exactly it wasn't working.

Good to hear you got it working!

Finally I pointed the DirectoryIndex at the new correct path to our index.php and that made dev companion start working again.

I don't know why this is a problem only for dev companion and not the rest of our applications but I am really glad to have it working again. Any ideas?

Maybe no trailing slash? i.e. http://local.switchsoft.com/ vs http://local.switchsoft.com

Thank you once again for all your great assistance on the problem and for putting together such a great tool. You really went above and beyond helping us out.

Thanks. No problem.

Christoph

[Will Ferrer]

Hi Christoph

I tried it with and with out the trailing slash and it didn't seem to effect the issue. But the important thing is its all working again.

I hope you are having a great weekend.

Best regards

Will Ferrer