mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
bbc9b152e6
* MM-68417, MM-68420: API support for PAT expiry and admin policy settings
POST /users/{id}/tokens now accepts a client-supplied expires_at
(previously stripped per the TODO in api4/user.go), and the create app
method enforces two new ServiceSettings:
- EnforcePersonalAccessTokenExpiry (bool, default false): when on,
rejects creates with expires_at == 0
- MaximumPersonalAccessTokenLifetimeDays (int, default 0 = unlimited):
caps how far in the future expires_at may be
Rejections return distinct app error ids so clients can disambiguate:
expires_at_required, expires_at_in_past, expires_at_too_far.
GET /users/{id}/tokens already serializes expires_at via the model's
JSON tag added in MM-68419; clients derive token status (active /
expired / inactive) from is_active + expires_at without a separate
server-side field, keeping the response shape minimal.
The Client4 helper CreateUserAccessToken gained an optional variadic
expiresAt parameter (and the mmctl Client interface + mock match)
rather than introducing a parallel WithExpiry method.
Refs: MM-68417, MM-68420
* MM-68417: exempt bot accounts from PAT expiry enforcement
Mirrors the existing EnableUserAccessTokens bypass at session.go:453,
where bot tokens are allowed even when human PATs are disabled. Bots
are programmatic clients that typically need long-lived credentials,
and integrations that provision them would otherwise break the moment
an admin enables EnforcePersonalAccessTokenExpiry — turning a settings
toggle into a footgun. The expiry policy now applies only to human
users; bots can still be given a future expires_at by callers that
want it, but the server won't require one.
Locked in by a new TestCreateUserAccessToken/bot_tokens_are_exempt
subtest that enables enforcement plus a 30-day cap, creates a bot,
and asserts a non-expiring token is accepted.
Refs: MM-68417
* MM-68420: bound MaximumPersonalAccessTokenLifetimeDays in isValid
Negative values silently meant "unlimited" (the runtime check is `> 0`),
and very large values overflow int64 when computing
`now + days*86_400_000` at token-creation time, producing a wrap-around
that either rejects all reasonable expiries or accepts past timestamps
as valid.
Bound the setting in ServiceSettings.isValid to [0, MaxPersonalAccess
TokenLifetimeDays] where the cap is 36500 (100 years) — past any
realistic operational use and well clear of int64 overflow. Surfaces
as a config validation error rather than a silently-broken runtime
check. New TestServiceSettingsIsValid cases lock in zero, negative,
upper-bound, and above-upper-bound behavior.
Refs: MM-68420
* MM-68417: reject multiple expiresAt values in Client4 helper
CodeRabbit caught that the variadic CreateUserAccessToken silently used
expiresAt[0] when callers passed more than one value, masking a
mis-call instead of failing fast. Return an error in that case so the
misuse is visible at the call site rather than producing a token with
the wrong (or right-but-coincidental) expiry.
Refs: MM-68417
* MM-68417: make expiresAt a required parameter on Client4.CreateUserAccessToken
Drop the variadic in favor of a regular int64 parameter. The variadic
form silently dropped extra values and made a misuse undetectable at
the call site (per CodeRabbit review on PR 36706); the previous fix
guarded against >1 values at runtime, but a required parameter is
strictly better — the compiler now refuses the misuse and every caller
is forced to make a deliberate decision about expiry. Existing callers
that want the old behavior pass 0 (== never expires).
Refs: MM-68417
* MM-68417: add --expires-in flag to mmctl user token generate
Adds an --expires-in duration flag so operators can create expiring
PATs via the CLI. Accepts the standard Go duration syntax plus a
trailing 'd' for days (the common case for token lifetimes), e.g.
--expires-in 90d, --expires-in 12h, --expires-in 1h30m. Empty (the
default) means no expiry — matching prior behavior. Without this
flag the command was unusable once an admin enables
EnforcePersonalAccessTokenExpiry, since every create would fail with
app.user_access_token.expires_at_required.app_error.
Flag parsing now happens before the user-lookup API call so the
command fails fast on invalid input. Regenerated mmctl docs reflect
the new flag.
Refs: MM-68417
* MM-68417: cap --expires-in day count to prevent time.Duration overflow
parseExpiresIn returns time.Duration(days) * 24 * time.Hour, which is
int64 nanoseconds and overflows past ~106751 days (CodeRabbit caught
this). Cap at model.MaxPersonalAccessTokenLifetimeDays (36500) so the
CLI rejects values the server would reject anyway, well below the
int64-overflow point. Adds two test cases (at-cap and beyond-cap) to
TestParseExpiresIn.
Refs: MM-68417
* MM-68420: collapse PAT expiry settings into a single max-lifetime setting
Remove ServiceSettings.EnforcePersonalAccessTokenExpiry and fold the
policy onto MaximumPersonalAccessTokenLifetimeDays: 0 means no policy
(never-expiring tokens allowed, no cap), while a value > 0 requires every
new token to expire within that many days. The two-setting design let an
admin set a maximum but leave enforcement off, silently allowing
never-expiring tokens to sidestep the cap; the only combination the
boolean added (require expiry, no upper bound) has little practical
value. The removed field was introduced on this branch and never
released, so this is not a breaking change.
---------
Co-authored-by: Hanzo Dev <[email protected]>
55 lines
1.6 KiB
ReStructuredText
55 lines
1.6 KiB
ReStructuredText
.. _mmctl_token_generate:
|
|
|
|
mmctl token generate
|
|
--------------------
|
|
|
|
Generate token for a user
|
|
|
|
Synopsis
|
|
~~~~~~~~
|
|
|
|
|
|
Generate token for a user. Use --expires-in to set an expiry, which may be required by the server's MaximumPersonalAccessTokenLifetimeDays setting.
|
|
|
|
::
|
|
|
|
mmctl token generate [user] [description] [flags]
|
|
|
|
Examples
|
|
~~~~~~~~
|
|
|
|
::
|
|
|
|
generate testuser test-token
|
|
generate testuser ci-token --expires-in 90d
|
|
generate testuser short-lived --expires-in 12h
|
|
|
|
Options
|
|
~~~~~~~
|
|
|
|
::
|
|
|
|
--expires-in string Duration after which the token expires (e.g. 90d, 12h, 30m). Accepts the standard Go duration syntax plus a 'd' (days) suffix. If empty, the token does not expire.
|
|
-h, --help help for generate
|
|
|
|
Options inherited from parent commands
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
::
|
|
|
|
--config string path to the configuration file (default "$XDG_CONFIG_HOME/mmctl/config")
|
|
--disable-pager disables paged output
|
|
--insecure-sha1-intermediate allows to use insecure TLS protocols, such as SHA-1
|
|
--insecure-tls-version allows to use TLS versions 1.0 and 1.1
|
|
--json the output format will be in json format
|
|
--local allows communicating with the server through a unix socket
|
|
--quiet prevent mmctl to generate output for the commands
|
|
--strict will only run commands if the mmctl version matches the server one
|
|
--suppress-warnings disables printing warning messages
|
|
|
|
SEE ALSO
|
|
~~~~~~~~
|
|
|
|
* `mmctl token <mmctl_token.rst>`_ - manage users' access tokens
|
|
|