FirePHP 0.4.3 with Firebug 1.5 changes user agent on the fly

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by digitala...@gmail.com on 22 Jan 2010 at 4:39

[GoogleCodeExporter]

Thanks for the report!

Original comment by christ...@christophdorn.com on 22 Jan 2010 at 9:01

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by christ...@christophdorn.com on 22 Jan 2010 at 9:02

• Added labels: Milestone-Extension-0.4.4

[GoogleCodeExporter]

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

Original comment by christ...@christophdorn.com on 4 Mar 2010 at 5:14

• Changed state: Committed

[GoogleCodeExporter]

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

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

Original comment by christ...@christophdorn.com on 9 Mar 2010 at 12:49

[GoogleCodeExporter]

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.

Original comment by digitala...@gmail.com on 13 Jun 2010 at 10:03

[GoogleCodeExporter]

Could that be related to Issue 57?

Original comment by christ...@christophdorn.com on 18 Jun 2010 at 9:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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)

Original comment by EliCross...@gmail.com on 7 Oct 2010 at 6:31

[GoogleCodeExporter]

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)

Original comment by EliCross...@gmail.com on 7 Oct 2010 at 6:39

[GoogleCodeExporter]

@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.

Original comment by christ...@christophdorn.com on 7 Oct 2010 at 9:13

[GoogleCodeExporter]

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.

Original comment by digitala...@gmail.com on 17 Oct 2010 at 6:43

[GoogleCodeExporter]

@digitalaudiorock - Great. Thanks for letting me know.

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

Original comment by christ...@christophdorn.com on 17 Oct 2010 at 6:54

[GoogleCodeExporter]

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

Original comment by christ...@christophdorn.com on 27 Oct 2010 at 4:32

• Changed state: Fixed

[GoogleCodeExporter]

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.

Original comment by digitala...@gmail.com on 4 Feb 2011 at 10:44

[GoogleCodeExporter]

Hmm. What are the request and response headers?

Original comment by christ...@christophdorn.com on 4 Feb 2011 at 11:02

[GoogleCodeExporter]

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

Original comment by digitala...@gmail.com on 5 Feb 2011 at 1:56