skizzerz

It only blocks spam on the “Contact Us” form when it’s configured to send submissions to a Commerce support department as well as spam submitted via a regular Commerce support request. It does not run on user registration nor on forum posts or other content. I could look into extending Akismet into other areas of the suite, get in touch via PM if you’re interested in that.

You missed the second half of what I wrote: "Use HTTPS for your API calls and ensure that the server's certificate is strictly validated." If the customer is able to easily reroute it to another site, you are likely failing the second prong of that message. Strict validation means that 1. the hostname/SAN in the certificate matches the host you are trying to reach, 2. the certificate chains up to a trusted CA, and 3. there are no expired or revoked certificates in the chain. You may need to explicitly opt-in to this strict validation in your REST library, consult the documentation for more details. The above can still be bypassed if the client adds a custom root CA to their machine and generates a spoofed certificate for that hostname, but that is more effort than simply setting up an entry in the hosts file. Pinning the CA certificate inside of your app (that is, setting it up so that CA certificate is the only trusted CA rather than relying on the system's root CA store) is one way to help make that even harder, although it means your application has a ticking time bomb embedded inside of it -- should the upstream site change CAs or the CA change their root certificate your app will break until you update the thumbprint. As such, I would personally recommend against pinning the CA certificate.

It is impossible to completely prevent this, because the customer can always control what code is running on their machine. Below are some common ways to help protect client applications however. None of these are 100% effective (because it is impossible to be 100% effective), but are more to "keep honest people honest" -- that is, someone who wants to break your licensing will figure out a way to do so. People who are curious but see the roadblocks will be more likely to give up, however. Encoding/obfuscation of source code Use HTTPS for your API calls and ensure that the server's certificate is strictly validated There are a plethora of other methods a quick search away, but the two above shouldn't cause much extra friction in your customers who are not trying to bypass your licensing. You don't want to make your anti-piracy measures so onerous that it breaks the application for paying customers.

Custom indicates that the plugin was not downloaded/installed from the Marketplace. If the plugins exist in the Marketplace, you can map them over. There should be a notification in your Admin CP for "Marketplace Setup" -- go ahead and run that.

This is already possible via Commerce, albeit for a regular product instead of a subscription. You can create a regular product that expires in 7 days and does not renew, and adds the user to whatever group while it's active.