Your documentation about Bot Protection doesn't make sense. It says to add to whitelist click X and to remove from whitelist click the checkmark. Also, in the screens such as Traffic requests, every entry whether in Allowed or Blocked as a green arrow next to it. When hovering above the checkmark it says "Whitelist this IP". That seems backwards, and even more confusion is that these same rules apply for both Allowed and Blocked tabs. I am not even sure what actions to take and I don't want to block or allow an IP accidentally. What would make more sense if it just showed checkmark for allowed and X for not allowed, no matter what screen I am looking at. Can you please submit this to your development team for review?

Please, consider adapting the Dashboard to allow the adding of Ed25519 keys for SSH sessions.

RSA, the cryptographic method currently in place for SSH sessions, is mathematically breakable, which is why long keys are necessary to keep security; nevertheless, there is always the possibility they could be cracked. Also, for long term protection, RSA keys should now, supposedly, contain at least 15360 bits; of course, this is unrealistic in a real environment, as it decreases performance and increases strain on the communication channels.

I pledge for the usage of Ed25519, considering a mere 256 bit key is enough to guarantee long term protection, simplifying drastically the identities used for logging into servers and increasing security all at the same time.

OpenSSH, the SSH software ran on most Linux servers, just like my Cloudways Digital Ocean droplet, has supported Ed25519 cryptography since v6.5, released in January 2014, meaning most servers should support it out of the box. My specific server runs OpenSSH v7.4, for example, many releases ahead of the one with the Ed25519 implementation.

Even though it might sound a little tricky, this suggestion should not be too complicated to implement: the software to handle these cryptographic method is already in place in most, if not all servers, so the only thing necessary to get this online is a change in the front-facing console, or Dashboard, clients like me use to configure their servers. It would, however, significantly improve security for SSH connections and make them airtight for the future, as well as tranquilising the few of us, such as myself, who dread of seeing their RSA keys cracked by someone malicious.

Once again, please consider taking action on this.

Apologies, I am sure most or all of these have been suggested and I am suggesting a few at once here.

• File manager

• Ability to rename accounts. I am a developer and have 5 accounts and more soon that I am working on for different clients. In the drop down it shows their name, I should be able to rename it so I see the name of the client, not the name they signed up with which sometimes is not someone I know and am not sure which websites it is and need to click around to find the correct account.

• Login timeout. If I don't use the Cloudways admin page for as little as an hour or two I get logged out and need to log back in. I think the timeout should be at least 12 if not 24 hours. I waste a lot of time each day waiting to log back in (click on a link, the single application page loads, then it realizes I am timeout, redirects me to the login screen, need to log in, land back on the main page with the servers, need to click into where I wanted to be...)

• Link should be openable in another tab. Nothing in the CW admin that is a link is an actual link. It is all controlled with JS, so I can't right click and open in another tab.

From Wordfence:
We tested this issue using the Breeze plugin and found two problems.

This affects Wordfence’s two-factor authentication, if one or more users has set up two-factor authentication, and the reCAPTCHA feature, so using either or both of those features would be broken by Breeze modifying our script tags.

In Breeze’s “Advanced Options”, under “Delay JS inline scripts”, you can remove the line that says “nonce” to avoid having our script deferred.

You will also need to turn off the “JS” option under “Minifcation” in Breeze’s settings. We don’t know why they are modifying our script tag when minification is off but not on, but they have removed parameters that are necessary when loading Google’s api.js file.

Enabling JS minification may work on your site, but that has the potential to break other scripts. You can try it if you like, but be sure to test your site’s functionality if you do. Otherwise, we recommend disabling Breeze temporarily, until their next release that may fix these new issues.

Me: I tried the above suggestion which did not work. Cloudways have downgraded Breeze to an earlier version for me.

Can you please fix the compatibility issue.

Thank you

Currently the created date only shows on the "Applications" page, which paginates apps in groups of 10. We've go over 150 apps, so when we need to find the created date we have to trawl through pages to find the correct app.

So it would be super helpful to have the "Created Date" for an application within the details of a single app. As for where, maybe above/below the "Applications Management" title on the left hand side. Or below that menu? Or within one of the pages - e.g. Access Details.

Should be super simple to add in wherever! Just somewhere within the single app :)

Thanks!!!