Closed Bug 36545 Opened 21 years ago Closed 12 years ago
talkback does not function with authenticating proxies
Talkback fails to function with an authenticating HTTP proxy. Instead of issuing a username and password challenge, it simply returns an error when trying to submit a report.
Can you provide more information on what proxy software you are using. I not able to reproduce the problem. What kind of setup is needed and so on. This will help us in fixing the problem. Is it a standard proxy server ?(I know it is not router based proxy.)
The proxy software is Netscape-Proxy/2.53 . It returns a "HTTP/1.0 407 Proxy authorization required" response when no authentication header is provided in the request.
setting status to new
Status: UNCONFIRMED → NEW
Ever confirmed: true
Talkback client-server combination doesn't have proxy user login facility. Regular proxy without user authentication works fine.
Status: NEW → ASSIGNED
A workaround on the PC platform is to use Proxomitron http://members.tripod.com/Proxomitron/ You can follow the instructions given here http://setiathome.berkeley.edu/faq.html#q49 to set it up for authenticating proxies. Assuming that you're running Proxomitron on port 8080, you can then configure Talkback to use localhost:8080 as the HTTP proxy, and Proxomitron will add the user and password information automatically.
*** Bug 130766 has been marked as a duplicate of this bug. ***
*** Bug 137610 has been marked as a duplicate of this bug. ***
*** Bug 152565 has been marked as a duplicate of this bug. ***
*** Bug 101287 has been marked as a duplicate of this bug. ***
I have the same problem when using TalkBack with my authenticating proxy, which is iPlanet Proxy 3.6. The suggested 'workaround' of using 'Proxomitron', is only valid on Ms-Windows. (By the way, a current URL is http://www.proxomitron.org ). But this does nothing for users of other Operating Systems, like Linux/BDS/Mac/etc. Is anyone actively working on this issue ? I am using Mozilla at work as both an email and a web client, but am unable to submit the crash data that TalkBack produces because it fails to connect through the authenticating proxy (doesn't ask for userid/password). I would very much like to see this one resolved, so I can report crashes again ;)
As far as I know, we do not have any immediate plans to add authenticating proxy support to the Talkback client. Marking won't fix. If we do decide to add this functionality in the future, we will reopen the bug.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
WONTFIX ? whaddayamean, WONTFIX ? So I guess that this means that I wont be able to submit crash dumps, *ever*. Might as well stop using the product if I can't submit any crash reports ...
*** Bug 198038 has been marked as a duplicate of this bug. ***
->jrgm,mcafee for possible workarounds. I am re-opening to re-assign.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: namachi → jrgm
Status: REOPENED → NEW
QA Contact: chofmann → namachi
*** Bug 210883 has been marked as a duplicate of this bug. ***
*** Bug 247692 has been marked as a duplicate of this bug. ***
Doesn't work with a Microsoft ISA Server either
*** Bug 263478 has been marked as a duplicate of this bug. ***
Any chance to get talkback upgraded to support proxies w/ authentication ? Firefox and Thunderbird are now used in large companies, which protect the Internet access with proxy+authentication. It's a pity crash reports are discarded only because they cannot be transmitted through the proxy.
*** Bug 267328 has been marked as a duplicate of this bug. ***
*** Bug 263324 has been marked as a duplicate of this bug. ***
Probably looking for a new owner here, jrgm is welcome to take this back but he should update his email.
Assignee: jrgmorrison → jay
QA Contact: namachi → chofmann
We should also go back and split the bug into Basic Auth and NTLM bugs. Support for each needs to be implemented separately.
*** Bug 286538 has been marked as a duplicate of this bug. ***
*** Bug 315992 has been marked as a duplicate of this bug. ***
I too am facing the same bug but on windows XP sp2 see details of my config. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060308 Firefox/184.108.40.206 The proxy server is Squid. I should say this is a high priority bug if talkback crash reports are considered useful for improving the product. There is no point of talkback at all if this bug aint fixed.
For Windows and basic authentication, you can use the workaround of installing The Proxomitron <http://www.proxomitron.info/> and setting it up to add the username and password. Then you set Talkback to use The Proxomitron as its proxy.
I think this bug should be nominated as a blocker. Reasons being it makes talkback ineffective in sending crash feedback from growing corporate communities using firefox across a proxy. This leads to firefox being perceived as of low quality and reduces trust because of a broken feedback mechanism. The suggested workarounds are not easy for a non technical user or rather those kind of users should not be bothered about this.
(In reply to comment #29) > I think this bug should be nominated as a blocker. > Reasons being it makes talkback ineffective in sending crash feedback from > growing corporate communities using firefox across a proxy. > This leads to firefox being perceived as of low quality and reduces trust > because of a broken feedback mechanism. > The suggested workarounds are not easy for a non technical user or rather those > kind of users should not be bothered about this. > Nominated as blocking 220.127.116.11
we get plenty of talkback data (so much that we generally drown), try runsocks from nec w/ a socks proxy and see if talkback works there.
This is not going to block 18.104.22.168. It probably won't block any other soon to be releases version of Firefox either. We simply don't have the resources to hack Talkback at this time, so please use the few workarounds mentioned in this bug or disable Talkback (easy to do now that it is installed as an extension). I apologize for those having problems with proxies, but we are trying out best to get the most use out of Talkback. We are entertaining the possibility of upgrading the Talkback Server, so I will look into whether a Client update will be possible (which *might* fix some of the issues we have been seeing for a long time).
Flags: blocking22.214.171.124? → blocking126.96.36.199-
Target Milestone: --- → Future
Jay, any changes to fix this issue is welcome(the sooner the better). timeless, despite the numerous crashes reported via talkback I think there is a significant lot going unreported. This may lead to false sense of stability of major releases and a illusion that we have got all the info needed to fix the major crashes.
oh cut it out. how about trying my solution (comment 31) instead of claiming that i'm disillusioned. we have more than enough top crashers that aren't fixed to last us quite a few years. if you are actually hitting crashes on windows, then you can use http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg to get a build + debugger, and when you crash, just use !analyze -v -f that output is generally more than sufficient for most work. if you and a developer aren't able to figure out enough from that, you can use: .dump /maipwd /u /ba /c "comment" file where "comment" is some comment explaining what's going on, and file is part of a filename, e.g. c:\necko-burp-bug3000 you'd then make the resulting file available via a web server (or allpeers) and i'd retrieve it and do whatever analysis is necessary. jay: could we run a public proxy server (in the dmz) which only talks to the talkback-receptor? i think i once used the testing proxy server mozilla.org had (it was designed to emulate dialup speeds) to submit reports.
oh, and please refrain from using the word "we" when you talk about mozilla. i don't see you fixing crash bugs, nor do i see you triaging them or anything else. otoh, you're free to browse through bugzilla or bonsai or cvs and you'll see that i'm there, constantly worrying about crashes in even the smallest of components.
Talkback will work if direct connections to 188.8.131.52, TCP/80, are permitted. Even if a proxy server is needed, authentication can be disabled for connections to mothra. In Squid this can be done with an ACL: acl moz_talkback dstdomain talkback.mozilla.org http_access allow moz_talkback This would just need to be added before the acl that requires authentication. Of course, if the IT department won't help then there's not much that can be done. This doesn't solve the problem but it could be a viable workaround for some.
Hey, all! Do you REALLY think lots of IT departments in corporations will bother themselves to configure any exceptions in firewall\proxy configurations?!Then you're stupid and this will cause a dozen of crashes not detected. Personally I'm got a plenty dozen of crashes in firewalled environments.I was not able to report them, they're remained unsent.Basically I either needed to pass HTTP authorisation (often NTLM) and sometimes Socks 5 (with plaintext authentication).Neither NTLM auth on proxy nor Socks 5 is supported by TalkBack.Now imagine average corporate environment where HTTP proxy used and auth required and think about the fact that corporate users crashes will remain unreported.I'm do not understanding why Firefox itself supports this but not it's crash reporter.Maybe crash reporter can use Firefox itself to send data if no other ways available?! As for me(I'm QA in some reasonable big corporation), this bug is quite critical if you're going to create STABLE and RELIABLE application.
let's try this again since you people are being amazingly annoying and can't seem to follow what i feel are reasonable directions. steps: 1. visit http://www.socks.permeo.com/cgi-bin/download.pl 2. fill in the form and download that app 3. use that app to run talkback 4. tell me if it works. if it does, stop complaining.
I also happen to have occasional crashes that I'm unable to report due to this issue. I have seen the suggested work-arounds requiring changes to the internet proxy configuration, but they aren't going to work for our corporate infrastructure. Not for technical reasons but because of company policy. If a corporate IT department officially supports Firefox they might be willing to do something to make talkback work. But at least in our case, the corporate standard is IE; users can use other browsers but they're on their own. FYI, we have a cascaded configuration of webwasher and squid as internet proxy, which uses basic authentication. We will probably migrate to an NTLM-based solution in the coming year. Our IT department is not going to disable authentication for Firefox talkback. They are also not going to allow some direct connection. An alternative solution would be to have Firefox check for crashdumps on startup and ask the user if they should be uploaded to the talkback server. But as has been mentioned before, if Firefox already handles authenticating proxies just fine, it is just awkward to see that its talkback tool doesn't. The only work-around I could still try is using proximitron, although that would require me to set it up only to get the talkback to work. Probably feasible but it remains a cumbersome workaround only workable for knowledgeable users. Using windbg is even worse, what user is going to do all that to report a bug (assuming the corporate user is allowed to install Windbg on his PC)? They just restart Firefox and forget about it. I must say I have some difficulty to understand why some people consider this to be low-priority. Authenticating proxies are very common in corporate environments, and if the effort for implementing a workaround for this talkback problem is somewhere inbetween laborious and impossible there won't be much feedback from those environments... The question whether talkback reports that are currently lost would report new problems not already reported by other users is probably difficult to answer. Is it acceptable to lose talkback reports since the problems already have a high probability of being reported by other users ? If so, just make such a statement and close this bug. Are the reports being lost considered important? Then it makes sense to increase the priority of this problem. In any case, leaving it as is will cause the discussion to continue...
i consider this a low priority because there's only one engineer with any access to talkback sources, and he has dozens of more important things to do. and i look through just about every crash mozilla.org gets, we get plenty of reports. i also consider this a low priority because people repeatedly ignore my suggesed workarounds. if one of them works (especially the socks one i repeatedly mention) we could probably fairly easily *ship* talkback with that app and include instructions for configuring it so that people would stop having this problem. and until we started shipping it, I could update the release notes to include that suggestion. note that talkback is closed source under its own special license, we can't simply teach firefox how to read the talbkack files or how to talk to the talkback server.
Everyone: Please understand that this is not a problem that mozilla is going to be able to solve any time soon. There are many other higher priority things to deal with right now and fixing Talkback bugs (no matter how annoying or limiting they are) is not on that list at the moment. Know that we will *try* to address issues like this when the time is right, but for now you must rely on known workarounds or disable Talkback. Yes it sucks that we won't be getting crash data from corporate environments that use authenticating proxies... but we have millions of users out there that are not using proxies, and they send us plenty of good crash data. We currently have over 3 million incidents in the Talkback DB (roughly the past 3 months worth of crashes). I'm fairly confident that most crashes corporate users behind proxies are seeing are represented well in whatever data we are getting, so this problem is not going to be a show stopper for us. That doesn't mean that your crashes won't get fixed. We work hard to fix as many topcrashers as we can from release to release, and our products are getting more stable every day. So please continue to enjoy Firefox and Thunderbird, and pick one of the following options to make your life a bit easier and carefree: 1. Disable Talkback - Simply disable the extension and you won't have to worry about whether a crash will be submitted or not through a proxy or a direct connection! :-) 2. Try a workaround to see if one works for you. There are two reasonable ways to get your Talkback data submitted: a. comment #38 (socks proxy) or comment #34 (windbg) b. comment #28 (http://www.proxomitron.info/) I appreciate everyone's concern about getting good data from every type of user, but it's just not going to happen anytime soon. Sorry.
This begins to look a bit like Microsoft.They do not like to fix issues even if these are bothering or allow to compromise system, this looks in similar way :).Sorry for such reminder... It is just interesting for me, if guys are talking they they are aware of all crashes, etc... why my girlfriend got THREE crashes just recently?Today it is version 184.108.40.206 which is far away from alfa and beta and even from 1.0.However crashes are still here.Why??I'm do not like to feel myself sorry just because I'd recommended some software to others and it sometimes works poorly for them :( (I have to admit I did not had crashes myself for couple of months though.So, really some crashes are fixed...)
Yay, My Firefox finally crashed. I tried Comment 38 but it dint work. I also tried a program called HTTP-Tunnel which again dint work with talback. what worked was Proxomitron though after a while figuring out how to set it up to connect to our proxy with authentication(Note: the proxy authentication settings comes up only by right clicking the proxy entry textbox) Generated Talkback ID: TB20353855Y
(In reply to comment #43) > Yay, My Firefox finally crashed. I tried Comment 38 but it dint work. I also > tried a program called HTTP-Tunnel which again dint work with talback. > what worked was Proxomitron though after a while figuring out how to set it up > to connect to our proxy with authentication(Note: the proxy authentication > settings comes up only by right clicking the proxy entry textbox) > > Generated Talkback ID: TB20353855Y > Here is a link to a short description of using Proxomitron with talkback. http://www.pradeepkumar.net/2006/06/28/MozillaTalkbackProxyAuthenticationIssueP2Solution.aspx
Talkback is dead.
Status: NEW → RESOLVED
Closed: 18 years ago → 12 years ago
Resolution: --- → INVALID
(In reply to comment #46) > Talkback is dead. OK, but what about the other 142 Talckback bugs? (http://tinyurl.com/l4jszv)
I suggest this is rather a duplicate of the new bug on the same topic for the replacement of talkback: Breakpad (cf bug 430469).
Resolution: INVALID → DUPLICATE
Duplicate of bug: 430469
You need to log in before you can comment on or make changes to this bug.