[FEATURE] - Branding and customizations.

[bitbound]

Subscribers will have access to customized, branded builds of the server, agents, and desktop clients. They will be able to choose their own product name, icon, color palettes, and server URL. These options will be recompiled in GitHub Actions (in a private repo) and signed using my existing Azure Key Vault flow.

I'm considering two different ways of implementing this. I'd like to hear from the community on which one they'd prefer, or if they'd prefer something different altogether. Since ControlR is now my only source of income, and this is the only monetized aspect of the project, it's important that people are happy with it.

I'll add each implementation as a separate comment to this issue. Please vote (using 👍) for which one you'd prefer. Or if you'd prefer neither, add a comment with a suggested alternative.

[bitbound]

Option 1 (custom image)

Shared steps for both options:

• User logs into a ControlR Subscriber's Portal website, using GitHub auth.
• The backend queries GitHub API to determine if the user is at or above the necessary sponsorship level.
  • It also checks if the user is part of an org that is sponsoring.
  • If this is the case, the user will need the required permissions from the org.

Steps specific to option 1:

• If authorized, the user can update the customizations/branding and run builds.
• Customization sets can be saved in "templates", so you can easily switch between different customizations.
• There will be "slots" for holding customized images.
  • I'm thinking of starting with 2 or 3 slots.
  • This allows users to test out new builds or experiment with branding, and quickly roll back to another image if necessary (without having to rebuild it).
• To update a slot with a new image, you select the customization template and ControlR version, then hit Build.
• When the image is built, it will show the command needed to pull the image.
• The image will be in a private GitHub registry and only accessible by the user/org.

Pros:

• Less things that can go wrong during upgrades.
• Probably less dev time/effort than option 2.

Cons:

• A little more initial setup due to the private Docker registry.

Note: Users should be able to supply a custom CSS file for the site, either as a workflow input or via Docker volume bind mount.

[bitbound]

Option 2 (in-server)

Shared steps for both options:

• User logs into a ControlR Subscriber's Portal website, using GitHub auth.
• The backend queries GitHub API to determine if the user is at or above the necessary sponsorship level.
  • It also checks if the user is part of an org that is sponsoring.
  • If this is the case, the user will need the required permissions from the org to create custom builds.

Steps specific to option 2:

• You'll be able to create/regenerate an API key here to use in your ControlR server.
• In your ControlR instance (using the public Docker Hub image), there will be a new Branding tab for server admins.
• Here, you will save your API key and choose branding options.
• After changing branding options, the ControlR backend will reach out to the my sponsor's portal backend, using the API key for authentiction.
• This will kick off new builds for each platform's agents and desktop clients, targeting the same version as the server that's requesting them.
• Like with option 1, these builds will run in GitHub Actions, and the new binaries will be signed using Azure Key Vault flow.
• Once finished, these will be downloaded by your ControlR backend and saved to a Docker volume.
• These customized versions will then override the default versions that come in the image.
• Icons and color customizations will also apply to the server's UI after reloading.

Pros:

• Avoids need to authenticate with custom Docker registry.
• Most of the user workflow stays inside ControlR.

Cons:

• More moving parts and edge cases that can go wrong.
• Probably more dev time/effort than option 1.

[PowershellScripter]

For the custom branding and logo, wouldnt a licensing db of some sort be a good option? The code can remain under the same image and a read only API call to the db licensing server on boot of the container will verify if the license is active and if it is, that will unlock the custom branding section of the server dashboard. The license key could be a key or the company's domain and you could mark in db the sponsorship, whether its monthly or permanent.
If the db API server ever changes, an upgrade of the code to a single image is all that needed to point to the new set of params.
This also gives end users the ability to have all customizations stay local. The code can point to the main branding and css style locations and pay-for-brand users can add custom media locations and if the subscription requirements are met, the code will reflect the custom media location upon start. If the api call reflects no active sub, it will default back to the main ControlR branding.

The caveats of this would be ensuring the db is always reachable and that the ControlR dashboard network isnt internally locked down (configure for over VPN connection only)

[bitbound]

@PowershellScripter Thanks for your input.

What you're suggesting with a licensing DB is essentially the same as Option 2. Except instead of a license key, you'd have an API key, which is used to authenticate with the sponsorship portal (i.e. licensing db). Upon successful authentication with the API key, it'd have all the information from GitHub's API about sponsorship level and such.

With Option 2, the color selections and icons will get saved in the instance's local DB and will show up immediately on the web.

However, the problem that the above options are trying to solve is that the binaries for the agent and desktop client can't be fully customized without rebuilding and resigning them. And the signing must happen from GitHub Actions in one of my repos (required by the integration with Azure Key Vault).

Some of the elements can be updated dynamically. If the agent and desktop client are running from a managed install, the server URL and tenant ID will already be known (as it was entered during installation and saved to the local settings). So it could grab the customizations from the server on startup and use those for most UI elements.

But it can't change the application icon (the .exe icon on Windows and the .app icon on Mac) without a rebuild. Changing those dynamically will be break the code signing signature.

The "quick support" client for ad-hoc sessions will be more problematic. In the public Docker image, that app will be downloaded and opened directly by end users on unmanaged computers. Not only will the executable icon be the default, but it will not know what server to connect to, what the tenant ID is, etc. The user would have to be instructed to enter this.

In order for that process to be seamless, so the end user just opens the app and is ready to receive support, the app needs to be custom-built.

So both of these options are primarily about getting those customized executables built, signed, and saved to the ControlR instance.

[PowershellScripter]

@bitbound After plugging our conversation into both chatgpt and grok to get some insight, they both suggest Option 1 as the recommended option forward.

A suggest for the customization if its not already on the list, The ability to add a css file or add css code during the build sequence. Or the ability to add a css file via docker volume. The latter does come with the caveat of people being able to just change the logos of the site via that file, but that still wouldnt give them the ability to change the logos of the binaries.

In case youa re interested in the short reads, heres the output that the models gave me.

gpt: https://chatgpt.com/s/t_69a71a81d41c8191b7c626f7005b8786
grok: https://x.com/i/grok/share/338a28d35eb14df1a404f74fd4429aff

[bitbound]

@PowershellScripter Thanks for the follow-up, @PowershellScripter . Much appreciated! :) The suggestions in those links are solid.

I'm also leaning toward Option 1. I'll add a note about the custom css file.