InformAction Forums

sourcejedi wrote: and the C code relies on that:

http://mxr.mozilla.org/mozilla-central/ ... el.cpp#541
requestURI = &mSpec;

mSpec must be a private copy of channel.URI.spec. I guess it gets set before NoScript changes the URI. And this line is specific to the proxy case.

Indeed the XSS filter, which uses the same request modification pattern, has a specific method (significantly called proxyHack()) to force the new URI to be used also in the proxied case.

In all the most recent places where a request modification was required, I used another (less risky, but far more complex and yet hackish) way, i.e. my ChannelReplacement class, which produces an internal fake redirection and therefore has no immutability violation issue.

Unfortunately the escape_fragment feature, which was not security-critical and has been coded in a fairly relaxed and quick mood, fell back to the simplest but less correct approach and forgot about the proxyHack() thing, hence the problem at hand.

Since I'm here, rather than adding another hack I'm turning both instances to the ChannelReplacement approach -- something which was postponed for a long time because of backward compatibility concerns.

Thanks for finding out the root cause of this issue.

Awesome, thanks.

sourcejedi wrote:Awesome, thanks.

Please check latest development build 2.2.2rc2.

Dev build 2.2.2rc2 fixes twitter access through a HTTP proxy when twitter is not whitelisted. Thanks.

Issues #1 and #3 identified by al_9x are still valid. [Issue #4 is what's just been fixed].

Issue #2 is probably a red herring. al_9x points out that the undesired fragment is preserved across 301 redirect. But that happens without NoScript anyway, if I clear cookies and disable javascript. Visiting <http://twitter.com/?_escaped_fragment_= ... PostDeskUK>, I am redirected to <http://twitter.com/PostDeskUK#!/PostDeskUK>.


Issue #1 might only be "cosmetic", but it'd be nice to fix given how ugly the "ugly" URLs are.

Ideal sequence:
http://twitter.com/#!/PostDeskUK
=> NoScript =>
http://twitter.com/?_escaped_fragment_=/PostDeskUK
=> 301 redirect =>
http://twitter.com/PostDeskUK

Actual sequence:
<http://twitter.com/#!/PostDeskUK>
=> NoScript =>
<http://twitter.com/?_escaped_fragment_= ... PostDeskUK>
=> 301 redirect + NoScript =>
<http://twitter.com/PostDeskUK?_escaped_ ... PostDeskUK>

(In the last step, the query string doesn't come from the redirect. It's NoScript adding it back because there's still a #! in the URL).

sourcejedi wrote:Issue #2 is probably a red herring. al_9x points out that the undesired fragment is preserved across 301 redirect. But that happens without NoScript anyway, if I clear cookies and disable javascript. Visiting <http://twitter.com/?_escaped_fragment_= ... PostDeskUK>, I am redirected to <http://twitter.com/PostDeskUK#!/PostDeskUK>.

issue #2 is not about the preservation of the hash fragment, but the invalid preservation of the query string. Your own test confirms my point, without NS, http://twitter.com/?_escaped_fragment_=/PostDeskUK is redirected to http://twitter.com/PostDeskUK, but with NS, the request after the redirect is to http://twitter.com/PostDeskUK?_escaped_ ... PostDeskUK, the original query string is tacked on to the 301 url.

<facepalm>. Yes, #2 is valid (and I think caused by #1).

sourcejedi wrote:and I think caused by #1.

Yes, since the hash fragment is kept and redirect removes the escaped fragment, the resulting url (http://twitter.com/PostDeskUK#!/PostDeskUK) is fragment escaped again by NS. Giorgio, are you keeping the fragment for the sake of unescaping on permission toggle and refresh?

al_9x wrote:Giorgio, are you keeping the fragment for the sake of unescaping on permission toggle and refresh?

Exactly. I need a way to mark a certain ?_escapedFragment_ URL as generated by NoScript, rather than intentionally created by a web author for unknown reasons, and therefore a candidate for unescaping on permissions change.