You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bug, not a question or a configuration issue; Please visit our forum first to troubleshoot with volunteers, before creating a report. The links can be found here.
This issue is not already reported on GitHub(I've searched it).
I'm using an up to date version of OpenBullet2. We generally do not support previous older versions. If possible, please update to the latest version before opening an issue.
This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one.
Description of the bug
Hello again friends
I added </html> to the Global Ban Keys section under Proxies, and the documentation says it's a way to not have to add terms to every KeyCheck which sounded great, so I added to it as a way to filter out Proxies that keep giving bad responses, but it doesn't appear to work, and instead is heading to my CUSTOM area where I am doing further troubleshooting.
But I expect this to receive BAN status, not CUSTOM! As </html> is already specified in Global Ban Keys. And then when something doesn't contain my terms it's supposed to go to Custom afterwards, but not before being filtered by the Global Ban Key. Only way I can figure out to fix it is to add the </html> tag above the CUSTOM check, but isn't that what exactly what it's supposed to save time from?
Let me know what I misunderstood, or if this is a bug
Thanks as always
Reproduction steps
Add </html> to Proxy Global Ban Keys
Receive a response with </html> and notice it is not caught by Global Ban Key Check
What is the current bug behavior?
Not working
What is the expected correct behavior?
Catch the Global Ban Key at KeyCheck time, as per the documentation
Global ban keys
In the global ban keys field you can write a list of keywords (one per line) that indicate that a proxy should be banned. Usually, these include keywords that indicate the presence of a captive portal or region-based access control of some sort. This is a way to ban free low-quality proxies without the need to put all those keywords inside the Keycheck block of your configs.
These keys will be checked when executing a Keycheck block, and if they are present in the data.SOURCE variable, they will lead to a BAN status.
This issue respects the following points:
Description of the bug
Hello again friends
I added
</html>
to the Global Ban Keys section under Proxies, and the documentation says it's a way to not have to add terms to every KeyCheck which sounded great, so I added to it as a way to filter out Proxies that keep giving bad responses, but it doesn't appear to work, and instead is heading to my CUSTOM area where I am doing further troubleshooting.But I expect this to receive BAN status, not CUSTOM! As
</html>
is already specified in Global Ban Keys. And then when something doesn't contain my terms it's supposed to go to Custom afterwards, but not before being filtered by the Global Ban Key. Only way I can figure out to fix it is to add the</html>
tag above the CUSTOM check, but isn't that what exactly what it's supposed to save time from?Let me know what I misunderstood, or if this is a bug
Thanks as always
Reproduction steps
Add
</html>
to Proxy Global Ban KeysReceive a response with
</html>
and notice it is not caught by Global Ban Key CheckWhat is the current bug behavior?
Not working
What is the expected correct behavior?
Catch the Global Ban Key at KeyCheck time, as per the documentation
Version of the client
Latest
Type of client
Web client
Environment
OpenBullet2 logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Relevant LoliCode if needed
Additional information
No response
The text was updated successfully, but these errors were encountered: