Hi,

As I was working with the standalone mode, I saw some error and misbehavior that we should address.

First, a notice error is thrown (for example when accessing the home page)

Notice: Undefined variable: crowdSecJsonStandaloneConfig in /var/www/html/wp-content/plugins/cs-wordpress-bouncer/inc/bounce-current-ip.php on line 14

This is coming from a require_once / auto_prepend_mode weird behavior : the file standalone-settings.php is not included because it has already been included (normal) but the variable that has been included is not defined (weird).

Secondly, there are 2 bounces for each request : the first is done by the standalone bouncer, the second is done by the "classic" bouncer.
There should be some logic that will disable the second bounce in case we are in standalone context.
If we fix this, the first error will be fixed too, as there won't be a second bounce anymore.

Third, the configuration Enable Standalone mode in the back office should be removed as the "standalone" should be entirely determined by the presence of an auto_prepend_file PHP directive (php.ini, Apache, nginx, ...): if such a directive has been configured in the server, the standalone mode should be enabled. If it hasn't, the standalone mode should not be enabled.

Currently, while the bouncer does the job, I would like to have it being able to protect all the php code of my wordpress.
Using something like auto_prepend_file php's directive might be nice, but I don't know if it's currently possible.

Hi,

I am on ubuntu 18.04.1, docker 20.10.7 and docker-compose version 1.24.1.

When I try to run SETUP_ONLY=1 ./run-tests.sh, I have the following error messages :

ERROR: The Compose file './docker-compose.yml' is invalid because:
networks.wordpress_bouncer_network_ipv4 value Additional properties are not allowed ('enable_ipv6', 'name' were unexpected)
networks.wordpress_bouncer_network_ipv6 value Additional properties are not allowed ('enable_ipv6', 'name' were unexpected)
networks.wordpress_bouncer_network_ipv6.ipam.config value Additional properties are not allowed ('gateway' was unexpected)

And it seems that enable_ipv6 property is not allowed with version 3 : docker/compose#4958

I changed version "3" by "2.3" and I could run the script, but then (when I tried to test the plugin) I had other errors probably due to this change.

As a workaround, I removed all unallowed additional properties (enable_ipv6, name, gateway) from the docker-compose.yml file: the script ran well, and the plugin seems to work, but I guess I will have issue with IPv6 feature.

When we launch the end to end tests, the display error option is by default disabled : should be enabled in order to throw an error during test.

Hi,

I am using Crowdsec Bouncer Plugin 1.4.3 with WP 5.93 and PHP 7.4.29.
I am using a single Redis DB with multiple WP sites. One of them is set to sync at 60 seconds (WP cron is replaced by a system cron job, and wp-config disables CRON), the rest of them have > 60000 seconds interval.
I am manually banning IP's and monitoring /var/log/crowdsec_api.log, /var/log/crowdsec.log, redis-cli monitor and the the access log for the website that syncs at each 60sec.

Problem : sometimes the IP is not added to Redis, so they are not banned.

How do I test:
I ban the IP 81.196.86.95 with cscli decisions add --ip 81.196.86.95 --duration 5m.
I see the API log entry :

time="24-05-2022 12:05:36" level=info msg="(441fca0e645b4b41b4c2d6da56663f0c3xIHLlSvv2snSDYT/cscli) manual 'ban' from '441fca0e645b4b41b4c2d6da56663f0c3xIHLlSvv2snSDYT' by ip 81.196.86.95 : 5m ban on Ip 81.196.86.95"

I can also see it in : cscli decisions list table
I have redis-cli monitor command running. If I click Refresh the cache now, I see the Redis entry being added:
Redis 10 DB is used in all configs.

1653383978.667692 [10 127.0.0.1:57260] "MGET" "cacheConfig"
1653383978.730722 [10 127.0.0.1:57260] "MGET" "SXA6ODEuMTk2Ljg2Ljk1"
1653383978.731144 [10 127.0.0.1:57260] "SETEX" "SXA6ODEuMTk2Ljg2Ljk1" "296" "\x00\x00\x00\x02\x14\x01\x06\x00\x14\x04\x06\x00\x11\x03ban\x06\x01\nb\x8c\xa4S\x06\x02\n\x00'\xb6\xd1\x06\x03\x06\x00"

If I try to browse from the above IP, i get a 403 as expected.

If I add the next IP 81.196.86.96, and wait for the cron to run, in the access.log I see entries at each 60s:

84.247.81.123 - - [24/May/2022:12:07:01 +0300] "GET /wp-cron.php?doing_wp_cron HTTP/2.0" 200 20 "-" "Wget/1.21"
84.247.81.123 - - [24/May/2022:12:08:01 +0300] "GET /wp-cron.php?doing_wp_cron HTTP/2.0" 200 20 "-" "Wget/1.21"
84.247.81.123 - - [24/May/2022:12:09:01 +0300] "GET /wp-cron.php?doing_wp_cron HTTP/2.0" 200 20 "-" "Wget/1.21"
84.247.81.123 - - [24/May/2022:12:10:02 +0300] "GET /wp-cron.php?doing_wp_cron HTTP/2.0" 200 20 "-" "Wget/1.21"

In crowdsec_api.log I see the requests from the plugin:

time="24-05-2022 12:07:01" level=info msg="127.0.0.1 - [Tue, 24 May 2022 12:07:01 EEST] "GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 67.459313ms "WordPress CrowdSec Bouncer/v1.4.3" ""
time="24-05-2022 12:08:01" level=info msg="127.0.0.1 - [Tue, 24 May 2022 12:08:01 EEST] "GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 151.400157ms "WordPress CrowdSec Bouncer/v1.4.3" ""
time="24-05-2022 12:09:02" level=info msg="127.0.0.1 - [Tue, 24 May 2022 12:09:02 EEST] "GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 151.97765ms "WordPress CrowdSec Bouncer/v1.4.3" ""
time="24-05-2022 12:10:02" level=info msg="127.0.0.1 - [Tue, 24 May 2022 12:10:02 EEST] "GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 190.641162ms "WordPress CrowdSec Bouncer/v1.4.3" ""

