Wordpress LScache Plugin: Cannot Retrieve Domain Key
Hi all Im trying to get a Domain Key within the litespeed cache plugin. Im currently running the site on a jelastic environment based on https://docs.jelastic.com/wordpress-cluster/ So Basically a Litespeed ADC and a Litespeed WebServer backed by a MARIADB Cluster. Basically all works fine but getting the domain key returns the following error: 1) The POST callback to https://uat-3.hebu-shop.ch/wp-json/litespeed/v1/token failed. The server returns a 401 error. Deactivating all the plugins was not helping at all. Ive also tried a database repair of the litespeed plugin as suggested in another thread. Ive checked a dozen of thread regarding this. Basically i can tell that there is not firewall issue. WAF is deactivate on Litespeed and on the Security Tab if granted access to ALL. I think that wordpress is blocking the request for some reasons, but i dont know why. Looks like it needs a login on the wp-json/litespeed/v1/token the base wp-json/litespeed/v1/token is accessible. So please have a look on the HTACCESS: # BEGIN LSCACHE ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ## RewriteEngine on CacheLookup on RewriteRule . - [E=Cache-Control:no-autoflush] RewriteRule .litespeed_conf .dat - [F,L] ### marker MOBILE start ### RewriteCond % HTTP_USER_AGENT Mobile|Android|Silk/|Kindle|BlackBerry|Opera Mini|Opera Mobi [NC] RewriteRule . - [E=Cache-Control:vary=% ENV:LSCACHE_VARY_VALUE +ismobile] ### marker MOBILE end ### ### marker CACHE RESOURCE start ### RewriteRule wp-content/. /[^/] (responsive|css|js|dynamic|loader|fonts) .php - [E=cache-control:max-age=3600] ### marker CACHE RESOURCE end ### ### marker FAVICON start ### RewriteRule favicon .ico$ - [E=cache-control:max-age=86400] ### marker FAVICON end ### ### marker DROPQS start ### CacheKeyModify -qs:fbclid CacheKeyModify -qs:gclid CacheKeyModify -qs:utm CacheKeyModify -qs:_ga ### marker DROPQS end ### ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ## # END LSCACHE # BEGIN NON_LSCACHE ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ## ## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ## # END NON_LSCACHE Header always set Strict-Transport-Security max-age=31536000 # BEGIN WordPress # Die Anweisungen (Zeilen) zwischen ?BEGIN WordPress und ?END WordPress sind # dynamisch generiert und sollten nur ?ber WordPress-Filter ge?ndert werden. # Alle ?nderungen an den Anweisungen zwischen diesen Markierungen werden ?berschrieben. # END WordPress Expand Do you have any hint were I can continue with my investigations? Best Regards, Fabo This topic was modified 10 months, 4 weeks ago by fabo137. The page I need help with: https://uat-3.hebu-shop.ch/ Sorry forgot the report: SWKFDFFU Ive made some further investigations. I still dont have a solution, but an idea. I currently assuming that the lightspeed plugin, especially the function which is failing. Ive found on src/cloud.cls.php the function public function token_validate() which is doing the magic. This one is called by from the rest call and registered in register_rest_route( litespeed/v1, /token, array( methods => POST, callback => array( $this, token ), permission_callback => array( $this, is_from_cloud ), which is making a check if is from cloud. which goes deeper in public function is_from_cloud() if ( empty( $this->_summary[ ips ] ) || empty( $this->_summary[ ips_ts ] ) || time() - $this->_summary[ ips_ts ] > 86400 self::TTL_IPS ) $this->_update_ips() $res = $this->cls( Router )->ip_access( $this->_summary[ ips ] ) if ( ! $res ) self::debug( Not our cloud IP ) // Refresh IP list for future detection $this->_update_ips() else self::debug( Passed Cloud IP verification ) return $res Expand and deeper in private function _update_ips() self::debug( Load remote Cloud IP list from . self::CLOUD_IPS ) $response = wp_remote_get( self::CLOUD_IPS . ?json ) if ( is_wp_error( $response ) ) $error_message = $response->get_error_message() self::debug( failed to get ip whitelist: . $error_message ) throw new Exception( Failed to fetch QUIC.cloud whitelist . $error_message ) $json = json_decode( $response[ body ], true ) $this->_summary[ ips_ts ] = time() $this->_summary[ ips ] = $json self::save_summary() So i assume the plugin is checking if the origin IP from the caller is from quic cloud. That would explain the reason why I get a 401 when calling the API manually by just navigating to /wp-json/litespeed/v1/token. My IP is not from Cloud. And that brings me to the point that the calling IP from quic cloud to send back the key is failing because the rest api gets a wrong IP. Ive mentioned before that I have whitelist the IPs. So the call will go definitely go through the ADC instance also through the webserver and hits the rest api. However authentication fails. So ive checked litespeed ADC config again and found in the Server ? > GENERAL TAB a setting called: Use Client IP in Header which was set to NO. Im not an Litespeed expert yet but would assume that my Webserver behind the ADC would not get the client IP. Instead I assume it will get the one of the ADC in the request header. ???? (I dont know, I assume) So ive changed this setting to Trusted IPs so assuming ip will be forwarded in the header, because of the fact that quic cloud servers are in the trusted list. Was not working. Ive found this setting on the Litespeed Webserver itself as well. Changed there as well. Also not working. So still not further. For completeness reasons here the whitelist IPs. 101.53.133.36T, 102.129.254.77T, 102.221.36.98T, 102.221.36.99T, 103.152.118.219T, 103.152.118.72T, 103.164.203.163T, 103.199.16.151T, 103.236.150.198T, 103.28.90.190T, 104.225.142.116T, 104.244.77.37T, 109.248.43.212T, 124.150.139.239T, 135.148.120.32T, 135.148.148.230T, 137.220.36.137T, 139.162.89.149T, 139.59.21.152T, 141.164.38.65T, 146.59.17.163T, 146.88.239.197T, 147.135.115.64T, 149.28.11.90T, 152.228.171.66T, 154.16.57.184T, 156.67.209.151T, 16.170.121.215T, 163.182.174.161T, 163.47.20.24T, 163.47.21.168T, 164.52.202.100T, 165.227.116.222T, 172.104.44.18T, 178.17.171.177T, 18.192.146.200T, 181.215.183.135T, 185.116.60.231T, 185.116.60.232T, 185.126.236.167T, 185.126.237.129T, 185.205.187.233T, 185.228.26.40T, 185.53.57.40T, 185.53.57.89T, 192.99.38.117T, 193.203.202.215T, 194.36.144.221T, 195.231.17.141T, 199.59.247.242T, 2.58.28.32T, 200.58.127.145T, 204.10.163.237T, 207.246.71.239T, 209.208.26.218T, 213.159.1.75T, 213.183.51.224T, 213.184.87.75T, 216.250.96.181T, 27.131.75.40T, 27.131.75.41T, 3.109.250.83T, 31.131.4.244T, 31.22.115.186T, 31.220.111.172T, 34.247.229.180T, 37.120.131.40T, 37.143.128.237T, 38.129.107.18T, 41.185.29.210T, 41.223.53.163T, 43.231.0.46T, 45.124.65.86T, 45.132.244.92T, 45.248.77.61T, 45.32.210.159T, 45.56.77.123T, 45.76.17.119T, 45.9.249.220T, 46.250.220.133T, 49.12.102.29T, 5.134.119.103T, 5.134.119.194T, 5.188.183.13T, 51.81.186.219T, 51.81.33.156T, 54.162.162.165T, 54.36.103.97T, 62.141.42.38T, 64.225.34.246T, 64.227.16.93T, 65.21.81.50T, 65.21.81.51T, 74.3.163.74T, 79.172.239.249T, 81.31.156.246T, 83.229.71.151T, 86.105.14.231T, 86.105.14.232T, 91.201.67.57T, 91.228.7.67T, 91.239.234.48T, 92.38.139.226T, 93.95.227.66T, 94.26.84.39T, 94.75.232.90T, 95.217.200.8T So. No im really confused and disappointed. No idea how to continue, now idea how to fix this. A little hint would probably save my day. Thanks in advance for helping. Regards, Fabo Hi, yes, when there is a proxy , like ADC or any other reverse proxy server in front , LSWS may not receive the real client IP you need to enable that client IP option to ON or trusted IP , in both LSWS and ADC a simple way to verify is that to create a phpinfo page , check the $_SERVER[REMOTE_ADDR] , make sure it shows the visitors IP , instead of any proxy server IP Best regards, ]