Variables and blacklist
Variables keep secrets out of your binary. The blacklist cuts a client off mid session.
Variables
A variable is a named string encrypted at rest and handed only to authenticated clients at or above its minimum level. Use it for anything you would otherwise compile in: a webhook URL, an API token, a feature flag, a Discord invite.
std::string webhook;
if (client.variable("webhook", webhook)) {
// fetched over the encrypted channel, never stored in the binary
}
The advantage over hardcoding is that you can change the value without shipping a new build, and a
customer reversing your binary finds nothing. The value is encrypted with APP_KEY, so it is
not readable from a database dump either.
A variable is still handed to any valid key, so treat it as a shared secret among your customers, not as something only you know. Gate sensitive values behind a higher minimum level.
Blacklist
Entries are checked on every authenticated request, not only at login, so a blocked client loses access in the middle of a session rather than at its next restart.
| Type | Use when |
|---|---|
| IP address | A single abusive source. Weak against anyone with a VPN. |
| Hardware ID | A specific machine. Stronger, and it survives an IP change. |
Matching is exact, so paste the value straight from the activity log. Entries can carry a reason, which is returned to the client so support can explain the block, and an optional expiry for temporary bans. Expired entries are cleaned up hourly.
Prefer banning the key over blacklisting, since that is targeted and reversible. Reach for the hardware blacklist when someone is burning through keys from the same machine.