Few months in using it, I went to look for another plugin. Came across Filebird, and it’s just perfect for my use case. Stackable folders, a good folder view at the left and no touching of the paths. I could even import the folders of the previous plugin.

super komisches problem:

einrichtung klappte problemlos, auch mit all in one security and firewall aktiv. derzeit ist letzteres komplett deaktiviert. nach einiger zeit und ohne spezifische ?nderungen bekomme ich jetzt auf einmal wieder den rest api fehler.
/wp-json/wp/v2 l?uft
/wp-json/real-cookie-banner/v1 l?uft ebenso
aber unter /wp-admin/admin.php?page=real-cookie-banner-component#/
dreht sich alles endlos, nichts geht, komplettes cookie banner offline.
insepctor console:
/wp-json/wp/v2/settings?_v=3.1.7&_locale=user forbidden
/wp-json/real-cookie-banner/v1/checklist?_v=3.1.7&_locale=user&_wp_http_referer=XXXXFwp-admin%2Fadmin.php%3Fpage%3Dreal-cookie-banner-component%23%2F contains unexpected JSON, try to resolve the JSON line by line

der fehler tritt nur in chrome auf. do not track ist aus, alle cookies werden akzeptiert. alle plugins deaktiviert. in firefox geht alles problemlos. irgendeine idee was das sein k?nnte?

danke!

noch was komisches. aktuell habe ich auf https://ff-webdesigner.com/online-bestellung-webdesign.html real cookie banner free aktiv. funktionalen service recaptcha erstellt, dazu einen content blocker https://www.google.com/recaptcha/*. genau so funktioniert real cookie banner zuverl?ssig auf vielen seiten. auf meiner eigenen nicht. auch ohne irgendwelche andere plugins aktiv oder mit standard-theme.

mein formulare sendet contact form 7. die recaptcha integration l?uft ohne real cookie banner korrekt. sobald ich nur den service recaptcha aktiviere, noch nicht mal den content blocker sehe ich in devtools:

grecaptcha is not defined

irgendeine ahnung warum?

I would like to report a misbehaviour of the plugin when using a reverse proxy.

The problem
The plugin does not recognise the real IP of the user / the request, but only the internal IP / the IP of my reverse proxy. Although I have switched on the setting “My site is behind a reverse proxy” and my reverse proxy (NGINX) is configured to send the required headers along.
This causes all IP addresses to be blocked when only one IP address should be blocked.

Let me explain the problem with an example…
The following situation:
I switch the option ” Immediately block IP when attempting to log in with a non-existing username” to on. Then I use two devices with different IPs to log in. Let’s say my PC and my smartphone (via LTE -> different IP address).
On the smartphone, I go to my login URL and try to log in with a fake username + password. With my PC, I also go to my login URL and try to log in with a correct username + password.

Expected behaviour
On the smartphone, I cannot log in. The combination of username + password is wrong. Because I have switched on the option “Immediately block IP when attempting to log in with a non-existing username”, I am also blocked for the time being and cannot log in at all for the next few minutes.
This should not be a problem on the PC because I use a different IP address there. If I want to log in (with a proper username + password), I should be able to log in without any problems.

Actual behaviour
I cannot log in on the smartphone. I am blocked immediately.
But on the PC I can’t log in either because all logins / all IP addresses are blocked.

This is probably because the plugin does not use the real IP address, but that of the reverse proxy. I also see this in the logs under Dashboard, Activity and Lockouts.

My setup

• Latest version of WordPress (5.8)
• Latest version of WP Cerber Security (8.9)
• WordPress Plugins: WooCommerce, WooCommerce Germanized, Borlabs Cookie Consent Management and a few more WordPress plugins that you need for a shop. So a few extensions for WooCommerce and such. Nothing extraordinary or weird. Most of the plugins are very popular and widely used.
• WordPress is run on a VM via Docker. The official Docker images for WordPress (from hub.docker.com/_/wordpress) are used and Docker-Compose is used to run WordPress and a MariaDB.
• We use a NGINX reverse proxy that is switched in front of the Docker container of WordPress. The NGINX reverse proxy takes care of the accesses and the SSL certificate. The communication between the NGINX and WordPress works without SSL.
• Settings in WP Cerber Security:
  – “Load security engine”: Normal
  – “Site connection / My site is behind a reverse proxy”: Checked
  All other settings are left at default values. At least I think so…

This is my NGINX config for the reverse proxy

user nginx;

worker_processes auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events
{
  worker_connections 1024;
}

http
{
  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  log_format main '$remote_addr - $remote_user [$time_local] "$request" '
  '$status $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';

  access_log /var/log/nginx/access.log main;

  sendfile on;

  keepalive_timeout 60;
  gzip on;
  gzip_proxied any;
  server_tokens off;

  client_max_body_size 256m;

  # ssl config
  # c.f. https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
  # c.f. https://mozilla.github.io/server-side-tls/ssl-config-generator/
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 60m;

  # modern
  ssl_protocols TLSv1.2;
  ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

  ssl_prefer_server_ciphers on;
  ssl_session_tickets off;

  # security
  # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
  add_header Strict-Transport-Security max-age=15768000;

  # generic proxy settings
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # pages may need longer to produce output - this should somewhat correspond to the proxied server timeout
  proxy_read_timeout 400s;

  # redirect everything to https
  server
  {
    listen 80;
    server_name _;

    # document root for letsencrypt certbot challenges
    location /.well-known/acme-challenge
    {
      root /proxy/conf/ssl/letsencrypt;
    }

    # everything else redirected to https
    location /
    {
      return 302 https://$host$request_uri;
    }
  }

  server
  {
    listen 443 ssl http2;
    server_name mysite.url;

    resolver 127.0.0.11 valid=10s;

    # ssl
    ssl_certificate /etc/letsencrypt/live/mysite.url/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mysite.url/privkey.pem;

    location /
    {
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header Host $host;

      http2_push_preload on;
      proxy_intercept_errors on;
      set $upstream https://mysite.url-container-name:80;
      proxy_pass $upstream$request_uri;
    }
  }
}