InformAction Forums

Fx 3.6.0, NS 1.9.9.47, new profile, defaults

1. run a local web server on a non standard port (8080)
2. add "127.0.0.1 a.b.c" to the hosts file
3. create a page with some script and load it (http://a.b.c:8080/page.html)
4. NS menu offers to allow b.c (Is this correct? Is b.c intended to cover every port? It doesn't. What should it show?)
5. (temp) allow b.c
6. b.c is added to the whitelist, page reloads, but is not allowed
7. now the menu presents the full address (http://a.b.c:8080) to allow, allow it
8. this time the page is allowed
9. if you now forbid http://a.b.c:8080, the full address is removed but b.c remain in the whitelist

The bug is http://a.b.c:8080 not being shown on first round.
Will be fixed in next release.

Giorgio Maone wrote:The bug is http://a.b.c:8080 not being shown on first round.

What about b.c and a.b.c (if full domain is checked)? Why should those appear, since they don't allow the page?

al_9x wrote:

Giorgio Maone wrote:The bug is http://a.b.c:8080 not being shown on first round.

What about b.c and a.b.c (if full domain is checked)? Why should those appear, since they don't allow the page?

No they shouldn't. Check what happens with http://127.0.0.1:8080 or http://localhost:8080 for reference.

Fixed in 1.9.9.49.
Partial correction to what I stated above: an URL with port is temporarily and automatically added to the whitelist as it's loaded ifits "no port" version matches the whitelist, unless you set the noscript.ignorePorts about:config preference to false.
However if you manually forbid it, it's not automatically reallowed until next session (or never, if you mark it as untrusted).

Giorgio Maone wrote:Fixed in 1.9.9.49.
Partial correction to what I stated above: an URL with port is temporarily and automatically added to the whitelist as it's loaded ifits "no port" version matches the whitelist, unless you set the noscript.ignorePorts about:config preference to false.
However if you manually forbid it, it's not automatically reallowed until next session (or never, if you mark it as untrusted).

I think there are still issues here (ignorePorts=true)

1) symmetry/reversibility - without ports, if you allow b.c (of a.b.c) you are given the same (b.c) to forbid. With ports, if you allow b.c (of a.b.c:8080) you are given http://a.b.c:8080 to forbid. Why? That's not what you allowed.

Forbidding http://a.b.c:8080, does not reverse your previous allow, b.c is still allowed

2) repeatability - after forbidding http://a.b.c:8080, allowing b.c no longer allows the page. This does not feel like a feature (However if you manually forbid it, it's not automatically reallowed until next session) Why does behavior change? Why is b.c still in the menu if it won't allow the page?

al_9x wrote: 1) symmetry/reversibility - without ports, if you allow b.c (of a.b.c) you are given the same (b.c) to forbid. With ports, if you allow b.c (of a.b.c:8080) you are given http://a.b.c:8080 to forbid. Why? That's not what you allowed.
Forbidding http://a.b.c:8080, does not reverse your previous allow, b.c is still allowed

Fair enough. If ignorePorts=true, I probably want to know as little as possible about implementation details, therefore a.b.c:8080 shouldn't be shown unless full addresses are selected for display.

al_9x wrote: 2) repeatability - after forbidding http://a.b.c:8080, allowing b.c no longer allows the page. This does not feel like a feature (However if you manually forbid it, it's not automatically reallowed until next session) Why does behavior change? Why is b.c still in the menu if it won't allow the page?

This should be fixed, i.e. manually allowing b.c/a.b.c on a http://a.b.c:8080 should allow it, no matter if you manually forbid it.

Giorgio Maone wrote:

al_9x wrote: 1) symmetry/reversibility - without ports, if you allow b.c (of a.b.c) you are given the same (b.c) to forbid. With ports, if you allow b.c (of a.b.c:8080) you are given http://a.b.c:8080 to forbid. Why? That's not what you allowed.
Forbidding http://a.b.c:8080, does not reverse your previous allow, b.c is still allowed

Fair enough. If ignorePorts=true, I probably want to know as little as possible about implementation details, therefore a.b.c:8080 shouldn't be shown unless full addresses are selected for display.

I gave up on this. Due to the subtle inconsistencies in CAPS matching/enforcing, trying to hide these details resulted in even more confusing behaviors. I won't touch it anymore (i.e., if non-standard ports are involved, full address will be shown for maximum clarity).

Giorgio Maone wrote: manually allowing b.c/a.b.c on a http://a.b.c:8080 should allow it, no matter if you manually forbid it.

This is more or less fixed in latest development build, i.e. if you allow a web site manually, auto-allow prevention is relaxed for its descendants including non-standard port URLs.

In .51 ignorePorts=true behaves the same as false, only the full address is shown, is that the intended behavior?

al_9x wrote:In .51 ignorePorts=true behaves the same as false, only the full address is shown, is that the intended behavior?

Yes, it is. The main point of ignorePorts=true is that if you previously allowed the domain, URLs with that domain but a non-standard port are allowed on the fly automatically when met.
Otherwise the standard CAPS behavior (coming essentially from a parsing glitch) applies, i.e. allowing a domain doesn't affect non-standard port URLs.

al_9x wrote:In .51 ignorePorts=true behaves the same as false, only the full address is shown, is that the intended behavior?

Yes, it is. The main point of ignorePorts=true is that if you previously allowed the domain, URLs with that domain but a non-standard port are allowed on the fly automatically when met.
This is meant as a work-around to the standard CAPS behavior (coming essentially from a parsing glitch), i.e. allowing a domain doesn't affect non-standard port URLs.

I guess there's been a change. Now with ignorePorts=false, http://a.b.c:0 and http://a.b.c:8080 are shown. Is that expected? Allowing http://a.b.c:0 appears to be the same as allowing b.c when ignoreports is true, so is there a need for http://a.b.c:0? Perhaps it would be better not to show http://a.b.c:0

This reintroduces the problems I brought up.

1) lack of symmetry/reversibility - if you allow http://a.b.c:0, you are offered http://a.b.c:8080 to forbid. Forbidding http://a.b.c:8080, leaves http://a.b.c:0 in the whitelist

2) repeatability - after forbidding http://a.b.c:8080 and removing http://a.b.c:0, allowing :0 no longer allows :8080. Though by design, this feels like a bug, it's not obvious why something that worked once, stops. And why show :0 if it won't make a difference?

al_9x wrote: Perhaps it would be better not to show http://a.b.c:0

Yes it would.
I was actually tempted to drop the "ignorePorts=false" branch entirely, since the default is much more intuitive, but I restrained myself not to break legacy whitelists.

Giorgio Maone wrote:I was actually tempted to drop the "ignorePorts=false" branch entirely

I think it's good that you didn't. In hosted sites, content on another port, likely has a different origin/owner than the app you've granted trust, in which case it's not a good idea for permissions to auto propagate to it. I won't argue about defaults, but ignorePorts=false should remain and probably deserves ui.