# Which Problems Are Solved
This PR aims to clarify how to use the zitadel SDK with OAuth token
introspection.
# How the Problems Are Solved
Reworked the setup process on console needed to create the JSON key and
a PAT.
# Additional Changes
- Closes#5559
# Which Problems Are Solved
List organization integration test fails sometimes due to incorrect
sorting of results.
# How the Problems Are Solved
Add sorting column to request on list organizations endpoint and sort
expected results.
# Additional Changes
None
# Additional Context
None
# Which Problems Are Solved
When retrieving the information of an IdP intent, depending on the IdP
type (e.g. Apple), there was issue when mapping the stored (event)
information back to the specific IdP type, potentially leading to a
panic.
# How the Problems Are Solved
- Correctly initialize the user struct to map the information to.
# Additional Changes
none
# Additional Context
- reported by a support request
- needs backport to 3.x and 2.x
# Which Problems Are Solved
- Allow users to use SHA-256 and SHA-512 hashing algorithms. These
algorithms are used by Linux's crypt(3) function.
- Allow users to import passwords using the PHPass algorithm. This
algorithm is used by older PHP systems, WordPress in particular.
# How the Problems Are Solved
- Upgrade passwap to
[v0.9.0](https://github.com/zitadel/passwap/releases/tag/v0.9.0)
- Add sha2 and phpass as a new verifier option in defaults.yaml
# Additional Changes
- Updated docs to explain the two algorithms
# Additional Context
Implements the changes in the passwap library from
https://github.com/zitadel/passwap/pull/59 and
https://github.com/zitadel/passwap/pull/60
# Which Problems Are Solved
LDAP userfilters are joined, but as it not handled as a list of filters
but as a string they are not or-joined.
# How the Problems Are Solved
Separate userfilters as list of filters and join them correctly with
"or" condition.
# Additional Changes
None
# Additional Context
Closes#7003
---------
Co-authored-by: Marco A. <kwbmm1990@gmail.com>
# Which Problems Are Solved
When users are removed, their auth factors stay in the projection. This
data inconsistency is visible if a removed user is recreated with the
same ID. In such a case, the login UI and the query API methods show the
removed users auth methods. This is unexpected behavior.
The old users auth methods are not usable to log in and they are not
found by the command side. This is expected behavior.
# How the Problems Are Solved
The auth factors projection reduces the user removed event by deleting
all factors.
# Additional Context
- Reported by support request
- requires backport to 2.x and 3.x
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
Replace this example text with a concise list of problems that this PR
solves.
- Organization list lacked the ability to filter by organization ID
- No efficient method was provided for users to search organizations by
ID
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
- Added organization ID filtering functionality to
`filter-org.component.ts`
- Added `ID` to the `SubQuery` enum
- Added `ID` case handling to `changeCheckbox`, `setValue`, and
`getSubFilter` methods
- Added ID filter UI to `filter-org.component.html`
- Added checkbox and text input field
- Used translation key to display "Organization ID" label
- Added new translation key to translation file (`en.json`)
- Added `FILTER.ORGID` key with "Organization ID" value
# Additional Changes
Replace this example text with a concise list of additional changes that
this PR introduces, that are not directly solving the initial problem
but are related.
- Maintained consistency with existing filtering functionality
- Ensured intuitive user interface usability
- Added new key while maintaining translation file structure
# Additional Context
Replace this example with links to related issues, discussions, discord
threads, or other sources with more context.
Use the Closing #issue syntax for issues that are resolved with this PR.
- Closes#8792
- Discussion #xxx
- Follow-up for PR #xxx
- https://discord.com/channels/xxx/xxx
---------
Co-authored-by: Marco A. <kwbmm1990@gmail.com>
# Which Problems Are Solved
We saw high CPU usage if many events were created on the database. This
was caused by the new actions which query for all event types and
aggregate types.
# How the Problems Are Solved
- the handler of action execution does not filter for aggregate and
event types.
- the index for `instance_id` and `position` is reenabled.
# Additional Changes
none
# Additional Context
none
# Which Problems Are Solved
In rare cases there was a possibility that multiple users were found by
a loginname. This prevented the corresponding user to sign in.
# How the Problems Are Solved
Fixed the corresponding query (to correctly respect the org domain
policy).
# Additional Changes
None
# Additional Context
Found during the investigation of a support request
# Which Problems Are Solved
#9837 added a new index `es_instance_position` on the events table with
the idea to improve performance for some projections. Unfortunately, it
makes it worse for almost all projections and would only improve the
situation for the events handler of the actions V2 subscriptions.
# How the Problems Are Solved
Remove the index again.
# Additional Changes
None
# Additional Context
relates to #9837
relates to #9863
We are bringing our DPA and privacy policy document in line with our
changes to the corporate structure, changes to subprocessors, and new
cookie technologies.
This PR replaces #3055 which included more changes to terms of service.
The changes to terms of service will follow in a second step.
---------
Co-authored-by: Florian Forster <florian@zitadel.com>
# Which Problems Are Solved
The execution handler projection handles all events to check if an
execution has to be provided to the worker to execute.
In this logic all events would be processed from the beginning which is
not necessary.
# How the Problems Are Solved
Add the current state to the execution handler projection, to avoid
processing all existing events.
# Additional Changes
Add custom configuration to the default, so that the transactions are
limited to some events.
# Additional Context
None
# Which Problems Are Solved
Misleading information on member endpoint requests.
# How the Problems Are Solved
Add comment to member endpoint requests that the request is invalid if
no roles are provided.
# Additional Changes
None
# Additional Context
Closes#9415
Co-authored-by: Fabienne Bühler <fabienne@zitadel.com>
# Which Problems Are Solved
Currently, users can't delete themselves using the V2 RemoveUser API
because of the redunant API middleware permission check.
On main, using a machine user PAT to delete the same machine user:
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
ERROR:
Code: NotFound
Message: membership not found (AUTHZ-cdgFk)
Details:
1) {
"@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
"id": "AUTHZ-cdgFk",
"message": "membership not found"
}
```
Same on this PRs branch:
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
{
"details": {
"sequence": "3",
"changeDate": "2025-05-06T13:44:54.349048Z",
"resourceOwner": "318838541083804033"
}
}
```
Repeated call
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
ERROR:
Code: Unauthenticated
Message: Errors.Token.Invalid (AUTH-7fs1e)
Details:
1) {
"@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
"id": "AUTH-7fs1e",
"message": "Errors.Token.Invalid"
}
```
# How the Problems Are Solved
The middleware permission check is disabled and the
domain.PermissionCheck is used exclusively.
# Additional Changes
A new type command.PermissionCheck allows to optionally accept a
permission check for commands, so APIs with middleware permission checks
can omit redundant permission checks by passing nil while APIs without
middleware permission checks can pass one to the command.
# Additional Context
This is a subtask of #9763
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
There were some misunderstandings on how different points would be
needed to be applied into existing API definitions.
# How the Problems Are Solved
- Added structure to the API design
- Added points to context information in requests and responses
- Added examples to responses with context information
- Corrected available pagination messages
- Added pagination and filter examples
# Additional Changes
None
# Additional Context
None
# Which Problems Are Solved
When a user changes their password, Zitadel needs to terminate all of
that user's active sessions. This query can take many seconds on
deployments with large session and user tables. This happens as part of
session projection handling, so doesn't directly impact user experience,
but potentially bogs down the projection handler which isn't great. In
the future, this index could be used to power a "see all of my current
sessions" feature in Zitadel.
# How the Problems Are Solved
Adds new index on `user_id` column on `projections.sessions8` table.
Alternatively, we can index on `(instance_id, user_id)` instead but
opted for keeping the index smaller as we already index on `instance_id`
separately.
# Additional Changes
None
# Additional Context
None
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
Step 54 was not executed during setup.
# How the Problems Are Solved
Added the step to setup jobs
# Additional Changes
none
# Additional Context
- the step was added in https://github.com/zitadel/zitadel/pull/9837
- thanks to @zhirschtritt for raising this.
# Which Problems Are Solved
Some projection queries took a long time to run. It seems that 1 or more
queries couldn't make proper use of the `es_projection` index. This
might be because of a specific complexity aggregate_type and event_type
arguments, making the index unfeasible for postgres.
# How the Problems Are Solved
Following the index recommendation, add and index that covers just
instance_id and position.
# Additional Changes
- none
# Additional Context
- Related to https://github.com/zitadel/zitadel/issues/9832
# Which Problems Are Solved
The sorting column of action targets and executions defaults to the ID
column instead of the creation date column.
This is only relevant, if the sorting column is explicitly passed as
unspecified.
If the sorting column is not passed, it correctly defaults to the
creation date.
```bash
# ❌ Sorts by ID
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"sortingColumn": "TARGET_FIELD_NAME_UNSPECIFIED"}' localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
# ❌ Sorts by ID
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"sortingColumn": 0}' localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
# ✅ Sorts by creation date
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
```
# How the Problems Are Solved
`action.TargetFieldName_TARGET_FIELD_NAME_UNSPECIFIED` maps to the
sorting column `query.TargetColumnCreationDate`.
# Additional Context
As IDs are also generated in ascending, like creation dates, the the bug
probably only causes unexpected behavior for cases, where the ID is
specified during target or execution creation. This is currently not
supported, so this bug probably has no impact at all. It doesn't need to
be backported.
Found during implementation of #9763
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
In Actions v2, if a target is removed, which is still used in an
execution, the target is still listed when list executions.
# How the Problems Are Solved
Removed targets are now also removed from the executions.
# Additional Changes
To be sure the list executions include a check if the target is still
existing.
# Additional Context
None
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Previously, if a target was deleted but still referenced by an
execution, it became impossible to load the executions.
# How the Problems Are Solved
Missing targets in the execution table are now gracefully ignored,
allowing executions to load without errors.
# Additional Changes
Enhanced permission handling in the settings sidenav to ensure users
have the correct access rights.
# Which Problems Are Solved
Sort Executions by ID in the Actions V2 view. This way All is the first
element in the table.
# How the Problems Are Solved
Pass ID sorting to the Backend.
# Additional Changes
Cleaned up some imports.
# Additional Context
- Part of Make actions sortable by hirarchie #9688
# Which Problems Are Solved
Users from Google IDP's are not unmarshalled correctly in intent
endpoints and not returned to callers.
# How the Problems Are Solved
Provided correct type for unmarshalling of the information.
# Additional Changes
None
# Additional Context
None
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Instance that had improved performance flags set, got event errors when
getting instance features. This is because the improved performance
flags were marshalled using the enumerated integers, but now needed to
be unmashalled using the added UnmarshallText method.
# How the Problems Are Solved
- Remove emnumer generation
# Additional Changes
- none
# Additional Context
- reported on QA
- Backport to next-rc / v3
# Which Problems Are Solved
The `auth.auth_requests` table is not cleaned up so long running Zitadel
installations can contain many rows.
The mirror command can take long because a the data are first copied
into memory (or disk) on cockroach and users do not get any output from
mirror. This is unfortunate because people don't know if Zitadel got
stuck.
# How the Problems Are Solved
Enhance logging throughout the projection processes and introduce a
configuration option for the maximum age of authentication requests.
# Additional Changes
None
# Additional Context
closes https://github.com/zitadel/zitadel/issues/9764
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Webkeys were not generated with new instances when the webkey feature
flag was enabled for instance defaults. This would cause a redirect loop
with console for new instances on QA / coud.
# How the Problems Are Solved
- uncomment the webkeys section on defaults.yaml
- Fix field naming of webkey config
# Additional Changes
- Add all available features as comments.
- Make the improved performance type enum parsable from the config,
untill now they were just ints.
- Running of the enumer command created missing enum entries for feature
keys.
# Additional Context
- Needs to be back-ported to v3 / next-rc
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
In some docs pages, we propose to generate a Zitadel masterkey using the
command `tr -dc A-Za-z0-9 </dev/urandom | head -c 32`. However, this
fails on some systems/locations with the error message `tr: Illegal byte
sequence`.
# How the Problems Are Solved
We replace the command by this more portable variant: `LC_ALL=C tr -dc
'[:graph:]' </dev/urandom | head -c 32`
# Additional Changes
None
# Additional Context
Found by @fcoppede while testing #9496. The new command works for him.
# Which Problems Are Solved
This pr includes improved texts to make the usage of Actions V2 more
easy.
Since the removal of the Actions V2 Feature Flag we removed the code
that checks if it's enabled in the settings sidenav.
# How the Problems Are Solved
Added new texts to translations. Removed sidenav logic that checks for
Actions V2 Feature Flag
# Additional Context
- Part of #7248
- Part of #9688
---------
Co-authored-by: Max Peintner <peintnerm@gmail.com>
Co-authored-by: Max Peintner <max@caos.ch>
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
- Updates to only capture 10% of events with posthog
# How the Problems Are Solved
- Uses a feature flag rolled out to 10% of users to enable the capture
# Additional Changes
N/A
# Additional Context
N/A
# Which Problems Are Solved
If I start a fresh instance and do not overwrite `SystemAPIUsers` I get
an error during startup `error="decoding failed due to the following
error(s):\n\n'SystemAPIUsers[0][path]' expected a map, got
'string'\n'SystemAPIUsers[0][memberships]' expected a map, got 'slice'"`
# How the Problems Are Solved
the configuration is commented so that the example is still there
# Additional Changes
-
# Additional Context
was added in https://github.com/zitadel/zitadel/pull/9757
# Which Problems Are Solved
This PR resolves the issue #9648
# How the Problems Are Solved
Resolves a typo in the documentation
# Additional Context
- Closes #9648
- Discussion #9648
# Which Problems Are Solved
Actions v2 is not a feature flag anymore, include functionality on
executions is not used and json tags of proto messages are handled
incorrectly.
# How the Problems Are Solved
- Remove actions from the feature flags on system and instance level
- Remove include type on executions, only in the API, later maybe in the
handling logic as well
- Use protojson in request and response handling of actions v2
# Additional Changes
- Correct integration tests for request and response handling
- Use json.RawMessage for events, so that the event payload is not
base64 encoded
- Added separate context for async webhook calls, that executions are
not cancelled when called async
# Additional Context
Related to #9759Closes#9710
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
A customer reached out that after an upgrade, actions would always fail
with the error "host is denied" when calling an external API.
This is due to a security fix
(https://github.com/zitadel/zitadel/security/advisories/GHSA-6cf5-w9h3-4rqv),
where a DNS lookup was added to check whether the host name resolves to
a denied IP or subnet.
If the lookup fails due to the internal DNS setup, the action fails as
well. Additionally, the lookup was also performed when the deny list was
empty.
# How the Problems Are Solved
- Prevent DNS lookup when deny list is empty
- Properly initiate deny list and prevent empty entries
# Additional Changes
- Log the reason for blocked address (domain, IP, subnet)
# Additional Context
- reported by a customer
- needs backport to 2.70.x, 2.71.x and 3.0.0 rc
doc: ADOPTERS.md ceex
# Which Problems Are Solved
Replace this example text with a concise list of problems that this PR
solves.
For example:
- If the property XY is not given, the system crashes with a nil pointer
exception.
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
For example:
- Validates if property XY is given and throws an error if not
# Additional Changes
Replace this example text with a concise list of additional changes that
this PR introduces, that are not directly solving the initial problem
but are related.
For example:
- The docs explicitly describe that the property XY is mandatory
- Adds missing translations for validations.
# Additional Context
Replace this example with links to related issues, discussions, discord
threads, or other sources with more context.
Use the Closing #issue syntax for issues that are resolved with this PR.
- Closes #xxx
- Discussion #xxx
- Follow-up for PR #xxx
- https://discord.com/channels/xxx/xxx
This PR ensures that the list of recent sessions has no duplicate
entries.
To ensure the sessions are unique, we create a map using the loginName
property.
---------
Co-authored-by: conblem <mail@conblem.me>
# Which Problems Are Solved
This PR allows one to edit the order of Actions V2 Targets in an
Execution. Editing of Targets was also added back again.
# How the Problems Are Solved
One of the changes is the addition of the CorrectlyTypedExecution which
restricts the Grpc types a bit more to make working with them easier.
Some fields may be optional in the Grpc Protobuf but in reality are
always set.
Typings were generally improved to make them more accurate and safer to
work with.
# Additional Changes
Removal of the Actions V2 Feature flag as it will be enabled by default
anyways.
# Additional Context
This pr used some advanced Angular Signals logic which is very
interesting for future PR's.
- Part of the tasks from #7248
---------
Co-authored-by: Max Peintner <peintnerm@gmail.com>
# Which Problems Are Solved
When running a long-running Zitadel Setup, Kubernetes might decide to
move a pod to a new node automatically. Currently, this puts any
migrations into a broken state that an operator needs to manually run
the "cleanup" command on - assuming they catch the error.
The only super long running commands are typically projection pre-fill
operations, which depending on the size of the event table for that
projection, can take many hours - plenty of time for Kubernetes to make
unexpected decisions, especially in a busy cluster.
# How the Problems Are Solved
This change listens on `os.Interrupt` and `syscall.SIGTERM`, cancels the
current Setup context, and runs the `Cleanup` command. The logs then
look something like this:
```shell
...
INFO[0000] verify migration caller="/Users/zach/src/zitadel/internal/migration/migration.go:43" name=repeatable_delete_stale_org_fields
INFO[0000] starting migration caller="/Users/zach/src/zitadel/internal/migration/migration.go:66" name=repeatable_delete_stale_org_fields
INFO[0000] execute delete query caller="/Users/zach/src/zitadel/cmd/setup/39.go:37" instance_id=281297936179003398 migration=repeatable_delete_stale_org_fields progress=1/1
INFO[0000] verify migration caller="/Users/zach/src/zitadel/internal/migration/migration.go:43" name=repeatable_fill_fields_for_instance_domains
INFO[0000] starting migration caller="/Users/zach/src/zitadel/internal/migration/migration.go:66" name=repeatable_fill_fields_for_instance_domains
----- SIGTERM signal issued -----
INFO[0000] received interrupt signal, shutting down: interrupt caller="/Users/zach/src/zitadel/cmd/setup/setup.go:121"
INFO[0000] query failed caller="/Users/zach/src/zitadel/internal/eventstore/repository/sql/query.go:135" error="timeout: context already done: context canceled"
DEBU[0000] filter eventstore failed caller="/Users/zach/src/zitadel/internal/eventstore/handler/v2/field_handler.go:155" error="ID=SQL-KyeAx Message=unable to filter events Parent=(timeout: context already done: context canceled)" projection=instance_domain_fields
DEBU[0000] unable to rollback tx caller="/Users/zach/src/zitadel/internal/eventstore/handler/v2/field_handler.go:110" error="sql: transaction has already been committed or rolled back" projection=instance_domain_fields
INFO[0000] process events failed caller="/Users/zach/src/zitadel/internal/eventstore/handler/v2/field_handler.go:72" error="ID=SQL-KyeAx Message=unable to filter events Parent=(timeout: context already done: context canceled)" projection=instance_domain_fields
DEBU[0000] trigger iteration caller="/Users/zach/src/zitadel/internal/eventstore/handler/v2/field_handler.go:73" iteration=0 projection=instance_domain_fields
ERRO[0000] migration failed caller="/Users/zach/src/zitadel/internal/migration/migration.go:68" error="ID=SQL-KyeAx Message=unable to filter events Parent=(timeout: context already done: context canceled)" name=repeatable_fill_fields_for_instance_domains
ERRO[0000] migration finish failed caller="/Users/zach/src/zitadel/internal/migration/migration.go:71" error="context canceled" name=repeatable_fill_fields_for_instance_domains
----- Cleanup before exiting -----
INFO[0000] cleanup started caller="/Users/zach/src/zitadel/cmd/setup/cleanup.go:30"
INFO[0000] cleanup migration caller="/Users/zach/src/zitadel/cmd/setup/cleanup.go:47" name=repeatable_fill_fields_for_instance_domains
```
# Additional Changes
* `mustExecuteMigration` -> `executeMigration`: **must**Execute logged a
Fatal error previously which calls os.Exit so no cleanup was possible.
Instead, this PR returns an error and assigns it to a shared error in
the Setup closure that defer can check.
* `initProjections` now returns an error instead of exiting
# Additional Context
This behavior might be unwelcome or at least unexpected in some cases.
Putting it behind a feature flag or config setting is likely a good
followup.
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
