These parameters could be used to deactivate a license, such as if someone were caught pirating, evidenced by the License Key File that may contain some information about them.

The methods cannot use zeroize at the moment

It might be useful to allow the version of a product to be updated, as well as the allows_offline parameter; however, I am unsure if a product should be able to switch from allowing offline licenses to disallowing offline licenses

Right now, to activate a license, there is a batch_get_item for 3 DynamoDB tables: the store table, the products table, and the license table.

For multiple licenses to be activated at once (for one store), this would require 2 + [number of products being activated] items to be fetched from the database. batch_get_item has a limit of 100 items that can be retrieved at once, and batch_write_item has a limit of about 25 or so, which is also performed in the request.

These will need to be completed:

• Remove License Activation method's dependency on the Products Table
• Update the License Activation method to be able to handle multiple products being activated
• Decrease the size of Product IDs to make these changes lighter on the database

Get item requests and write item requests are billed by the size of the items, as well as how many requests are made. There is a bit of a tradeoff here. We will be increasing the size of items in the Stores Table, but if we don't increase the size, then we would be reading and writing for up to n product items as well... I would say that the tradeoff will likely be worth it in the long run.

There should only be one create_license.proto, etc, not one for each individual request and each individual response

The plan for license activation is to use a single license code for every "product" a store has, and to activate the licenses for multiple products at a time. The plan for reactivation is to simply repeat the original license activation request regularly. However, if the user wishes to activate an offline license for one product, but one of the other products from a store does not support offline licenses, then it will currently return an error for any such products that do not support offline licenses.

To optimize this process where only one request is required to be made for multiple offline and online products to be activated, the program could fall back to an online activation when an offline license type is not supported by the product, instead of returning an error. This should be as simple as adding a few && product_allows_offline to some conditions.

The purpose of this field is to prevent offline activations for people who don't want there to be offline activations. This is a concern to some because from what I've read, products primarily begin to get pirated once the developer adds a method for performing offline activations.

The get_license_refactor would be a bit more messy if I don't change this. I originally wanted to keep things somewhat anonymized, but it only complicates things. Besides, DynamoDB tables are encrypted at rest.

Hopefully this won't be too bad, but I made a publish_public_keys that uses rusoto_s3, and it did not work correctly. Everything is set up to have it triggerable from EventBridge, but it doesn't work

There's no way to make some private values at the moment. Need to add environment variables

The variables aren't being correctly set in the build scripts

In license_activation, the check-up time needs to be before or when then license expires. Set the lower bound with std::cmp::min()

The offline code is currently case sensitive. Should be a simple fix

Get license needs to be refactored with minimal database get item requests.

Offline license activation probably shouldn't involve a 4 character code for the end user to append to their license code because it's kind of silly and could be susceptible to brute force, should someone find out someone else's license code.

The revision I have in mind is requiring the end user to click to enter an "Offline License Activation" menu, where there are two buttons: one for copying their machine ID to the clipboard (or saving a file containing their machine ID to their machine), and a button to activate the license using a key file.

The key file would need to be generated by the store's website, where they will need a form that accepts either a file or a machine ID, and then the website will need to send a request to the license_activation_refactor function using the user's machine ID, and the server will need to append -offline-[4 character offline code] to the end of the license code that is stored for the user. Don't worry, the store should already have access to this value if the user has a license, and if the store has saved their license data in the store's database. The store will also need to sign this request in the same manner that all of the other requests are signed with the store's private key.

Will probably need to store the GetLicenseResponse as binary

• Restrict maximum machine limits to 10 or so, and instruct stores to limit how many licenses a customer can purchase
• limit the maximum length for custom responses
• limit length of computer names
• Ensure that the frequency of client callbacks to the server is less than the license type's expiration period, and set a minimum value for these fields.

This code hasn't been touched in a while. The license_auth API method was my first ever Rust project, so I was a complete beginner and didn't really know how Rust worked, especially the ? symbol used for automatically returning on Error Results. create_license was the most recent one I created, about a year ago.

There's quite a bit of work to be done here, starting off with collecting all of the utilities spread throughout here and making new utilities to go in the utils crate.

Also, I will be migrating away from the JUCE authentication scheme because it is slow and it is not a constant-time implementation, meaning that it is vulnerable to timing attacks. Even if it was implemented in constant time, it would be about 10x slower, which is why I have created an entirely new cryptographic protocol called crypto-on-the-edge. This protocol is wickedly fast and wickedly secure, using Protocol Buffers and Elliptic Curve Cryptography, and it doesn't even need to save any private keys anywhere—not even the private keys for plugins.

