What steps will reproduce the problem? 1. Check the user agent before any FirePHP console is activated. 2. Check it after a console has been loaded.

What is the expected output? What do you see instead? This may be an issue with Firebug and not FirePHP...I don't know. With Firebug 1.4.5 the user agent always had "FirePHP/0.4" appended to the end. With Firebug 1.5 it adds it only after you've used a console.

What version of the product are you using? On what operating system? FirePHP 0.4.3, Firebug 1.5, Firefox 3.5.6 under Gentoo Linux.

Please provide any additional information below. This on-the-fly user agent change raises pure hell with other tabs that may be, for example, logged into webmail etc, as they view any user agent change as a potential session hijack. This was happening to me in Horde webmail for example...really had me going nuts.

Thanks for the report!

The next release will have an option to not modify the User-Agent. This will require an updated server library as well.

Please test: http://www.firephp.org/HQ/ReleaseCandidate.htm

The new options is under: "Tools" -> "FirePHP" -> "Options"

Sorry I didn't notice your post sooner. The new option works great. I do notice however that using that client and server version my fb() calls print to the client console twice.

Could that be related to Issue 57?

Comment deleted

I just wanted to add some additional information to this bug, as I just spent hours debugging what I thought was an issue in my code, and then ran into this.

The original report is correct, that the header is only added now, when the console is open, before It was always there. And yes, this wrecks havoc on anti-session-hijacking code. I've been losing my shopping carts all day and trying to figure out why.

However, I have an additional piece of information along why/when this was specifically happening to me.

Basically, if I start using a website, and keep using that website with FireBug open, it's fine.

If I take a link off that website, and spend 'some amount of time' on the second website, without Firebug open ... at least a couple minutes, I wasn't able to time exactly how long it took.

Then if you use the 'Back' button to return to the original page you were working on. The FireBug Console isn't already open, and instead, 'pops up' after the page loads.

This causes the FirePHP/0.4 user agent to not be sent. Which in turn makes all FirePHP code not run (And triggers the session hijack code)

One additional update. After some more testing, it seems that perhaps this is related to a bug/feature in FireBug?

Specifically, I realized that I was running in the mode where my console 'data entry' area was popped up in side-by-side mode. Normally I have the 'bottom line entry' mode turned on. I switched the data entry mode to bottom-line, and I haven't seen the bug manifest again since. (Or maybe that's just coincidence)

@EliCrossbow

Please test: http://www.firephp.org/HQ/ReleaseCandidate.htm

An option to not modify the user-agent header is under: "Tools" -> "FirePHP" -> "Options"

I am reworking the activation logic as part of FirePHP 1.0. I'll have more info on that soon.

Just to update. I'm now running the release candidate version with the modify user agent option off and it seems to be working fine. The previous issue I reported where this version gave me duplicate output from fb() appears to only happen on redirects as described in Issue 146.

@digitalaudiorock - Great. Thanks for letting me know.

You can also check out FirePHP 1.0: http://upgrade.firephp.org/

Released: http://www.firephp.org/HQ/FinalRelease.htm

Wow...suddenly this isn't working for me and I have no idea why.

I'm currently running FirePHP 0.5.0 and Firebug 1.6.1 with the FirePHPCore-0.3.2 server component. I'm unclear what changed but I can't get any display of the fiephp fb() function without enabling the "Modify User Agent Header" option. Any ideas what might be going on there? Could this be related to Firebug itself? I think that's all that changed except for my version of Firefox itself.

Hmm. What are the request and response headers?

Wow...for whatever reason today I can't reproduce the issue and it's working fine. Not a clue what that was all about.