# Which Problems Are Solved
- The eventstore did not support intentionally overwriting the resource
owner when creating events for aggregates that may be reused across
owners.
- Resource owner handling was implicit and could not be controlled per
command/event type.
- We needed a safe way to distinguish between:
- keeping the existing aggregate owner, and
- explicitly setting a new owner for specific create-like events.
# How the Problems Are Solved
- Introduced a new eventstore command type with an explicit
enforce_owner flag.
- Updated eventstore.commands_to_events and eventstore.push so owner
assignment is now explicit:
- if enforce_owner is true, the command owner is written
- if enforce_owner is false, the existing aggregate owner is retained
when present
- Added EnforceResourceOwnerCommand and wiring so command types can opt
in to enforced owner behavior.
- Wired the new behavior through the v3 eventstore push path, including
compatibility fallback for older command type mapping.
- Added migration/setup changes to register and use the new command type
and SQL functions.
- Added and updated tests for owner overwrite and aggregate ID reuse
scenarios.
# Additional Changes
- Added small migration/setup robustness improvements related to
eventstore setup ordering and helper reuse.
- Added focused test coverage for enforced owner behavior and
sequencing.
- Events that currently allow owner changes (implement
EnforceResourceOwner) are:
- AddedEvent (action)
- GroupAddedEvent
- StartedEvent (idp intent)
- ProjectAddedEvent
- HumanAddedEvent
- HumanRegisteredEvent
- MachineAddedEvent
- CreatedEvent (schema user)
# Additional Context
- Follow-up for eventstore owner-handling correctness in create flows
and aggregate ID reuse cases.
- No additional issue link was attached for this change.
---------
Co-authored-by: abhishek kumar gupta <[email protected]>
When an expired invite code was used for webauthn (passkeys), the change date got updated by the failed event. This change date was used to test for expiry, meaning failed events would reset the expiry timeout.
This fix adds a Code Creation Date to the writemodel which gets set by the first event. This can be the added or requested event.
Other changes:
- Expiry renamed to CodeExpiry so it's consistent with similar write models using secret codes.
- humanVerifyPasswordlessInitCode takes an algorithm instead of the complete generator, so the method can be unit tested easier
- Added tests that reproduced the original issue
This fix provides a possibility to pass a domain on the session, which
will be used (as rpID) to create a passkey / u2f assertion and
attestation. This is useful in cases where the login UI is served under
a different domain / origin than the ZITADEL API.
* command/crypto: DRY the code
- reuse the the algorithm switch to create a secret generator
- add a verifyCryptoCode function
* command: crypto code tests
* migrate webauthn package
* finish integration tests with webauthn mock client
* begin pw less registration
* create pwless one time codes
* send pwless link
* separate send and add passwordless link
* separate send and add passwordless link events
* custom message text for passwordless registration
* begin custom login texts for passwordless
* i18n
* i18n message
* i18n message
* custom message text
* custom login text
* org design and texts
* create link in human import process
* fix import human tests
* begin passwordless init required step
* passwordless init
* passwordless init
* do not return link in mgmt api
* prompt
* passwordless init only (no additional prompt)
* cleanup
* cleanup
* add passwordless prompt to custom login text
* increase init code complexity
* fix grpc
* cleanup
* fix and add some cases for nextStep tests
* fix tests
* Update internal/notification/static/i18n/en.yaml
* Update internal/notification/static/i18n/de.yaml
* Update proto/zitadel/management.proto
* Update internal/ui/login/static/i18n/de.yaml
* Update internal/ui/login/static/i18n/de.yaml
* Update internal/ui/login/static/i18n/de.yaml
Co-authored-by: Fabi <[email protected]>
* fix: email change not possible if init state
* fix: email change not possible if init state
* passwordless
Co-authored-by: Livio Amstutz <[email protected]>
Tim MöhlmannandGitHub
Livio SpringandGitHub