Here's a general list of things I need to do:

• migrate existing utils to utils
• make universal error type
• make database hashmap util method for extracting a piece of data with the error handled within the method, rather than manually checking that it is there
• do the same with any other frequently accessed options
• change debug mode to use debug assertions to determine if debug mode is active
• migrate to crypto-on-the-edge and delete all the cryptography code here... there's no reason to use OpenSSL when I'm also using RustCrypto
• add open source license after removing JUCE cryptography code, since JUCE might use a different license than the one that I will use
• migrate to 100% Protocol Buffers

Refactor progress:

• Register Store
• Create Plugin/Product
• Create License
• Get License
• License Auth

I was writing get_license_refactor and noticed that if there were over 100 different machines using one license from one store, this program would not be able to fetch all of them in one go. I will probably enforce some limits in the validations to ensure that there can only be up to maybe 10 machines per license to prevent this.

Anyway, the change from string sets to hashmaps allows there to be more than just machine IDs in the license items. I think I will just put the computer names and OS names in there for now. This will make it so that a get license request only uses 2 database reads

Apparently after adding Protocol Buffers into the mix, cross compiling might be a little more complicated. cross uses docker under the hood, and does not have protoc by default. This can be amended using a Cross.toml file in the workspace directory, as well as a Dockerfile. Some issues have arisen with that regard, as some base images don't have GCC-13. Will likely be using an alpine image

• Update Product - #39
• [ ] Recover Store - in case someone switches installations of WordPress, they could invoke this method with their signature on it
• Recover product public key - #39
• Get product IDs - in case someone didn't save their product IDs to the database
• Deactivate Machines - #37
• Regenerate License Code - #37
• Increase Machine Limit

When creating a product, there is a Map<String, LanguageSupport> field on the request. A LanguageSupport field looks like this:

message LanguageSupport {
    string incorrect_offline_code = 1;
    string license_no_longer_active = 2;
    string no_license_found = 3;
    string over_max_machines = 4;
    string trial_ended = 5;
    string success = 6;
}

The fields here are used to contain responses in a specific language, and these are mapped by the language name or ID. The user will provide the ID as a string when creating a product that is associated with the LanguageSupport fields.

The problem

If a user sets up language support for multiple languages for multiple plugins, then they might have to re-enter a bunch of sentences in a bunch of languages for each product.

Solutions

Store-specific responses

There could be store-specific responses kept in the database, that allows a store to reuse their responses across different products.

Global/default responses

There could be some default responses, but default responses might give away the fact that a given store is using this service. I also don't feel like translating responses into languages that I won't be using.

Client-side response translation fetching

The client side code could receive a response index from the server, and then fetch a translation from a GitHub site or a static website. This would be the best option for people being able to share translated messages with each other, and it could also be integrated with AI a bit better through the client side. It would also be extremely light on the database. I think I will likely go with this option.

*Note: Just because these responses might be able to be translated into languages does not mean that the software's GUI is automatically translated. Both would need to be translated for any of this to work, and there would need to be a way for a user to select the language within the software's installer or the GUI, and then the client would need to send the user's language to the server, or have it fetch the responses for the specific language from an online or maybe offline resource.

Some configuration details should probably be entered only once, if at all. Also, it would make things a bit easier on the back end if some of the details were solely in the Stores table.

Fields such as:

• license type expiration periods
• license type callback periods
• custom responses from the server

This could save quite a bit of requests if any clients were to use this licensing service for multiple products. The only problem is the initial license activation after a user installs multiple products.

The client-side problem

If a user installs multiple products and is only able to activate each product after they open it for the first time, then they will need to submit as many license_activation requests as the amount of products they installed (initially). Ideally, they would only need to activate them once initially, and then at some fixed rate later on.

Solutions

The main solution would be to use a standalone licensing application that runs in the background, but there is another solution:

Upon installing via a .exe installer (or MSI or pkg), for each package that is installed, a licensing file could be placed in a standard location (such as the AppData folder). The files would primarily contain the product_ids of the installed products. After opening any of the installed applications, they could be hit with a licensing screen, and after entering the license code (which is the same for all of the vendor's applications), the licensing program searches for the file(s) containing the product_ids of the installed products, and uses those IDs to submit a single license_activation request.

This setup would require the vendor to:

• know which directory they need to install the initial licensing file in, and
• know what to put in the licensing file, how to format it, and either
• use a single installer for multiple programs
• use the same licensing file info across multiple installers

The problem with activating in the product's installer

There could be a license activation screen in the installer itself, but then it would run into the same problem if it was only installing one application.