Search results

The issue is caused by the presence of jcryption_keypair.dpkg without the corresponding jcryption_keypair file. Since Jcryption is not being used, you have two options to resolve this: Remove the existing files: rm -f /usr/local/lsws/admin/conf/jcryption_keypair* Alternatively, manually create...

I will forward the request to the team.

I think I found the possible reason is that you have jcryption_keypair.dpkg, but jcryption_keypair and cuasing the issue. Could you share the output with the following command? ls -la /usr/local/lsws/admin/conf/jcryption_keypair* dpkg-divert --list | grep jcryption We'll enhance the package...

Those versions include the security patches. You can also check the build timestamps to confirm they are recent builds.

That's the new design starting from v1.9.4, To enable webadmin again: touch /usr/local/lsws/admin/conf/enable_webadmin /usr/local/lsws/bin/lswsctrl restart Optionally, list the IP addresses or subnets allowed to access WebAdmin in that file. Example:

Just a quick update: PHP 7.4–8.5(both amd64 and arm64) have been updated across all currently maintained OS versions, with the updates released on day one. We've also backported the fix to some EOL operating systems. The package for Bionic is also done now, @papa zulu, feel free to give it a try...

Once the upstream is ready, we will do it as fast as we can.

Thanks for the details, could you raise a forwardauth feature request on openlitespeed repo directly?

'#' should be encoded. It seems no such a parameter to bypass the check, you need to either keep v1.9.2 or build the package with the custom changes.

I'll look into whether there's a workaround. In the meantime, you can downgrade to v1.9.2 to keep the service running smoothly.

Hi, It's part of the security hardening "[Improvement] Improve header/URL handling." Check the code from https://github.com/litespeedtech/openlitespeed/blob/master/src/http/httpreq.cpp#L93 What if you enter GET /upload.php?ID=ExampleUser&PASSWORD=abc%23123&temp=12.3 HTTP/1.1 instead, does...

How about changing "iDisplayLength:10" to e.g. "iDisplayLength:100" from the /usr/local/lsws/admin/html.open/res/js/plugin/datatables/dataTables.min.js file ?

Hi, I understand. However, I'm still unable to reproduce the redirect code issue. In my test case, I’m still getting a 403 response instead. I think it would be easier for you to get further assistance from LiteSpeed by submitting a support request to support@litespeedtech.com with this forum...

Based on my testing: When a request is blocked by ModSecurity, OLS returns the server’s default 403 error page. When a 403 is triggered by a rewrite rule or file permission, OLS returns the custom 403 error page. The default error page is a built-in feature, and cannot be modified.

Security enhancement should be included in the next OpenLiteSpeed release.

Thanks for the report, we will take a look.

I tried a similar setup, including upgrading and downgrading OLS with the lsup command and switching between PHP versions, but I still haven't been able to reproduce the issue. If the issue is still occurring, please send the issue to support@litespeedtech.com with this forum link appended for...

Thanks for the details. I will forward the issue to the dev team.

Could you provide an example of the full socket path that contains the .sock.<absurdly long numeric suffix>? For example, something like: **/tmp/lshttpd/example.com.sock.123456789** I'd like to check the actual length and format of the generated socket path.

So far we haven't received any similar reports. Could you upgrade again? If the loading issue occurs again, please add your domain and your origin server's IP address to your hosts file so you can access the site directly, bypassing the CDN. If the page still loads slowly or fails to load on an...