Preparing for the 6.2026.902.1 Update

Updated by Dean Perry

Version 6.2026.902.1 changes how ToolHound authenticates users and enforces permissions. Three items need attention before you apply the update.

1. Set the JWT signing key — On Premise only

ToolHound signs access tokens with a key held in appsettings.json under JwtToken:SigningKey. Starting with this release, the application will not start if that key is present but too short, or if it still contains the bracketed placeholder value copied from appsettings.example.json.

Check your appsettings.json:

  • If JwtToken:SigningKey contains a bracketed placeholder such as [YOUR_SIGNING_KEY], replace it with a value of at least [minimum length] characters.
  • If JwtToken:SigningKey contains a real value of at least [minimum length] characters, no change is required.
  • If the JwtToken section is absent entirely, no change is required. ToolHound generates a key on first start and saves it under the licenses/ folder.

Note callout: Leaving the setting out is safe. Leaving the placeholder in is not — the application will fail to start and the error will be recorded in [log location].

Cloud subscribers do not need to do anything. This setting is managed by ToolHound.

2. Expect every user and integration to sign in again

Applying this update invalidates every access token issued before the upgrade. After the update:

  • Browser users are returned to the login page.
  • TH6 Mobile users must sign in again. Cached credentials from before the update will not be accepted.
  • Kiosk devices must sign in again.
  • API clients and integrations receive [status code] on their next call and must request a new token from /connect/token.

Tell your users and whoever maintains your integrations before you apply the update. An unattended integration that stores a long-lived token will stop silently until someone re-authenticates it.

3. Review your roles

Role permissions are now enforced on the API as well as in the browser. Before this release, an action hidden from a role in the browser could still be performed through the API by any signed-in user. It can no longer.

Most sites will see no change. A site is likely to see a change if it has:

  • Integrations that call ToolHound with a low-privilege service account.
  • Roles where an action was set to View Only or No Access on the assumption that hiding it in the menus was sufficient.

To check your configuration before updating:

  1. [step]
  2. [step]
  3. [step]

After the update

If users report being unable to sign in, work through these in order:

  • "Invalid login attempt" repeating for one user — the account may now be locked. See About Account Lockout.
  • A user reset their password and no email arrived — check whether the account has an email address on file. Since this release, an account with no address still reaches the confirmation page. See Using Forgot / Reset Password.
  • An integration returns [status code] — request a fresh token, then confirm the service account's roles grant the actions the integration performs.

See also:

How did we do?