Thus spake Mike Perry (mikeperry@xxxxxxxxxx): > > If you have any pointers on how to achieve proxy-per-tab, I'd be > > grateful to hear them. I've asked in mozilla.dev.extensions, > > mozilla.dev.tech.network, IRC, as well as some prominent Firefox and > > SeaMonkey developers (Christian Biesinger, Benjamin Smedberg, Philip > > Chee, Michael Vincent Van Rantwijk, etc.) Christian Biesinger and > > Michael Vincent Van Rantwijk had some ideas which eventually panned > > out. > > Yeah, unfortunately despite Mozilla's impressively extensive work > making almost every browser behavior into scriptable, contractable > components, most Firefox APIs suffer from a particularly annoying > aspect of braindamage: They almost never provide the context of the > browser window, tab, and/or DOMWindow that they are happening in. As > I'm sure you're aware, you have to bend over backwards in all sorts of > weird ways to get this sort of info without falling prey to various > race conditions and window focus issues (for example, almost all of > the mozilla documentation gives example code to get the currently > FOCUSED navigator window, calling it the "most recent window", but > this is not the actual one that just performed whatever network IO or > action caused your API hook/callback to be called).. > > My guess is your problems arise from this issue being the case with > nsIProtocolProxyFilter, right? My suggestion would be recording this > context from somewhere that recieves the event first and making a > cache. Torbutton does this with its content-window-mapper: > https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/window-mapper.js > > That component may be helpful for you to use as a starting point to > map DOMWindows to tabbrowsers, but you probably need another layer for > URLs themselves. Probably you want to go with a dummy > nsIContentPolicy that gets the window for a URL fetch (see > https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/cssblocker.js > for how torbutton does this), then use the torbutton window mapper to > map this to a tabbrowser, then use your own custom component to map > that URL to that tabbrowser.. > > If you are real lucky, your nsIContentPolicy will always be called > before your nsIProtocolProxyFilter, and thus your URL->tabbrowser > mapper will always have the correct (and most recent/current) > tabbrowser, which you would then use to look up the appropriate proxy > in your filter based on the tabbrowser's contentWindow.top.location > URL instead of the one handed to nsIProtocolProxyFilter.applyFilter. > > If you are no so lucky wrt to the ordering of those two interface > calls, perhaps the doc loader service can provide you with similar > context information that you can cache, but its unclear if this will > give you ALL url evens like the content policy will: > http://www.xulplanet.com/references/xpcomref/comps/c_docloaderservice1.html Oh, I should probably also mention that of course this approach has its own fun race conditions that need to be addressed. For example, say you trust washingtonpost.com but not foxnews.com, but both source an ad from doubleclick.net. There is then a race between which tab fetches the URL, potentially transmitting cookies for both. You can try to fix this with some kind of priority system, where tor windows always cause their URLs to replace old entries in the cache but lower priority fetches cannot expire the entries placed by Tor or corporate security proxies. I still have no idea how you would handle the cookie jars per tab, cache per tab, history attributes per tab, user agent per tab, and many of the other security features the Torbutton dev provides though... You might be able to handle cookies and user agent per tab by manually creating the headers yourself a-la refspoof (which uses nsIHttpChannel and nsIRequestObserver I believe).. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpbdAXs1sevx.pgp
Description: PGP signature