Redis-cli monitor doesn't show any SETEX entries.

The timestamps match, this means wp-cron triggers the refresh from the API.

If i wait and add other IP's each minute, 81.196.86.97 / 81.196.86.98 / 81.196.86.99 / 81.196.86.100 it doesn't (sometimes) pick them up. The logs show the API being queried but that's it.
Manually clicking the Refresh the cache now works and I recorded the SETEX value for each, to manually do a MGET after them.

81.196.86.95 - SXA6ODEuMTk2Ljg2Ljk1
81.196.86.96 - SXA6ODEuMTk2Ljg2Ljk2
81.196.86.97 - SXA6ODEuMTk2Ljg2Ljk3
81.196.86.98 - SXA6ODEuMTk2Ljg2Ljk4
81.196.86.99 - SXA6ODEuMTk2Ljg2Ljk5

I noticed that If I add 81.196.86.97 and is not picked up, after the cron runs, then I add 81.196.86.98, and manually click Refresh the cache now, only 81.196.86.98 / SXA6ODEuMTk2Ljg2Ljk4 key is added to Redis. Checking for the key SXA6ODEuMTk2Ljg2Ljk3 corresponding to 81.196.86.97 shows (nil).

In the decisions table both IP's are still present, but only the last one is added in Redis. I've tried with longer ban periods (so that the TTL for the key does not expire too soon for the tests), but it's the same. I've made sure that the IP's are not in the Crowsec DB already (blacklisted from central API). I have no other websites quering the API (both LIVE / STREAM mode).

I think the latest decisions are always synced from the API, but the IP's aren't always added to Redis.

This behaviour seems to happen when unbanning IP's also.
I need a way to debug the API refresh done by the plugin.

WordPress Version 5.9.3
CrowdSec Plugin Version 1.4.0

The following two errors are generated with the plugin enabled. Errors go away with plugin disabled.

A PHP session was created by a session_start() function call. This interferes with REST API and loopback requests. The session should be closed by session_write_close() before making any HTTP requests.

The REST API request failed due to an error. Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

With PHP 8.1, an error is thrown when a captcha wall has to be displayed.
On my local environment, here is the error :

Fatal error: Uncaught ErrorException: Implicit conversion from float 20.5 to int loses precision in /var/www/html/wp-content/plugins/cs-wordpress-bouncer/vendor/gregwar/captcha/src/Gregwar/Captcha/CaptchaBuilder.php:365 

It seems that this is due to the gregwar/captcha package:

@see Gregwar/Captcha#100

I'm not sure that the package is still being maintained.

In some case, we can have inconstancy between the JSON file and the database settings.

For example, if we use the wp cli tool to update a setting (or just update the settings directly in database), the static file won't be updated until an admin save the configuration again from the back office.

That's why I suggest limiting the use of this JSON static config file to the standalone mode. In "normal" mode, we should get the configuration from the database directly.

Fatal error: Uncaught TypeError: ltrim() expects parameter 1 to be string, bool given in /website/www/wp-content/plugins/crowdsec/inc/Bouncer.php:67
Stack Trace

1. ltrim()/website/www/wp-content/plugins/crowdsec/inc/Bouncer.php:67
2. Bouncer->handleRawConfigs()/website/www/wp-content/plugins/crowdsec/inc/Bouncer.php:35
3. Bouncer->__construct()/website/www/wp-content/plugins/crowdsec/inc/admin/init.php:126
4. testBouncerConnexionInAdminPage()/website/www/wp-content/plugins/crowdsec/inc/admin/init.php:219
5. {closure}()/website/www/wp-includes/class-wp-hook.php:308
6. do_action()/website/www/wp-admin/admin-post.php:85
7. {main}
   thrown in /website/www/wp-content/plugins/crowdsec/inc/Bouncer.php on line 67

What happened?

E_ERROR on line 52 file /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/NumericNode.php. Messaggio di errore: Uncaught Symfony\Component\Config\Definition\Exception\InvalidConfigurationException: The value 0 is too small for path "config.captcha_cache_duration". Should be greater than or equal to 1 in /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/NumericNode.php:52
Stack trace:
#0 /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/BaseNode.php(455): Symfony\Component\Config\Definition\NumericNode->finalizeValue()
crowdsecurity/crowdsec#1 /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/ArrayNode.php(245): Symfony\Component\Config\Definition\BaseNode->finalize()
crowdsecurity/crowdsec#2 /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/BaseNode.php(455): Symfony\Component\Config\Definition\ArrayNode->finalizeValue()
crowdsecurity/crowdsec#3 /wp-content/plugins/crowdsec/vendor/symfony/config/Definition/Processor.php(36): Symfony\Component\Config\Definition\BaseNode->finalize()

Hope this could help!

What did you expect to happen?

Works flawlessy ;-)

How can we reproduce it (as minimally and precisely as possible)?

I don't know

Anything else we need to know?

No response

Crowdsec version

$ cscli version
2023/03/08 10:04:48 version: v1.4.6-debian-pragmatic-5f71037b40c498045e1b59923504469e2b8d0140
2023/03/08 10:04:48 Codename: alphaga
2023/03/08 10:04:48 BuildDate: 2023-02-09_14:34:10
2023/03/08 10:04:48 GoVersion: 1.19.2
2023/03/08 10:04:48 Platform: linux
2023/03/08 10:04:48 Constraint_parser: >= 1.0, <= 2.0
2023/03/08 10:04:48 Constraint_scenario: >= 1.0, < 3.0
2023/03/08 10:04:48 Constraint_api: v1
2023/03/08 10:04:48 Constraint_acquis: >= 1.0, < 2.0

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ uname -a
Linux debian-4gb-fsn1-1 5.10.0-19-amd64 crowdsecurity/crowdsec#1 SMP Debian 5.10.149-1 (2022-10-17) x86_64 GNU/Linux


# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Enabled collections and parsers

