[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
|
|
|
|
|
|
uBlock Origin Lite - a comprehensive, MV3-compliant content blocker
|
|
|
|
|
Copyright (C) 2014-present Raymond Hill
|
|
|
|
|
|
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
along with this program. If not, see {http://www.gnu.org/licenses/}.
|
|
|
|
|
|
|
|
|
|
Home: https://github.com/gorhill/uBlock
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
const validActionValues = [
|
|
|
|
|
'block',
|
|
|
|
|
'redirect',
|
|
|
|
|
'allow',
|
|
|
|
|
'upgradeScheme',
|
|
|
|
|
'modifyHeaders',
|
|
|
|
|
'allowAllRequests',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
const validBoolValues = [
|
|
|
|
|
'false',
|
|
|
|
|
'true',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
const validHeaderOpValues = [
|
|
|
|
|
'append',
|
|
|
|
|
'remove',
|
|
|
|
|
'set',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
const validDomainTypeValues = [
|
|
|
|
|
'firstParty',
|
|
|
|
|
'thirdParty',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
const validRequestMethodValues = [
|
|
|
|
|
'connect',
|
|
|
|
|
'delete',
|
|
|
|
|
'get',
|
|
|
|
|
'head',
|
|
|
|
|
'options',
|
|
|
|
|
'patch',
|
|
|
|
|
'post',
|
|
|
|
|
'put',
|
|
|
|
|
'other',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
const validResourceTypeValues = [
|
|
|
|
|
'main_frame',
|
|
|
|
|
'sub_frame',
|
|
|
|
|
'stylesheet',
|
|
|
|
|
'script',
|
|
|
|
|
'image',
|
|
|
|
|
'font',
|
|
|
|
|
'object',
|
|
|
|
|
'xmlhttprequest',
|
|
|
|
|
'ping',
|
|
|
|
|
'csp_report',
|
|
|
|
|
'media',
|
|
|
|
|
'websocket',
|
|
|
|
|
'webtransport',
|
|
|
|
|
'webbundle',
|
|
|
|
|
'other',
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
function selectParser(scope, rule, node) {
|
|
|
|
|
const parser = perScopeParsers[scope.join('.')];
|
|
|
|
|
if ( parser === undefined ) { return false; }
|
|
|
|
|
return parser(scope, rule, node);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const perScopeParsers = {
|
|
|
|
|
'': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'action':
|
|
|
|
|
case 'condition':
|
|
|
|
|
if ( val !== undefined ) { return false; }
|
2025-05-30 22:15:25 +00:00
|
|
|
rule[key] = {};
|
|
|
|
|
scope.push(key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
2025-06-13 16:46:05 +00:00
|
|
|
case 'id': {
|
|
|
|
|
const n = parseInt(val, 10);
|
|
|
|
|
if ( isNaN(n) || n < 1) { return false; }
|
|
|
|
|
rule.id = n;
|
|
|
|
|
break;
|
|
|
|
|
}
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
case 'priority': {
|
|
|
|
|
const n = parseInt(val, 10);
|
2025-06-13 16:46:05 +00:00
|
|
|
if ( isNaN(n) || n < 1 ) { return false; }
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
rule.priority = n;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'type':
|
|
|
|
|
if ( validActionValues.includes(val) === false ) { return false; }
|
|
|
|
|
rule.action.type = val;
|
|
|
|
|
break;
|
|
|
|
|
case 'redirect':
|
|
|
|
|
rule.action.redirect = {};
|
|
|
|
|
scope.push('redirect');
|
|
|
|
|
break;
|
|
|
|
|
case 'requestHeaders':
|
|
|
|
|
case 'responseHeaders':
|
2025-05-30 22:15:25 +00:00
|
|
|
rule.action[key] = [];
|
|
|
|
|
scope.push(key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.redirect': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'extensionPath':
|
|
|
|
|
case 'regexSubstitution':
|
2025-05-30 22:15:25 +00:00
|
|
|
case 'url':
|
|
|
|
|
rule.action.redirect[key] = val;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
case 'transform':
|
|
|
|
|
rule.action.redirect.transform = {};
|
|
|
|
|
scope.push('transform');
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.redirect.transform': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'fragment':
|
|
|
|
|
case 'host':
|
|
|
|
|
case 'path':
|
|
|
|
|
case 'port':
|
|
|
|
|
case 'query':
|
|
|
|
|
case 'scheme': {
|
|
|
|
|
if ( val === undefined ) { return false; }
|
|
|
|
|
rule.action.redirect.transform[key] = val;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case 'queryTransform':
|
|
|
|
|
rule.action.redirect.transform.queryTransform = {};
|
|
|
|
|
scope.push('queryTransform');
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.redirect.transform.queryTransform': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
if ( val !== undefined ) { return false; }
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'addOrReplaceParams':
|
|
|
|
|
case 'removeParams':
|
2025-05-30 22:15:25 +00:00
|
|
|
rule.action.redirect.transform.queryTransform[key] = [];
|
|
|
|
|
scope.push(key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.redirect.transform.queryTransform.addOrReplaceParams': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.action.redirect.transform.queryTransform.addOrReplaceParams.push({});
|
|
|
|
|
scope.push('@');
|
|
|
|
|
return selectParser(scope, rule, node);
|
|
|
|
|
},
|
|
|
|
|
'action.redirect.transform.queryTransform.addOrReplaceParams.@': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
if ( val === undefined ) { return false; }
|
|
|
|
|
const item = rule.action.redirect.transform.queryTransform.addOrReplaceParams.at(-1);
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'key':
|
|
|
|
|
case 'value':
|
2025-05-30 22:15:25 +00:00
|
|
|
item[key] = val;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
case 'replaceOnly':
|
|
|
|
|
if ( validBoolValues.includes(val) === false ) { return false; }
|
|
|
|
|
item.replaceOnly = val === 'true';
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.redirect.transform.queryTransform.removeParams': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.action.redirect.transform.queryTransform.removeParams.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.requestHeaders': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.action.requestHeaders.push({});
|
|
|
|
|
scope.push('@');
|
|
|
|
|
return selectParser(scope, rule, node);
|
|
|
|
|
},
|
|
|
|
|
'action.requestHeaders.@': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
const item = rule.action.requestHeaders.at(-1);
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'header':
|
|
|
|
|
case 'value':
|
2025-05-30 22:15:25 +00:00
|
|
|
item[key] = val;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
case 'operation':
|
|
|
|
|
if ( validHeaderOpValues.includes(val) === false ) { return false; }
|
|
|
|
|
item.operation = val;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'action.responseHeaders': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.action.responseHeaders.push({});
|
|
|
|
|
scope.push('@');
|
|
|
|
|
return selectParser(scope, rule, node);
|
|
|
|
|
},
|
|
|
|
|
'action.responseHeaders.@': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
const item = rule.action.responseHeaders.at(-1);
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'header':
|
|
|
|
|
case 'value':
|
2025-05-30 22:15:25 +00:00
|
|
|
item[key] = val;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
case 'operation':
|
|
|
|
|
if ( validHeaderOpValues.includes(val) === false ) { return false; }
|
|
|
|
|
item.operation = val;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition': function(scope, rule, node) {
|
|
|
|
|
const { key, val } = node;
|
|
|
|
|
switch ( key ) {
|
|
|
|
|
case 'domainType':
|
|
|
|
|
if ( validDomainTypeValues.includes(val) === false ) { return false; }
|
|
|
|
|
rule.condition.domainType = val;
|
|
|
|
|
break;
|
|
|
|
|
case 'isUrlFilterCaseSensitive':
|
|
|
|
|
if ( validBoolValues.includes(val) === false ) { return false; }
|
|
|
|
|
rule.condition.isUrlFilterCaseSensitive = val === 'true';
|
|
|
|
|
break;
|
|
|
|
|
case 'regexFilter':
|
|
|
|
|
case 'urlFilter':
|
|
|
|
|
if ( val === undefined ) { return false; }
|
2025-05-30 22:15:25 +00:00
|
|
|
rule.condition[key] = val;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
case 'initiatorDomains':
|
|
|
|
|
case 'excludedInitiatorDomains':
|
|
|
|
|
case 'requestDomains':
|
|
|
|
|
case 'excludedRequestDomains':
|
|
|
|
|
case 'resourceTypes':
|
|
|
|
|
case 'excludedResourceTypes':
|
|
|
|
|
case 'requestMethods':
|
|
|
|
|
case 'excludedRequestMethods':
|
|
|
|
|
case 'responseHeaders':
|
|
|
|
|
case 'excludedResponseHeaders':
|
2025-05-30 22:15:25 +00:00
|
|
|
rule.condition[key] = [];
|
|
|
|
|
scope.push(key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
2025-06-13 16:46:05 +00:00
|
|
|
case 'tabIds':
|
|
|
|
|
rule.condition.tabIds = [];
|
|
|
|
|
scope.push('tabIds');
|
|
|
|
|
break;
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.initiatorDomains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.initiatorDomains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedInitiatorDomains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.excludedInitiatorDomains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
2025-05-29 18:33:30 +00:00
|
|
|
'condition.domains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.domains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedDomains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.excludedDomains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
'condition.requestDomains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.requestDomains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedRequestDomains': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.excludedRequestDomains.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.resourceTypes': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
if ( validResourceTypeValues.includes(node.val) === false ) { return false; }
|
|
|
|
|
rule.condition.resourceTypes.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedResourceTypes': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
if ( validResourceTypeValues.includes(node.val) === false ) { return false; }
|
|
|
|
|
rule.condition.excludedResourceTypes.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.requestMethods': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
if ( validRequestMethodValues.includes(node.val) === false ) { return false; }
|
|
|
|
|
rule.condition.requestMethods.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedRequestMethods': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
if ( validRequestMethodValues.includes(node.val) === false ) { return false; }
|
|
|
|
|
rule.condition.excludedRequestMethods.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.responseHeaders': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.responseHeaders.push({});
|
|
|
|
|
scope.push('@');
|
|
|
|
|
return selectParser(scope, rule, node);
|
|
|
|
|
},
|
|
|
|
|
'condition.responseHeaders.@': function(scope, rule, node) {
|
|
|
|
|
const item = rule.condition.responseHeaders.at(-1);
|
|
|
|
|
switch ( node.key ) {
|
|
|
|
|
case 'header':
|
|
|
|
|
if ( node.val === undefined ) { return false; }
|
|
|
|
|
item.header = node.val;
|
|
|
|
|
break;
|
|
|
|
|
case 'values':
|
|
|
|
|
case 'excludedValues':
|
2025-05-30 22:15:25 +00:00
|
|
|
item[node.key] = [];
|
|
|
|
|
scope.push(node.key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.responseHeaders.@.values': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
const item = rule.condition.responseHeaders.at(-1);
|
|
|
|
|
item.values.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.responseHeaders.@.excludedValues': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
const item = rule.condition.responseHeaders.at(-1);
|
|
|
|
|
item.excludedValues.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedResponseHeaders': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
rule.condition.excludedResponseHeaders.push({});
|
|
|
|
|
scope.push('@');
|
|
|
|
|
return selectParser(scope, rule, node);
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedResponseHeaders.@': function(scope, rule, node) {
|
|
|
|
|
const item = rule.condition.excludedResponseHeaders.at(-1);
|
|
|
|
|
switch ( node.key ) {
|
|
|
|
|
case 'header':
|
|
|
|
|
if ( node.val === undefined ) { return false; }
|
|
|
|
|
item.header = node.val;
|
|
|
|
|
break;
|
|
|
|
|
case 'values':
|
|
|
|
|
case 'excludedValues':
|
2025-05-30 22:15:25 +00:00
|
|
|
item[node.key] = [];
|
|
|
|
|
scope.push(node.key);
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedResponseHeaders.@.values': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
const item = rule.condition.excludedResponseHeaders.at(-1);
|
|
|
|
|
item.values.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
|
|
|
|
'condition.excludedResponseHeaders.@.excludedValues': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
const item = rule.condition.excludedResponseHeaders.at(-1);
|
|
|
|
|
item.excludedValues.push(node.val);
|
|
|
|
|
return true;
|
|
|
|
|
},
|
2025-06-13 16:46:05 +00:00
|
|
|
'condition.tabIds': function(scope, rule, node) {
|
|
|
|
|
if ( node.list !== true ) { return false; }
|
|
|
|
|
const n = parseInt(node.val, 10);
|
|
|
|
|
if ( isNaN(n) || n === 0 ) { return false; }
|
|
|
|
|
rule.condition.tabIds.push(n);
|
|
|
|
|
},
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
function depthFromIndent(line) {
|
|
|
|
|
const match = /^\s*/.exec(line);
|
|
|
|
|
const count = match[0].length;
|
|
|
|
|
if ( (count & 1) !== 0 ) { return -1; }
|
|
|
|
|
return count / 2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
function nodeFromLine(line) {
|
|
|
|
|
const match = reNodeParser.exec(line);
|
|
|
|
|
const out = {};
|
|
|
|
|
if ( match === null ) { return out; }
|
|
|
|
|
if ( match[1] ) {
|
|
|
|
|
out.list = true;
|
|
|
|
|
}
|
|
|
|
|
if ( match[4] ) {
|
|
|
|
|
out.val = match[4].trim();
|
|
|
|
|
} else if ( match[3] ) {
|
|
|
|
|
out.key = match[2];
|
|
|
|
|
out.val = match[3].trim();
|
|
|
|
|
if ( out.val === "''" ) { out.val = '' };
|
|
|
|
|
} else {
|
|
|
|
|
out.key = match[2];
|
|
|
|
|
}
|
|
|
|
|
return out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const reNodeParser = /^\s*(- )?(?:(\S+):( \S.*)?|(\S.*))$/;
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
function ruleFromLines(lines, indices) {
|
|
|
|
|
const rule = {};
|
|
|
|
|
const bad = [];
|
|
|
|
|
const scope = [];
|
|
|
|
|
for ( const i of indices ) {
|
|
|
|
|
const line = lines[i];
|
|
|
|
|
const depth = depthFromIndent(line);
|
|
|
|
|
if ( depth < 0 ) {
|
|
|
|
|
bad.push(i);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
scope.length = depth;
|
|
|
|
|
const node = nodeFromLine(line);
|
|
|
|
|
const result = selectParser(scope, rule, node);
|
|
|
|
|
if ( result === false ) {
|
|
|
|
|
bad.push(i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ( bad.length !== 0 ) { return { bad }; }
|
|
|
|
|
return { rule };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
export function rulesFromText(text) {
|
|
|
|
|
const rules = [];
|
|
|
|
|
const bad = [];
|
|
|
|
|
const lines = [ ...text.split(/\n\r|\r\n|\n|\r/), '---' ];
|
|
|
|
|
const indices = [];
|
|
|
|
|
for ( let i = 0; i < lines.length; i++ ) {
|
|
|
|
|
const line = lines[i].trimEnd();
|
2025-06-13 16:46:05 +00:00
|
|
|
if ( line.trim().startsWith('#') ) { continue; }
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
if ( line !== '---' && line !== '...' ) {
|
|
|
|
|
indices.push(i);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2025-06-13 16:46:05 +00:00
|
|
|
// Discard leading empty lines
|
|
|
|
|
while ( indices.length !== 0 ) {
|
|
|
|
|
const s = lines[indices[0]].trim();
|
|
|
|
|
if ( s.length !== 0 ) { break; }
|
|
|
|
|
indices.shift();
|
|
|
|
|
}
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
// Discard trailing empty lines
|
|
|
|
|
while ( indices.length !== 0 ) {
|
|
|
|
|
const s = lines[indices.at(-1)].trim();
|
|
|
|
|
if ( s.length !== 0 ) { break; }
|
|
|
|
|
indices.pop();
|
|
|
|
|
}
|
|
|
|
|
if ( indices.length === 0 ) { continue; }
|
|
|
|
|
const result = ruleFromLines(lines, indices);
|
|
|
|
|
if ( result.bad ) {
|
2025-12-12 14:48:40 +00:00
|
|
|
bad.push(...result.bad.slice(0, 4));
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
} else if ( result.rule ) {
|
|
|
|
|
rules.push(result.rule);
|
|
|
|
|
}
|
|
|
|
|
indices.length = 0;
|
|
|
|
|
}
|
|
|
|
|
return { rules, bad };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
|
|
|
|
function textFromValue(val, depth) {
|
|
|
|
|
const indent = ' '.repeat(depth);
|
|
|
|
|
switch ( typeof val ) {
|
|
|
|
|
case 'boolean':
|
|
|
|
|
case 'number':
|
|
|
|
|
return `${val}`;
|
|
|
|
|
case 'string':
|
|
|
|
|
if ( val === '' ) { return "''"; }
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
const out = [];
|
|
|
|
|
if ( Array.isArray(val) ) {
|
|
|
|
|
for ( const a of val ) {
|
|
|
|
|
const s = textFromValue(a, depth+1);
|
|
|
|
|
if ( s === undefined ) { continue; }
|
|
|
|
|
out.push(`${indent}- ${s.trimStart()}`);
|
|
|
|
|
}
|
|
|
|
|
return out.join('\n');
|
|
|
|
|
}
|
|
|
|
|
if ( val instanceof Object ) {
|
|
|
|
|
for ( const [ a, b ] of Object.entries(val) ) {
|
|
|
|
|
const s = textFromValue(b, depth+1);
|
|
|
|
|
if ( s === undefined ) { continue; }
|
|
|
|
|
if ( b instanceof Object ) {
|
|
|
|
|
out.push(`${indent}${a}:\n${s}`);
|
|
|
|
|
} else {
|
|
|
|
|
out.push(`${indent}${a}: ${s}`);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return out.join('\n');
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/******************************************************************************/
|
|
|
|
|
|
2025-06-13 16:46:05 +00:00
|
|
|
export function textFromRules(rules, option = {}) {
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
if ( Array.isArray(rules) === false ) {
|
|
|
|
|
if ( rules instanceof Object === false ) { return; }
|
|
|
|
|
rules = [ rules ];
|
|
|
|
|
}
|
|
|
|
|
const out = [];
|
|
|
|
|
for ( const rule of rules ) {
|
2025-06-13 16:46:05 +00:00
|
|
|
if ( option.keepId !== true && rule.id ) { rule.id = undefined };
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
const text = textFromValue(rule, 0);
|
|
|
|
|
if ( text === undefined ) { continue; }
|
|
|
|
|
out.push(text, '---' );
|
|
|
|
|
}
|
2025-06-13 16:46:05 +00:00
|
|
|
if ( out.length !== 0 ) {
|
|
|
|
|
out.unshift('---');
|
|
|
|
|
out.push('');
|
|
|
|
|
}
|
[mv3] Add support for custom DNR rules
This feature is hidden behind the "Developer mode" setting in
the dashboard. When "Developer mode" is enabled, a tab named
"Develop" will become available in the dashboard. This tab is
meant to contain tools for technical users.
At the moment, the "Develop" pane allows to create custom DNR
rules through a (CodeMirror-based) editor.
For the sake of convenience, the DNR rule must be entered in
YAML-like format. The format is not really full compliant YAML,
just YAML-like, and very strict in order to ensure the parser
stays simple enough.
Lines starting with `#` are comments and will be ignored by the
parser.
Any line which do not match the parser's expectation will be
marked as invalid, and the whole DNR rule containing such invalid
lines will be discarded.
There must not be empty lines inside a rule definition.
Each DNR rule must be separated with a `---` line, which is
known as a YAML document separator.
String values must not be quoted, otherwise the quotes will be
considered part of the value. There is one exception: `''` will
be parsed as "an empty string".
The editor will attempt to auto-complete known DNR keywords. That
feature will improve over time.
Though the parser will identify some errors, not all invalid DNR
rules are currently identified by the parser, and these will be
reported when the rules are registered through the DNR API. Better
identifying invalid DNR rules at edit time will improve over time.
The editor will report `regexFilter` values which are not
supported by the DNR engine on the current platform.
The editor reacts to instances of `regexFilter: ...` to report
whether a regex value is supported. This means you can test for
a regex value by using `# regexFilter: ...` so that you do not
have to create an actual DNR rules just for the sake of testing.
Custom DNR rules can be exported into a JSON file (a format
known by the DNR API as a "static ruleset").
JSON-based ruleset can be imported, the content will be converted
to YAML-like syntax.
The editor will attempt to convert to YAML pasted content which
can be JSON-parsed. It's possible to paste partially or wholly
JSON-based rulesets.
When disabling "Developer mode", all custom DNR rules will be
unregistered from the DNR API. The DNR rules content will be left
intact in such case. Existing DNR rules will be registered into
the DNR API when re-enabling "Developer mode".
Administrators can prevent "Developer mode" from being enabled
by adding `develop` token to `disabledFeatures` setting.
Related discussion:
https://github.com/uBlockOrigin/uBOL-home/discussions/323
The main motivation is to give list maintainers a tool to assist
with resolving filter issues. Custom DNR rules can assist in
crafting and validating filters meant to work with uBOL.
A secondary motivation is to provide technical users the ability
to further customize their content blocker.
More conveniences will be added over time, this is a first version.
2025-05-29 13:06:02 +00:00
|
|
|
return out.join('\n');
|
|
|
|
|
}
|