InformAction Forums

Posted: **Sat Mar 26, 2011 7:16 pm**

Recently, I noticed that a USER ABE rule seems to have changed behaviour. The ruleset is

Site */omniture/s_code.js
Accept from *.fnfg.com fnfg.com
Deny
Site */s_code.js
Deny

This ruleset is meant to deny execution of the Omniture "s_code.js" tracking script, while allowing such on a single site ("fnfg.com") (a bank). I recently noticed that the site https://myservices.timewarnercable.com/ had added

Code: Select all

https://myservices.timewarnercable.com/js/omniture/s_code.js

and the error console does not reflect the ABE rule blocking message. I updated the ruleset to

Code: Select all

Site */js/omniture/s_code.js
Accept from *.fnfg.com fnfg.com
Deny
Site */omniture/s_code.js
Accept from *.fnfg.com fnfg.com
Deny
Site */s_code.js
Deny

and the error console reflected

Code: Select all

[ABE] <*/js/omniture/s_code.js> Deny on {GET https://myservices.timewarnercable.com/js/omniture/s_code.js <<< https://myservices.timewarnercable.com/, https://myservices.timewarnercable.com/ - 2}
USER rule:
Site */js/omniture/s_code.js
Deny

which was the desired effect.

Was I incorrect in my understanding of the leading "*/" in the ruleset ? I had understood that "*/s_code.js" would block any URL not specifically allowed, using right-to-left priorities ("s_code.js" would be blocked regardless of the depth of sub-directory nesting. Should that not be the case, my ABE ruleset would need to be updated for the various forms of this code used in different sites.

Posted: **Sun Mar 27, 2011 8:53 pm**

NS turns these patterns into RXs, which you can examine (eval the following in error console, substituting your pattern for {pattern}):

Code: Select all

Components.classes["@maone.net/noscript-service;1"].getService().wrappedJSObject.__parent__.eval("new AddressMatcher('{pattern}').rx")

and test:

Code: Select all

Components.classes["@maone.net/noscript-service;1"].getService().wrappedJSObject.__parent__.eval("new AddressMatcher('{pattern}').test('{url}')")

"*/s_code.js" produces "/^[a-z]\w+:\/\/[^\/]*?\/s_code\.js$/"

which shows that when you are specifying a path pattern, you have to match the first / in the path. Not sure this is deliberate, Giorgio?
so "*/js/omniture/s_code.js" will work, and also "*/*/s_code.js"

I don't think (all the nuances of) AddressMatcher behavior is clearly specified in NS docs, so when in doubt you can try to use RXs directly:

Code: Select all

Site ^.*/s_code.js$
Deny

Posted: **Sun Mar 27, 2011 9:34 pm**

al_9x wrote: Not sure this is deliberate, Giorgio?

It is, so you can specify an absolute path on any domain.

First aster matches domain only, second aster matches path and anchors the next string to the right, unless another aster is found.

al_9x wrote:so "*/js/omniture/s_code.js" will work, and also "*/*/s_code.js"

**/s_code.js will work as well, and will match any path before s_code.js.

Posted: **Sun Mar 27, 2011 10:13 pm**

Giorgio Maone wrote: **/s_code.js will work as well, and will match any path before s_code.js.

Spot on! That reduces a rather cumbersome ruleset to:

Code: Select all

Site **/s_code.js
Accept from *.fnfg.com fnfg.com
Deny

Should I come upon other sites that need this, a single "Accept" is all that is needed!

Thank you Al and Giorgio !

Posted: **Sun Mar 27, 2011 10:17 pm**

SeanM wrote:
Giorgio Maone wrote: Spot on! That reduces a rather cumbersome ruleset to:
Code: Select all
Site **/s_code.js
Accept from *.fnfg.com fnfg.com
Deny

You can further reduce it thanks to (*.fnfg.com fnfg.com) = .fnfg.com:

Code: Select all

Site **/s_code.js
Accept from .fnfg.com
Deny

InformAction Forums

ABE Script-blocking

ABE Script-blocking

Re: ABE Script-blocking

Re: ABE Script-blocking

Re: ABE Script-blocking

Re: ABE Script-blocking