[RESOLVED] ice.net (ice.no)

[Tom T.]

Can't get some parts of the support pages at http://kundeservice.ice.no/Privat/Kunde ... gsvar.aspx to work. Each question is clickable and will scroll down more text, but with noscript enabled that don't work. I have to disable the addon completely to make this site work properly.

I know this is a Norwegian site, but I hope someone might know how to make it work.

Thank you.

[Gazer75]

Seems this site cant handle some links so trying again with url and code...
http://kundeservice.ice.no/Privat/Kundeservice/Sp%C3%B8rsm%C3%A5logsvar.aspx

Code: Select all

http://kundeservice.ice.no/Privat/Kundeservice/Sp%C3%B8rsm%C3%A5logsvar.aspx

[Tom T.]

The issue with long URLs being broken has been discussed, and appears to be a phpBB issue. You have the correct solutions: URL tags or code tags.

Reproduced on both Fx 3.6.27 and 10.0.02 with NS 2.3.4rc1.
Temp-allowed ice.no.

Sample page:

Code: Select all

http://kundeservice.ice.no/Privat/Kundeservice/Sp%C3%B8rsm%C3%A5logsvar/TeknisksupportWlanR90.aspx

The list of topics displays, but clicking either the + sign or the topic does nothing.

Giorgio?

[Giorgio Maone]

The Google Analytics surrogate seems to be broken, working on that.
Temporarily allowing google-analytics.com works for me, though (the FAQ revealing script tries to record which item you're opening through GA).
Check also ABP and RequestPolicy, which may be blocking GA as well.

[Giorgio Maone]

Restored Surrogates functionality in latest development build 2.4.5rc3 (you can forbid google-analytics.com again, now).

[Tom T.]

Restored Surrogates functionality in latest development build 2.4.5rc3 (you can forbid google-analytics.com again, now).

Confirmed the site works now in both Fx 3.6.28 and 11.0, but with a strange twist:

1) GA is Untrusted in NS, *and* blocked in HOSTS and RequestPolicy.
Result: page is broken.

2) TA requests from site to GA in RP; keeping it blocked in NS and Hosts
Result: site works.

Toggling the permission in RP toggles the symptom, even though it can't call anywhere due to hosts blocking.

Please refresh my memory on the order of processing between NS and RP, sorry.
Is it necessary to TA GA in RP to fool the site into thinking GA ran vs. (locally-supplied) surrogate?
Is it necessary to allow this request in RP for the surrogate to run in the first place?

Thanks, Giorgio.

[Giorgio Maone]

Please refresh my memory on the order of processing between NS and RP, sorry.

By default, NS comes always the last: this was introduced years ago to allow ABP users to see stuff blocked later by NoScript among ABP's "Blockable objects".
This is controlled by the noscript.cp.last about:config preference: if you turn it to false, content policy execution order will depend on component registration order, which isn't always obvious.

[Tom T.]

Please refresh my memory on the order of processing between NS and RP, sorry.

By default, NS comes always the last: this was introduced years ago to allow ABP users to see stuff blocked later by NoScript among ABP's "Blockable objects".
This is controlled by the noscript.cp.last about:config preference: if you turn it to false, content policy execution order will depend on component registration order, which isn't always obvious.

Thank you.

Confirming that I understand correctly: In the default configuration, I must TA or allow in RequestPolicy requests to G-A, so that RP will allow this to get to where NS sees it, whereupon NS runs the surrogate. Correct?

And the Hosts blocking is irrelevant to the above, because the original request is internally processed through RP to NS, which runs the locally-stored surrogate, thus never triggering a (Hosts or DNS) lookup to G-A. Correct?

If I have that right, then I understand the need to allow G-A in RP. Many thanks.

[Giorgio Maone]

Confirming that I understand correctly: In the default configuration, I must TA or allow in RequestPolicy requests to G-A, so that RP will allow this to get to where NS sees it, whereupon NS runs the surrogate. Correct?

And the Hosts blocking is irrelevant to the above, because the original request is internally processed through RP to NS, which runs the locally-stored surrogate, thus never triggering a (Hosts or DNS) lookup to G-A. Correct?

If I have that right, then I understand the need to allow G-A in RP.

Everything correct.

[Tom T.]

TUVM, for both the surrogate fix and the very useful information. Marking as Resolved.