$ cscli hub list -o raw
crowdsecurity/apache2,enabled,0.1,apache2 support : parser and generic http scenarios ,collections
crowdsecurity/base-http-scenarios,enabled,0.6,http common : scanners detection,collections
crowdsecurity/dovecot,enabled,0.1,dovecot support : parser and spammer detection,collections
crowdsecurity/http-cve,enabled,1.9,,collections
crowdsecurity/iptables,enabled,0.1,iptables support : logs and port-scans detection scenarios,collections
crowdsecurity/linux,enabled,0.2,core linux support : syslog+geoip+ssh,collections
crowdsecurity/linux-lpe,enabled,0.1,Linux Local Privilege Escalation collection : detect trivial LPEs,collections
crowdsecurity/mariadb,enabled,0.1,mariadb support : logs and brute-force scenarios,collections
crowdsecurity/postfix,enabled,0.2,postfix support : parser and spammer detection,collections
crowdsecurity/sshd,enabled,0.2,sshd support : parser and brute-force detection,collections
crowdsecurity/wordpress,enabled,0.4,wordpress: Bruteforce protection and config probing,collections
crowdsecurity/apache2-logs,enabled,1.3,Parse Apache2 access and error logs,parsers
crowdsecurity/dateparse-enrich,enabled,0.2,,parsers
crowdsecurity/dovecot-logs,enabled,0.6,Parse dovecot logs,parsers
crowdsecurity/geoip-enrich,enabled,0.2,"Populate event with geoloc info : as, country, coords, source range.",parsers
crowdsecurity/http-logs,enabled,1.1,"Parse more Specifically HTTP logs, such as HTTP Code, HTTP path, HTTP args and if its a static ressource",parsers
crowdsecurity/iptables-logs,enabled,0.3,Parse iptables drop logs,parsers
crowdsecurity/mariadb-logs,enabled,0.4,Parse MariaDB logs,parsers
crowdsecurity/pkexec-logs,enabled,0.1,Parse pkexec logs specifically for CVE-2021-4034,parsers
crowdsecurity/postfix-logs,enabled,0.4,Parse postfix logs,parsers
crowdsecurity/postscreen-logs,enabled,0.2,Parse postscreen logs,parsers
crowdsecurity/sshd-logs,enabled,2.0,Parse openSSH logs,parsers
crowdsecurity/syslog-logs,enabled,0.8,,parsers
crowdsecurity/whitelists,enabled,0.2,Whitelist events from private ipv4 addresses,parsers
crowdsecurity/CVE-2021-4034,enabled,0.1,Detect CVE-2021-4034 exploits,scenarios
crowdsecurity/CVE-2022-26134,enabled,0.1,Detect CVE-2022-26134 exploits,scenarios
crowdsecurity/CVE-2022-35914,enabled,0.1,Detect CVE-2022-35914 exploits,scenarios
crowdsecurity/CVE-2022-37042,enabled,0.1,Detect CVE-2022-37042 exploits,scenarios
crowdsecurity/CVE-2022-40684,enabled,0.2,Detect cve-2022-40684 exploitation attempts,scenarios
crowdsecurity/CVE-2022-41082,enabled,0.3,Detect CVE-2022-41082 exploits,scenarios
crowdsecurity/CVE-2022-41697,enabled,0.1,Detect CVE-2022-41697 enumeration,scenarios
crowdsecurity/CVE-2022-42889,enabled,0.2,Detect CVE-2022-42889 exploits (Text4Shell),scenarios
crowdsecurity/CVE-2022-44877,enabled,0.2,Detect CVE-2022-44877 exploits,scenarios
crowdsecurity/CVE-2022-46169,enabled,0.1,Detect CVE-2022-46169 brute forcing,scenarios
crowdsecurity/apache_log4j2_cve-2021-44228,enabled,0.4,Detect cve-2021-44228 exploitation attemps,scenarios
crowdsecurity/dovecot-spam,enabled,0.3,detect errors on dovecot,scenarios
crowdsecurity/f5-big-ip-cve-2020-5902,enabled,0.1,Detect cve-2020-5902 exploitation attemps,scenarios
crowdsecurity/fortinet-cve-2018-13379,enabled,0.2,Detect cve-2018-13379 exploitation attemps,scenarios
crowdsecurity/grafana-cve-2021-43798,enabled,0.1,Detect cve-2021-43798 exploitation attemps,scenarios
crowdsecurity/http-backdoors-attempts,enabled,0.3,Detect attempt to common backdoors,scenarios
crowdsecurity/http-bad-user-agent,enabled,0.7,Detect bad user-agents,scenarios
crowdsecurity/http-bf-wordpress_bf,enabled,0.4,detect wordpress bruteforce,scenarios
crowdsecurity/http-crawl-non_statics,enabled,0.3,Detect aggressive crawl from single ip,scenarios
crowdsecurity/http-cve-2021-41773,enabled,0.1,cve-2021-41773,scenarios
crowdsecurity/http-cve-2021-42013,enabled,0.1,cve-2021-42013,scenarios
crowdsecurity/http-generic-bf,enabled,0.4,Detect generic http brute force,scenarios
crowdsecurity/http-open-proxy,enabled,0.3,Detect scan for open proxy,scenarios
crowdsecurity/http-path-traversal-probing,enabled,0.2,Detect path traversal attempt,scenarios
crowdsecurity/http-probing,enabled,0.2,Detect site scanning/probing from a single ip,scenarios
crowdsecurity/http-sensitive-files,enabled,0.2,"Detect attempt to access to sensitive files (.log, .db ..) or folders (.git)",scenarios
crowdsecurity/http-sqli-probing,enabled,0.2,A scenario that detects SQL injection probing with minimal false positives,scenarios
crowdsecurity/http-wordpress_user-enum,enabled,0.1,detect wordpress probing : authors enumeration,scenarios
crowdsecurity/http-wordpress_wpconfig,enabled,0.1,detect wordpress probing : variations around wp-config.php by wpscan,scenarios
crowdsecurity/http-xss-probing,enabled,0.2,A scenario that detects XSS probing with minimal false positives,scenarios
crowdsecurity/iptables-scan-multi_ports,enabled,0.1,ban IPs that are scanning us,scenarios
crowdsecurity/jira_cve-2021-26086,enabled,0.1,Detect Atlassian Jira CVE-2021-26086 exploitation attemps,scenarios
crowdsecurity/mariadb-bf,enabled,0.1,Detect mariadb bruteforce,scenarios
crowdsecurity/postfix-spam,enabled,0.2,Detect spammers,scenarios
crowdsecurity/pulse-secure-sslvpn-cve-2019-11510,enabled,0.2,Detect cve-2019-11510 exploitation attemps,scenarios
crowdsecurity/spring4shell_cve-2022-22965,enabled,0.2,Detect cve-2022-22965 probing,scenarios
crowdsecurity/ssh-bf,enabled,0.1,Detect ssh bruteforce,scenarios
crowdsecurity/ssh-slow-bf,enabled,0.2,Detect slow ssh bruteforce,scenarios
crowdsecurity/thinkphp-cve-2018-20062,enabled,0.3,Detect ThinkPHP CVE-2018-20062 exploitation attemps,scenarios
crowdsecurity/vmware-cve-2022-22954,enabled,0.2,Detect Vmware CVE-2022-22954 exploitation attempts,scenarios
crowdsecurity/vmware-vcenter-vmsa-2021-0027,enabled,0.1,Detect VMSA-2021-0027 exploitation attemps,scenarios
ltsich/http-w00tw00t,enabled,0.1,detect w00tw00t,scenarios

