{"version":"2.1.234","anchor":"setup-token-lifetime-is-plumbed-through-but-always-365-days","canonical_anchor":"setup-token-lifetime-is-plumbed-through-but-always-365-days","heading":"Setup-token lifetime is plumbed through but always 365 days","tier":"internal","area":"Auth","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234\/e\/setup-token-lifetime-is-plumbed-through-but-always-365-days","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234","markdown":"### Setup-token lifetime is plumbed through but always 365 days\n\nSetup tokens can now carry any lifetime, but everything still hands over the 365-day maximum.\n\n**What**\n\nThe `setup-token` flow now carries a token duration as data instead of a fixed sentence, so the login screen reports whatever lifetime it was handed: \"1-year\" when the value matches the one-year constant, and an explicit day count otherwise. Everything needed to issue a shorter token is present, but nothing in this build supplies a different value, so every token created is still the 365-day maximum.\n\n**Details**\n\n- The configured duration reaches the login component as an `expiresIn` value rather than as prebaked wording, which is what lets the screen state the real lifetime.\n- A ceiling constant caps the lifetime at 365 days, and a parser exists to turn a requested number of days into a duration.\n- That parser discards its input and always returns the maximum, 365 days or 31536000 seconds, so the derived wording always resolves to \"1-year\".\n- The rejection path is written but unreachable: an out-of-range value would print a message and exit with status 1.\n- No command-line option feeds a requested day count into the parser, so no user action changes a token lifetime in this build.\n\n**Evidence**\n\n`mode: \"setup-token\"`, `SETUP_TOKEN_MAX_EXPIRY_DAYS`\n\n- Area: Auth\n- Names: `setup-token`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}