luop90 / scriptno

Automatically exported from code.google.com/p/scriptno
0 stars 0 forks source link

trusting with wildcard doesn't work for lower domain levels #31

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.go to scriptno options.
2.scroll to the whitelist section and enter a domain with a wildcard that has 
more than one dot (e.g. *.tau.ac.il) and press "+ Whitelist".
3.go to a page under a sub-domain for the domain inserted before (e.g. 
www.cs.tau.ac.il).

What is the expected output? What do you see instead?
scripts are blocked for this domain. they should be allowed...

What version of the product are you using? On what operating system?
scriptno 1.0.5.49
Windows 7 64-bit

Please provide any additional information below.
using the "trust" button for a page under the domain i gave as an example (like 
www.cs.tau.ac.il) will add "*.ac.il" to the whitelist. any page hosted under 
any acaedmic domain in il will be allowed.
it would be nice (supposing the said issue is fixed) if the trust button will 
let you select different levels of trust (e.g. let you select between 
*.cs.tau.ac.il, *.tau.ac.il and *.ac.il).

Original issue reported on code.google.com by gal...@gmail.com on 18 Nov 2011 at 4:50

GoogleCodeExporter commented 9 years ago
Reproduced; and agreed, more granular control over domain trusting is 
advantageous.

This will mean a pretty substantial rewrite of the logic to accommodate this 
(and to determine whether or not a current page should be allowed/blocked), but 
I will work on this soon.

Original comment by andr...@gmail.com on 1 Dec 2011 at 9:45

GoogleCodeExporter commented 9 years ago
Issue 56 has been merged into this issue.

Original comment by andr...@gmail.com on 15 Feb 2012 at 5:56

GoogleCodeExporter commented 9 years ago
Issue 54 has been merged into this issue.

Original comment by andr...@gmail.com on 15 Feb 2012 at 3:38

GoogleCodeExporter commented 9 years ago
Issue 93 should be merged.

Original comment by petteyg359@gmail.com on 11 Sep 2012 at 3:59

GoogleCodeExporter commented 9 years ago
I have the same problem, also the following functionality would be very 
helpfull: i need to allow something like abcdef.c.yout.com, and not to allow 
scripts from the next level abcd.abcdef.c.yout.com. If probably doesn't have to 
affect "trust" functionality (to trust any lower level domain). But if not 
trusted every domain level should be added in consecutive order, if scripts 
from the higher level access some on the lower level, sould be blocked by 
default, even if the next low level domain is on the domain already allowed. 
Also the trust functionality should be added to allow this and any lower level 
domain. Now if i add *.a.some.com to whitelist it doesn't work, also there's no 
"Trust domain" green link on the right.

Original comment by Xavo...@gmail.com on 12 Jan 2013 at 4:30

GoogleCodeExporter commented 9 years ago
Each Youtube video now references a couple of cache servers (*.c.youtube.com).  
I do not want to whitelist the entire youtube.com domain but rather just 
*.c.youtube.com.

Original comment by jorge.el...@gmail.com on 21 Jan 2013 at 3:46

GoogleCodeExporter commented 9 years ago
I agree that multi-level wildcards would be great:

For example, I need to trust *.unch.unc.edu, but not trust *.unc.edu.

Original comment by donb...@gmail.com on 5 Feb 2013 at 7:12

GoogleCodeExporter commented 9 years ago
Still open issue and from my opinion, quite important from advanced usability 
perspective.
As an side note, having this functionality as GUI element to create advanced 
rules would be very cool as well, i.e. if path is 1.sub.example.com, it would 
be cool to allow either *.sub.example.com or *.example.com, without leaving the 
open page (going into options), maybe current "resouces list" is place, where 
this could be added, besides, if there are multiple blocked resources i.e. 
1.example.com and 2.example.com, they could be grouped in the resource list, 
allowing 1-click decision on the whole sub-domain.

Original comment by kork...@gmail.com on 1 Dec 2014 at 12:16