Acquisition config

Config show

$ cscli config show
Global:
   - Configuration Folder   : /etc/crowdsec
   - Data Folder            : /var/lib/crowdsec/data
   - Hub Folder             : /etc/crowdsec/hub
   - Simulation File        : /etc/crowdsec/simulation.yaml
   - Log Folder             : /var/log/
   - Log level              : info
   - Log Media              : file
Crowdsec:
  - Acquisition File        : /etc/crowdsec/acquis.yaml
  - Parsers routines        : 1
  - Acquisition Folder      : /etc/crowdsec/acquis.d
cscli:
  - Output                  : human
  - Hub Branch              : 
  - Hub Folder              : /etc/crowdsec/hub
Local API Server:
  - Listen URL              : 127.0.0.1:8080
  - Profile File            : /etc/crowdsec/profiles.yaml
  - Trusted IPs: 
      - 127.0.0.1
      - ::1
  - Database:
      - Type                : sqlite
      - Path                : /var/lib/crowdsec/data/crowdsec.db
      - Flush age           : 7d
      - Flush size          : 5000

Prometheus metrics

$ cscli metrics
# paste output here

Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.

I no longer get the error mentioned in #91, however crowdsec doesn't seem to be working. I added my IP address to the decisions list but don't get bounced with this image

(found in this great tutorial which you might want to incorporate into your documentation -https://anto.online/guides/setup-crowdsec-wordpress-reverse-proxy-docker/)

Hi, I'd like to script the installation of the crowdsec plugin. I know of a workaround that could possibly work, but native integration to hand the API key and host details to the plugin and change the settings would be nice!

https://discord.com/channels/921520481163673640/1042925611427057786

See https://wordpress.org/support/topic/verify-checksums-fails-due-to-added-files/

For log and cache files, we could probably add a setting to choose another directory.

As there is no a PHP 8.1 compatible release of php-memcached : php-memcached-dev/php-memcached#495,
the memcached option for the cache selector should be removed if PHP 8.1 is detected.

Maybe, we will use something like :

if (PHP_VERSION_ID >= 80100 && version_compare(phpversion('memcached'), '3.1.5', '<=')) {
    // do not use Memcached
}

I cannot acivate the plugin in one of my Wordpress docker containers running with the bitnami/wordpress image.
When I try to activate it, I get an "fatal error" message and an error in the logs:

[24-Mar-2024 16:17:58 UTC] PHP Fatal error:  Cannot declare class AdminNotice, because the name is already in use in /bitnami/wordpress/wp-content/plugins/crowdsec/inc/admin/notice.php on line 3
<ip redacted> - - [24/Mar/2024:17:17:57 +0100] "GET /wp-admin/plugins.php?action=activate&plugin=crowdsec%2Fcrowdsec.php&plugin_status=all&paged=1&s&_wpnonce=6632a1c26b HTTP/1.1" 302 -
<ip redacted> - - [24/Mar/2024:17:17:59 +0100] "GET /wp-admin/plugins.php?error=true&plugin=crowdsec%2Fcrowdsec.php&_error_nonce=c4019a46df HTTP/1.1" 200 33475

I was able to activate the plugin on other wordpress sites of mine, which also use the same docker image and the same wordpress version, so maybe this is caused by some other Plugin?
I checked if the class name is already used by any other plugin, but this does not seem the case. At least I was not able to grep for that name in any other plugin directory.

The wordpress version is 6.4.3

Edit: I just tried to activate the plugin while the others where deactivated. This however did not work. Maybe the error is then not caused by any of my plugins?

Edit 2:
I was able to find a class with the same name in my theme's directory.

I have no name!@6d6b073227a8:/bitnami/wordpress/wp-content/themes$ grep -R AdminNotice *
newsphere/admin-dashboard/rest-api/class-admin-notice.php:if(!class_exists('AdminNotice')){ 
newsphere/admin-dashboard/rest-api/class-admin-notice.php:class AdminNotice {
newsphere/admin-dashboard/rest-api/class-admin-notice.php:$data = new AdminNotice();

When reading the crowsdesc_api.log, it can be useful to know which site made the request. Maybe a custom ID, or the site name added to the user agent ?

time="14-05-2022 12:10:14" level=info msg="127.0.0.1 - [Sat, 14 May 2022 12:10:14 EEST] \"GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 116.225231ms \"WordPress CrowdSec Bouncer/v1.4.3\" \""

nvm

Hi, regarding the use of Redis for caching. Do we need to use different databases (example: DSN : redis://localhost:6379/1 for site 1 and DSN : redis://localhost:6379/2 for site 2) for each site ?
Or it doesn't matter because the names for the keys are generated with unique names for each site ?

Hi, it would be nice if multisite could be supported to facilitate easier deployment and management across networks.

It could work like this:

1. The plugin checks if it's network enabled. If yes, then store the settings network-wide. or
2. Add support for constants that can be declared in wp-config.php (should help with automated deployments as well) or
3. both

Thank you for considering.

Hello all! 👋

First of all, I would like to say that Crowdsec is a powerful thing, and this WordPress plugin is a total bomb! ⚡

But, I recently noticed a possible problem with this plugin, in a test, and then in a production environment with plugin version - 1.11.0. The captcha/ban page is not displayed, for example, if add your IP address to Crowdsec decisions manually or use a banned IP address by inserting it into the "Forced test IP" field in "Advanced Settings". It simply passes the banned IP further to the site, instead of displaying the captcha/ban page.

In the logs (prod.log) there is an exception message (captcha):

2023-02-06T16:17:18.152008+00:00|300|{"type":"NON_AUTHORIZED_X_FORWARDED_FOR_USAGE","original_ip":"XXX.XXX.XXX.XXX","x_forwarded_for_ip":"type not as expected"}
2023-02-06T16:17:18.167364+00:00|300|{"type":"BAD_VALUE","value":" XXX.XXX.XXX.XXX","scope":"Ip","remediation":"ban","cache":"miss"}
2023-02-06T16:17:18.167583+00:00|200|{"type":"FINAL_REMEDIATION","ip":" XXX.XXX.XXX.XXX","remediation":"ban"}
2023-02-06T16:17:18.169490+00:00|400|{"type":"WP_EXCEPTION_WHILE_BOUNCING","message":"An exception has been thrown during the compilation of a template (\"include(/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/composer/../twig/twig/src/TwigTest.php): failed to open stream: No such file or directory (Error level: 2)\") in \"captcha.html.twig\".","code":0,"file":"/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Environment.php","line":521}

And the same for the page with a ban (here briefly, only an exception, everything repeats):

2023-02-06T16:27:41.991953+00:00|400|{"type":"WP_EXCEPTION_WHILE_BOUNCING","message":"An exception has been thrown during the compilation of a template (\"include(/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/composer/../twig/twig/src/TwigTest.php): failed to open stream: No such file or directory (Error level: 2)\") in \"ban.html.twig\".","code":0,"file":"/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Environment.php","line":521}

debug.log:

2023-02-08T16:45:29.912247+00:00|100|{"type":"REST_CLIENT_INIT","base_uri":"http://127.0.0.1:8080","timeout":120,"user_agent":"WordPress CrowdSec Bouncer/v1.11.0"}
2023-02-08T16:45:29.912563+00:00|100|{"type":"API_CLIENT_INIT","user_agent":"WordPress CrowdSec Bouncer/v1.11.0","rest_client":"CrowdSecBouncer\\RestClient\\Curl"}
2023-02-08T16:45:29.913331+00:00|100|{"type":"API_CACHE_INIT","adapter":"Symfony\\Component\\Cache\\Adapter\\TagAwareAdapter","mode":"live","fallback_remediation":"captcha","exp_clean_ips":5,"exp_bad_ips":20,"exp_captcha_flow":86400,"exp_geolocation_result":86400,"warmed_up":"false","geolocation":{"enabled":false,"type":"maxmind","save_result":false,"maxmind":{"database_type":"country","database_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../geolocation/"}}}
2023-02-08T16:45:29.913362+00:00|100|{"type":"BOUNCER_INIT","logger":"Monolog\\Logger","max_remediation_level":1,"configs":{"api_key":"***","auth_type":"api_key","tls_cert_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","tls_key_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","tls_verify_peer":false,"tls_ca_cert_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","api_url":"http://127.0.0.1:8080","use_curl":true,"api_user_agent":"WordPress CrowdSec Bouncer/v1.11.0","api_timeout":120,"debug_mode":true,"disable_prod_log":false,"log_directory_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../logs/","forced_test_ip":"XXX.XXX.XXX.XXX","forced_test_forwarded_ip":"","display_errors":false,"bouncing_level":"flex_bouncing","trust_ip_forward_array":[],"fallback_remediation":"captcha","stream_mode":false,"cache_system":"phpfs","fs_cache_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../.cache","redis_dsn":"","memcached_dsn":"","clean_ip_cache_duration":5,"bad_ip_cache_duration":20,"captcha_cache_duration":86400,"geolocation_cache_duration":86400,"geolocation":{"enabled":false,"type":"maxmind","save_result":false,"maxmind":{"database_type":"country","database_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../geolocation/"}},"max_remediation_level":"captcha","excluded_uris":[]}}
2023-02-08T16:45:29.913409+00:00|300|{"type":"NON_AUTHORIZED_X_FORWARDED_FOR_USAGE","original_ip":"XXX.XXX.XXX.XXX","x_forwarded_for_ip":"type not as expected"}
2023-02-08T16:45:29.913651+00:00|100|{"type":"START_IP_CHECK","ip":"XXX.XXX.XXX.XXX"}
2023-02-08T16:45:29.913799+00:00|300|{"type":"BAD_VALUE","value":"XXX.XXX.XXX.XXX","scope":"Ip","remediation":"ban","cache":"hit"}
2023-02-08T16:45:29.913907+00:00|200|{"type":"FINAL_REMEDIATION","ip":"XXX.XXX.XXX.XXX","remediation":"ban"}
2023-02-08T16:45:29.914806+00:00|400|{"type":"WP_EXCEPTION_WHILE_BOUNCING","message":"An exception has been thrown during the compilation of a template (\"include(/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/composer/../twig/twig/src/TwigTest.php): failed to open stream: No such file or directory (Error level: 2)\") in \"captcha.html.twig\".","code":0,"file":"/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Environment.php","line":521}

If enable WP_DEBUG and "Enable errors display":

Fatal error: Uncaught CrowdSecBouncer\BouncerException: include(/var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/composer/../twig/twig/src/TwigTest.php): failed to open stream: No such file or directory (Error level: 2) in /var/www/<site_dir>/wp-content/plugins/crowdsec/inc/Bounce.php:319
Stack trace:
#0 /var/www/<site_dir>/wp-content/plugins/all-in-one-seo-pack/vendor/composer/ClassLoader.php(571): Bounce->{closure}()
#1 /var/www/<site_dir>/wp-content/plugins/all-in-one-seo-pack/vendor/composer/ClassLoader.php(571): include()
#2 /var/www/<site_dir>/wp-content/plugins/all-in-one-seo-pack/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile()
#3 [internal function]: Composer\Autoload\ClassLoader->loadClass()
#4 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Extension/CoreExtension.php(243): spl_autoload_call()
#5 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/ExtensionSet.php(431): Twig\Extension\CoreExtension->getTests()
#6 /var/www/<site_dir>/wp-con
in /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Environment.php on line 521

This exception appears in versions 1.10.0 and 1.11.0. In the test environment, deactivation of all other plugins was tried, and for version 1.11.0, a test was made in a clean installation of WordPress. The result is the same.

This TwigTest.php file is missing from the plugin directory.

Version 1.9.0 displays pages with captcha/ban when banned or manually "Forced test IP" without any problems.

Also, I have already tried plugin version 2.0.0 on a clean installation of WordPress. The problem still remains. But, in the logs there seems to be no information about the error (debug.log):

2023-02-09T15:59:08.230416+00:00|100|Instantiate client|{"type":"CLIENT_INIT","configs":{"api_key":"***","auth_type":"api_key","tls_cert_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","tls_key_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","tls_verify_peer":false,"tls_ca_cert_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../tls/","api_url":"http://127.0.0.1:8080","api_timeout":120,"user_agent_version":"v2.0.0","user_agent_suffix":"WordPress"}}
2023-02-09T15:59:08.231299+00:00|100|Instantiate cache|{"type":"CACHE_INIT","configs":{"fs_cache_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../.cache"},"adapter":"Symfony\\Component\\Cache\\Adapter\\TagAwareAdapter"}
2023-02-09T15:59:08.231581+00:00|100|Instantiate remediation engine|{"type":"REM_INIT","configs":{"fallback_remediation":"captcha","stream_mode":false,"clean_ip_cache_duration":60,"bad_ip_cache_duration":120,"geolocation":{"enabled":false,"type":"maxmind","cache_duration":86400,"maxmind":{"database_type":"country","database_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../geolocation/"}},"ordered_remediations":["ban","captcha","bypass"]},"cache":"CrowdSec\\RemediationEngine\\CacheStorage\\PhpFiles"}
2023-02-09T15:59:08.231894+00:00|100|Instantiate bouncer|{"type":"BOUNCER_INIT","logger":"CrowdSec\\Common\\Logger\\FileLog","remediation":"CrowdSec\\RemediationEngine\\LapiRemediation","configs":{"use_curl":true,"debug_mode":true,"disable_prod_log":false,"log_directory_path":"/var/www/<site_dir>/wp-content/plugins/crowdsec/inc/../logs/","forced_test_ip":"XXX.XXX.XXX.XXX","forced_test_forwarded_ip":"","display_errors":true,"bouncing_level":"normal_bouncing","trust_ip_forward_array":[],"cache_system":"phpfs","captcha_cache_duration":86400,"hide_mentions":false,"custom_css":"","excluded_uris":[]}}
2023-02-09T15:59:08.232324+00:00|100|Cache result|{"type":"LAPI_REM_CACHED_DECISIONS","ip":"XXX.XXX.XXX.XXX","result":"miss"}
2023-02-09T15:59:08.232351+00:00|100|Now processing a bouncer request|{"type":"BOUNCER_CLIENT_REQUEST","method":"GET","endpoint":"/v1/decisions","parameters":{"ip":"XXX.XXX.XXX.XXX"}}
2023-02-09T15:59:08.239015+00:00|100|Decisions have been sorted by priority|{"type":"REM_SORTED_DECISIONS","decisions":[{"0":"ban","1":1675958468,"2":"CAPI-ban-ip-XXX.XXX.XXX.XXX","priority":0}]}

If enabled, "Enable errors display" (without WP_DEBUG), then almost immediately a letter arrives with a plugin exception from WordPress:

An error with type E_ERROR occurred on line 35 of the file /var/www/<site_dir>/wp-content/plugins/crowdsec/inc/bounce-current-ip.php.
Error message: Uncaught Error: Class 'Twig\TwigTest' not found in /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Extension/CoreExtension.php:245
Stack trace:
#0 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/ExtensionSet.php(448): Twig\Extension\CoreExtension->getTests()
#1 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/ExtensionSet.php(428): Twig\ExtensionSet->initExtension()
#2 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/ExtensionSet.php(399): Twig\ExtensionSet->initExtensions()
#3 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Environment.php(817): Twig\ExtensionSet->getUnaryOperators()
#4 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Lexer.php(457): Twig\Environment->getUnaryOperators()
#5 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Lexer.php(108): Twig\Lexer->getOperatorRegex()
#6 /var/www/<site_dir>/wp-content/plugins/crowdsec/vendor/twig/twig/src/Envi

Additionally, I provide information about the production environment:
wordpress-prod.txt

Server OS:

Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

Debian 11.6

Crowdsec:

2023/02/10 00:50:32 version: v1.4.5-debian-pragmatic-a9a2186a76af63551352aa3bc296bdbe80ca4893
2023/02/10 00:50:32 Codename: alphaga
2023/02/10 00:50:32 BuildDate: 2023-01-19_15:06:57
2023/02/10 00:50:32 GoVersion: 1.19.2
2023/02/10 00:50:32 Platform: linux
2023/02/10 00:50:32 Constraint_parser: >= 1.0, <= 2.0
2023/02/10 00:50:32 Constraint_scenario: >= 1.0, < 3.0
2023/02/10 00:50:32 Constraint_api: v1
2023/02/10 00:50:32 Constraint_acquis: >= 1.0, < 2.0

Plugin settings that are changed from default in production environment:

• Use cURL to call Local API - Yes
• Local API request timeout - 10 sec
• Bouncing level - Flex bouncing
• Public website only - No
• Theme customization - Messages and custom CSS code
• Captcha flow cache lifetime - 604800 sec
• Geolocation cache lifetime - 604800 sec

I'm sorry to face this problem, but I'm ready to help 🙂

I hope that the problem will be confirmed by you.
If you need any additional information, tests on this issue, I am always ready to provide and help with this.

Thank you in advance!

Best regards,
Maksim Strekalovskikh

i access site via normal domain and it gets killed no error

so i have domain
123456.uk example
i have cloudflare enabled
ive had bouncing flex or normal enabled my sit gets blocked
still not working

im using uptime kuma here for monitoring still stumpped

=============

An error of type E_ERROR was caused in line 311 of the file /var/www/developpement/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php. Error message: Uncaught Error: Call to a member function toString() on null in /var/www/developpement/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php:311
Stack trace:
#0 /var/www/developpement/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(446): CrowdSecBouncer\ApiCache->saveRemediations()
#1 /var/www/developpement/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/Bouncer.php(170): CrowdSecBouncer\ApiCache->warmUp()
#2 /var/www/developpement/wp-content/plugins/crowdsec/inc/admin/init.php(40): CrowdSecBouncer\Bouncer->warmBlocklistCacheUp()
#3 /var/www/developpement/wp-content/plugins/crowdsec/inc/plugin-setup.php(55): clearBouncerCacheInAdminPage()
#4 /var/www/developpement/wp-includes/class-wp-hook.php(303): deactivate_crowdsec_plugin()
#5 /var/www/developpement/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters()
#6 /var/www/developpement/wp-includes/plugin.php(470): WP_Hook->do_action()
#7 /var/www/developpement/wp-admin/includes/plugin.php(821): do_action()
#8 /va

As the WordPress plugin does not really use composer, we should add the vendor folder to the versioned sources.
We must ensure too that these files have been generated as we were on a PHP 7.2 environment.
We must ensure too that our tests works for other PHP versions.
After doing this, we have to modify the deployment process : there is now a GitHub action that generates on the fly vendor sources, and we won't have to do that anymore.

I have this issue : in STREAM mode, wordpress cron task does not work for updates from the local API.

In /wp-content/debug.log

[11-May-2022 09:17:14 UTC] PHP Fatal error: Uncaught Error: Call to a member function error() on null in /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/Bounce.php:339 Stack trace: #0 /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/bounce-current-ip.php(27): Bounce->safelyBounce() #1 /var/www/clients/client0/web5/web/wp-includes/class-wp-hook.php(307): safelyBounceCurrentIp() #2 /var/www/clients/client0/web5/web/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters() #3 /var/www/clients/client0/web5/web/wp-includes/plugin.php(474): WP_Hook->do_action() #4 /var/www/clients/client0/web5/web/wp-settings.php(450): do_action() #5 /var/www/clients/client0/web5/web/wp-config.php(106): require_once('/var/www/client...') #6 /var/www/clients/client0/web5/web/wp-load.php(50): require_once('/var/www/client...') #7 /var/www/clients/client0/web5/web/wp-cron.php(44): require_once('/var/www/client...') #8 {main} thrown in /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/Bounce.php on line 339

I'm testing this on 4 WP sites (different themes / plugins / WP versions) on the same ISPConfig Debian 11 server with NGINX & PHP 7.4.
Crowdsec plugin version is 1.4.1
I have crowdsec installed locally. In the LIVE mode, i see events in /var/log/crowdsec_api.log.
In STREAM mode i only see expected events when activating the plugin or manually clicking on "Refresh the cache now"

This also blocks all other Wordpress cron jobs. I can see this with Wordpress plugin "WP Crontrol". Manually executing the task from "WP Crontrol" trows the same error.

Hello, I've noticed there's a problem when using STREAM mode. I receive HTTP 500 ERROR when activating STREAM mode.

Debian version 11.3
PHP version : 7.4.29
Crowdsec version : 1.4.3
WP Crowdsec plugin : 1.10.0
Wordpress version : 6.1.1

I've changed the port for crowdsec in /etc/crowdsec/config.yaml in 8888 because 8080 is already used.

This issue is happening with / without the option "Use cURL to call Local API"

With Use cURL to call Local API enabled I have this in my logs.

The Crowdec WP plugin debug.log is:

==> ../../../debug.log <==
[14-Dec-2022 21:46:13 UTC] PHP Fatal error:  Uncaught CrowdSecBouncer\BouncerException: Unexpected CURL call failure: Operation timed out after 1000 milliseconds with 0 bytes received in /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/RestClient/Curl.php:35
Stack trace:
#0 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiClient.php(94): CrowdSecBouncer\RestClient\Curl->request()
#1 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(181): CrowdSecBouncer\ApiClient->getStreamedDecisions()
#2 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/Bouncer.php(299): CrowdSecBouncer\ApiCache->warmUp()
#3 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/inc/admin/advanced-settings.php(21): CrowdSecBouncer\Bouncer->warmBlocklistCacheUp()
#4 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/inc/admin/init.php(248): {closure}()
#5 /v in /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/RestClient/Curl.php on line 35

The /var/log/crowdsec.log show:

==> /var/log/crowdsec.log <==
time="14-12-2022 23:46:13" level=warning msg="client 127.0.0.1 disconnected : write tcp 127.0.0.1:8888->127.0.0.1:51036: write: broken pipe"

The /var/log/crowdsec_api.log shows:

==> /var/log/crowdsec_api.log <==
time="14-12-2022 23:46:13" level=info msg="127.0.0.1 - [Wed, 14 Dec 2022 23:46:13 EET] \"GET /v1/decisions/stream?startup=true&scopes=Ip%2CRange HTTP/1.1 200 1.316249051s \"WordPress CrowdSec Bouncer/v1.10.0\" \""

With With Use cURL to call Local API disabled I have this in my logs:

The Crowdec WP plugin debug.log is:

==> ../../../debug.log <==
[14-Dec-2022 21:54:58 UTC] PHP Warning:  file_get_contents(http://127.0.0.1:8888/v1/decisions/stream?startup=true&amp;scopes=Ip%2CRange): failed to open stream: HTTP request failed! in /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/RestClient/FileGetContents.php on line 50
[14-Dec-2022 21:54:58 UTC] PHP Fatal error:  Uncaught CrowdSecBouncer\BouncerException: Unexpected HTTP call failure. in /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/RestClient/FileGetContents.php:52
Stack trace:
#0 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiClient.php(94): CrowdSecBouncer\RestClient\FileGetContents->request()
#1 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(181): CrowdSecBouncer\ApiClient->getStreamedDecisions()
#2 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/Bouncer.php(299): CrowdSecBouncer\ApiCache->warmUp()
#3 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/inc/admin/advanced-settings.php(21): CrowdSecBouncer\Bouncer->warmBlocklistCacheUp()
#4 /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/inc/admin/init.php(248): {closure}()
#5 /var/www/clients/client0/web24/web/blog/wp-inc in /var/www/clients/client0/web24/web/blog/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/RestClient/FileGetContents.php on line 52

curl on http://127.0.0.1:8888 shows:

curl "http://127.0.0.1:8888/v1/decisions/stream?startup=true&scopes=Ip%2CRange"
{"message":"access forbidden"}

I assume it's normal, because it's expecting a header with the bouncer key.
Can you give me an example of a curl request with all the needed headers to query in STREAM mode ?
I assume the response it gets is different from what is expected.

Test your settings -> Test bouncing works.
I've tried Bouncing level Normal / Flex, no change.
I've tried caching with Filesystem / Redis, still no change.
I've deleted and recreated the bouncer API key, still no change.

Refreshing the cache in STREAM mode doesn't seem to work.
I am manually adding an IP with the following command:
cscli decisions add -i 81.196.86.92 --reason "web bruteforce"
I can see the IP in cscli decisions list table. In LIVE mode, the requests from the IP receive 403, as expected.
If I use STREAM mode, and click "Refresh cache now" i get : The cache has just been refreshed (0 new decision, 0 deleted).
I have tested with Techonolgy : File system / Redis

The changes are picked up only using the "Clear now button". When i add an IP, i get "CrowdSec cache has just been cleared. As the stream mode is enabled, the cache has just been warmed up, there are now 16000 decisions in cache."
The requests from the IP are blocked, as expected.
If I delete the IP with cscli decisions delete --ip 81.196.86.92, and click Refresh the cache now, i get "(0 new decision, 0 deleted)". I was expecting "1 deleted"
If i click "Clear now button" i get ""CrowdSec cache has just been cleared. As the stream mode is enabled, the cache has just been warmed up, there are now 15999 decisions in cache." - This is OK, we have 1 less decision.
Adding a bunch of IP's has the same result.

Wordpress 5.9.3 / Crowdec plugin 1.4.3

Is the option Advanced -> Remediations -> Trust these CDN Ips compatible with IPv6?

I'm getting this error in the debug.log. Crowdsec doesn't seem to be connecting/working.

safelyBounce error:session_start(): open(/var/lib/lsphp/session/lsphp81/sess_e5go527d5uqf4e32bpos3hqfdm, O_RDWR) failed: No such file or directory (2) (Error level: 2) in file:/wp-content/plugins/crowdsec-bk/inc/Bounce.php(line 326)

It may also be related to the fact that Crowdsec just doesn't seem to be working at all, which I suspect is because I have an OpenLiteSpeed server.

I'm happy to provide any details you need and help with debugging.

Hello!
I have this error in my apache2 logs :
PHP Fatal error: Uncaught Error: Call to a member function toString() on null in /var/www/html/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php:350\nStack trace:\n#0 /var/www/html/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php(491): CrowdSecBouncer\\ApiCache->removeRemediations()\n#1 /var/www/html/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/Bouncer.php(181): CrowdSecBouncer\\ApiCache->pullUpdates()\n#2 /var/www/html/wp-content/plugins/crowdsec/inc/scheduling.php(23): CrowdSecBouncer\\Bouncer->refreshBlocklistCache()\n#3 /var/www/html/wp-includes/class-wp-hook.php(303): crowdSecRefreshBlocklist()\n#4 /var/www/html/wp-includes/class-wp-hook.php(327): WP_Hook->apply_filters()\n#5 /var/www/html/wp-includes/plugin.php(518): WP_Hook->do_action()\n#6 /var/www/html/wp-cron.php(138): do_action_ref_array()\n#7 {main}\n thrown in /var/www/html/wp-content/plugins/crowdsec/vendor/crowdsec/bouncer/src/ApiCache.php on line 350, referer: https://my-website.com/wp-cron.php?doing_wp_cron=1629730782.3094000816345214843750

Access woocomerce log from this url: /wp-admin/admin.php?page=wc-status&tab=logs, I saw a long list of CRITICAL Uncaught Error such as below:

2022-05-10T22:50:22+00:00 CRITICAL Uncaught Error: Call to a member function error() on null in /var/www/mydomain/htdocs/wp-content/plugins/crowdsec/inc/Bounce.php:339
Stack trace:
#0 /var/www/mydomain/htdocs/wp-content/plugins/crowdsec/inc/bounce-current-ip.php(27): Bounce->safelyBounce()
#1 /var/www/mydomain/htdocs/wp-includes/class-wp-hook.php(307): safelyBounceCurrentIp()
#2 /var/www/mydomain/htdocs/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#3 /var/www/mydomain/htdocs/wp-includes/plugin.php(474): WP_Hook->do_action()
#4 /var/www/mydomain/htdocs/wp-settings.php(450): do_action()
#5 /var/www/mydomain/wp-config.php(113): require_once('...')
#6 /var/www/mydomain/htdocs/wp-load.php(55): require_once('...')
#7 /var/www/mydomain/htdocs/wp-cron.php(44): require_once('...')
#8 {main}
thrown in /var/www/mydomain/htdocs/wp-content/plugins/crowdsec/inc/Bounce.php on line 339

The deploy GitHub actions is using a composer install --no-dev,
And the debug log needs a Bramus package that has been defined in the required-dev section.

As a result, debug log will never be enabled in the deployed version.