Repository navigation
Add IP restrictions to service tokens - #1527
Open
mscoutermarsh wants to merge 1 commit into
Open
mscoutermarsh wants to merge 1 commit into
mscoutermarsh wants to merge 1 commit into
Conversation
Co-authored-by: Mike Coutermarsh <[email protected]>
no-itsbackpack
approved these changes
Nov 15, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Add
--cidrsonpscale service-token createandpscale service-token updateso a service token can be limited to IPv4 addresses or CIDR ranges.Details
Decisions
pscale password update --cidrs: a repeatable or comma-separated--cidrsflag. The field is omitted when the flag is not passed. A pointer to the slice is sent when it is, including an empty slice, so--cidrs ""clears the restriction instead of sending a blank entry.pscale service-token update <id> --cidrs. It sendsPATCH /organizations/:organization/service-tokens/:idwith body{ "cidrs": [...] }and no other keys. There was no service-token update command before this.IP restrictions must be a list of valid IPv4 addresses or ranges. That message is printed as-is.cidrscolumn on list, show, and create, andcidrsin JSON.showandupdateJSON keep the existing show shape and do not print the token secret. HumanupdateprintsIP restrictions: ...orIP restrictions: none, same as password update.duplicateprintscidrswhen the response includes them. It does not send its own list. Copying the restriction onto the new token is left to the server.Tests
TestServiceToken_CreateCmd— create omitscidrswhen the flag is absent.TestServiceToken_CreateCmdWithCIDRs— create sends the list and prints it.TestServiceTokens_CreateWithCIDRs— POST body is thecidrsarray.TestServiceTokens_UpdateCIDRs— PATCH path and body are only{ "cidrs": ["203.0.113.10/32"] }.TestServiceTokens_UpdateClearsCIDRs— an empty list is sent as{ "cidrs": [] }, not omitted.TestServiceToken_UpdateCmdSetsCIDRs,TestServiceToken_UpdateCmdClearsCIDRs,TestServiceToken_UpdateCmdRequiresCIDRs— flag wiring, clear, and the missing-flag error. Update JSON includescidrsand not the secret.TestServiceToken_ShowCmdandTestServiceToken_ShowCmdHuman— the list is in show JSON and in the human table.Terminal capture (run against a local API; token values redacted)
Skipped
pscale auth loginto the current IP. That is a later change.Risks
CIDRsnil unless it means to replace the list. Nil omits the field; a set pointer replaces it, and an empty slice clears it.--cidrs ""depends on the same flag behavior as password update. The clear test covers it.cidrs. It is null when the token has no restriction.