UserServiceMachine request model is missing accessTokenType supported by User Service V2
还没有人认领这个 Issue。
评估
调研方向
Locate the generated UserServiceMachine request model and the UserServiceCreateUserRequest and UserServiceUpdateUserRequest models, then inspect how the existing UserServiceAccessTokenType fields are represented. Regenerate the Python SDK against the current schema and add serialization coverage showing that accessTokenType is preserved in both create and update machine-user requests.
由索引模型根据 Issue 内容生成。
描述
Description
The generated UserServiceMachine request model does not expose accessTokenType, although current ZITADEL User Service V2 supports setting it when creating or updating a machine user.
This prevents Python SDK users from requesting JWT access tokens. ZITADEL otherwise defaults new machine users to opaque bearer tokens.
The SDK already contains:
- UserServiceAccessTokenType
- ACCESS_TOKEN_TYPE_BEARER
- ACCESS_TOKEN_TYPE_JWT
- access_token_type on the UserServiceMachineUser response model
However, the corresponding request model only contains name and description.
Environment
- zitadel_client==4.1.8
- Python 3.14.6
- This appears to be a generated-schema issue and is not Python-version-specific.
Reproduction
from zitadel_client.models import (
UserServiceAccessTokenType,
UserServiceMachine,
)
machine = UserServiceMachine(
name="example-client",
accessTokenType=UserServiceAccessTokenType.ACCESS_TOKEN_TYPE_JWT,
)
print(machine.model_dump(by_alias=True, exclude_none=True))
Actual output:
{"name": "example-client"}
The unrecognised accessTokenType input is silently discarded.
Consequently, using this model through UserServiceCreateUserRequest cannot send:
{
"machine": {
"name": "example-client",
"accessTokenType": "ACCESS_TOKEN_TYPE_JWT"
}
}
The same UserServiceMachine model is used by UserServiceUpdateUserRequest, so updating the access-token type is also unavailable.
Expected behaviour
UserServiceMachine should expose a field equivalent to:
access_token_type: UserServiceAccessTokenType | None = Field(
default=None,
alias="accessTokenType",
)
Serializing a create or update request should preserve the selected access-token type.
Upstream context
The missing API capability was reported in:
It was added to the core User Service V2 protobuf in:
The current protobuf contains access_token_type on the nested machine messages for both CreateUserRequest and UpdateUserRequest, but the Python SDK request model still reflects the older schema.
Suggested resolution
Please regenerate the Python SDK against a current ZITADEL core schema and add a serialization test confirming that accessTokenType is included in create and update machine-user requests.
- 主要语言
- Python
- 星标
- 16
- 派生
- 3
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
zitadel/client-python 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
zitadel/client-python#125 ·
-
难度 3/5 1-2 天 新手友好度 67/100
zitadel/client-python#145 ·
-
难度 2/5 1-3 小时 新手友好度 52/100
zitadel/client-python#99 ·
-
Release SDK for V5可能重新可做 @mridang 于 304 天前认领，目前没有进行中的 PR。 未关闭
zitadel/client-python#80 · 已指派 1 人 ·
-
难度 4/5 3-5 天 新手友好度 45/100
zitadel/client-python#78 ·
查看 zitadel/client-python 的全部 Issue
相似的 Issue
-
New Internship未关闭new_internship
难度 1/5 1 小时以内 新手友好度 70/100
-
[BUG] Reports tab: "Unban" button tooltip shows raw `{{ip}}` placeholder instead of the IP address未关闭bug javascript ui
难度 2/5 1-3 小时 新手友好度 68/100
bunkerity/bunkerweb#4001 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 1/5 1 小时以内 新手友好度 92/100
PedestrianDynamics/pyFDS-Evac#476 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
google/differential-privacy#516 ·
-
难度 2/5 1-3 小时 新手友好度 82/100
adobe-fonts/source-serif#153 ·