mirror of
https://github.com/zitadel/zitadel.git
synced 2025-04-15 23:41:30 +00:00
fa5e6d1914
# Which Problems Are Solved Among others #7822 changed the event type of the `user.token.added` to `user.token.v2.added`. To make customers aware of this in case they use it for calculating DAU / MAU, resp. for an audit trail, we want to raise awareness. # How the Problems Are Solved Technical advisory to state the change. # Additional Changes None. # Additional Context Relates to #7822 Co-authored-by: Fabi <fabienne@zitadel.com>
205 lines
8.6 KiB
Plaintext
205 lines
8.6 KiB
Plaintext
---
|
|
title: ZITADEL Technical Advisories
|
|
sidebar_label: Technical Advisories
|
|
---
|
|
|
|
Technical advisories are notices that report major issues with ZITADEL Self-Hosted or the ZITADEL Cloud platform that could potentially impact security or stability in production environments.
|
|
These advisories may include details about the nature of the issue, its potential impact, and recommended mitigation actions.
|
|
|
|
Users are strongly encouraged to evaluate these advisories and consider the recommended mitigation actions independently from their version upgrade schedule.
|
|
We understand that these advisories may include breaking changes, and we aim to provide clear guidance on how to address these changes.
|
|
|
|
<table>
|
|
<tr>
|
|
<th>Advisory</th>
|
|
<th>Name</th>
|
|
<th>Type</th>
|
|
<th>Summary</th>
|
|
<th>Affected versions</th>
|
|
<th>Date</th>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10000">A-10000</a>
|
|
</td>
|
|
<td>Reusing user session</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
The default behavior for users logging in is to be directed to the Select
|
|
Account Page on the Login. With the upcoming changes, users will be
|
|
automatically authenticated when logging into a second application, as
|
|
long as they only have one active session. No action is required on your
|
|
part if this is the intended behavior.
|
|
</td>
|
|
<td>2.32.0</td>
|
|
<td>Calendar week 32</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10001">A-10001</a>
|
|
</td>
|
|
<td>Login Policy - Allow Register</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
When disabling the option, users are currently not able to register
|
|
locally and also not through an external IDP. With the upcoming change,
|
|
the setting will only prevent local registration. Restriction to Identity
|
|
Providers can be managed through the corresponding IDP Template. No action
|
|
is required on your side if this is the intended behavior or if you
|
|
already disabled registration on your IDP.
|
|
</td>
|
|
<td>2.35.0</td>
|
|
<td>Calendar week 34</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10002">A-10002</a>
|
|
</td>
|
|
<td>Console - Branding</td>
|
|
<td>Breaking Design Change</td>
|
|
<td>
|
|
Since Angular Material v15 many of the UI components have been refactored
|
|
to be based on the official Material Design Components for Web (MDC).
|
|
These refactored components do not support dynamic styling, so in order to
|
|
keep the library up-to-date, the console UI will loose its dynamic theming
|
|
capability. If you need users to have your branding settings (background-,
|
|
button-, link and text coloring) you should implement your own user
|
|
facing UI yourself and not use ZITADELs console UI.
|
|
ZITADEL hosted Login-UI is not affected by this change.
|
|
</td>
|
|
<td>2.40.0</td>
|
|
<td>Calendar week 44</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10003">A-10003</a>
|
|
</td>
|
|
<td>Login-UI - Default Context</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
When users are redirected to the ZITADEL Login-UI without any organizational context,
|
|
they're currently presented a login screen, based on the default settings,
|
|
e.g. available IDPs and possible login mechanisms. If the user will then register themselves,
|
|
by the registration form or through an IDP, the user will always be created on the default organization.
|
|
With the introduced change, the settings will no longer be loaded from the instance, but rather the default organization directly.
|
|
</td>
|
|
<td>2.38.0</td>
|
|
<td>Calendar week 41</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10004">A-10004</a>
|
|
</td>
|
|
<td>Sequence uniquenes</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
Due to storage optimisations ZITADEL changes the behavior of sequences.
|
|
This change improves command (create, update, delete) performance of ZITADEL.
|
|
Sequences are no longer unique inside an instance.
|
|
From now on sequences are upcounting per aggregate id.
|
|
For example sequences of newly created users begin at 1.
|
|
Existing sequences remain untouched.
|
|
</td>
|
|
<td>2.39.0</td>
|
|
<td>2023-10-14</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10005">A-10005</a>
|
|
</td>
|
|
<td>Expected downtime during upgrade</td>
|
|
<td>Expected downtime during upgrade</td>
|
|
<td>
|
|
Migrating to versions >= 2.39 from < 2.39 will cause down time during setup starts and the new version is started.
|
|
This is caused by storage optimisations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
|
|
All existing events are migrated during the execution of the `zitadel setup` command.
|
|
New events will be inserted into the new `eventstore.events2` table. The old table `evetstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
|
|
</td>
|
|
<td>2.39.0</td>
|
|
<td>Calendar week 41/42 2023</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10006">A-10006</a>
|
|
</td>
|
|
<td>Additional grant to cockroach database user</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
Versions >= 2.39.0 require the cockroach database user of ZITADEL to be granted to the `VIEWACTIVITY` grant. This can either be reached by grant the role manually or execute the `zitadel init` command.
|
|
</td>
|
|
<td>2.39.0</td>
|
|
<td>Calendar week 41/42 2023</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10007">A-10007</a>
|
|
</td>
|
|
<td>Additional grant to cockroach database user</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
Upcoming Versions require the SYSTEM_OWNER role to be available in the permission role mappings. Self-hosting ZITADEL users who define custom permission role mappings need to make sure their system users don't lose access to the system API.
|
|
</td>
|
|
<td>Upcoming</td>
|
|
<td>Upcoming</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10008">A-10008</a>
|
|
</td>
|
|
<td>New flag to prefill projections during setup instead of after start</td>
|
|
<td>Feature description</td>
|
|
<td>
|
|
New flag `--init-projections` introduced to `zitadel setup` commands (`setup`, `start-from-setup`, `start-from-init`)
|
|
</td>
|
|
<td>2.44.0, 2.43.6, 2.42.12</td>
|
|
<td>2024-01-25</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10009">A-10009</a>
|
|
</td>
|
|
<td>Ensure lock distribution for `FOR UPDATE`-statements on Cockroachdb</td>
|
|
<td>Feature description</td>
|
|
<td>
|
|
Fixes rare cases where updating projections was blocked by a `WRITE_TOO_OLD`-error when using cockroachdb.
|
|
</td>
|
|
<td>2.53.0</td>
|
|
<td>2024-05-28</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<a href="./advisory/a10010">A-10010</a>
|
|
</td>
|
|
<td>Event type of token added event changed</td>
|
|
<td>Breaking Behavior Change</td>
|
|
<td>
|
|
Version 2.53.0 improves the token issuance. Due to this there are changes to the event types created on token creation.
|
|
</td>
|
|
<td>2.53.0</td>
|
|
<td>2024-05-28</td>
|
|
</tr>
|
|
</table>
|
|
|
|
## Subscribe to our Mailing List
|
|
|
|
If you want to stay up to date on our technical advisories, we recommend subscribing to the mailing list.
|
|
Go to <a href="https://zitadel.com/technical-advisory">the subscription form</a> and add your email address.
|
|
|
|
As ZITADEL Cloud customer, you can also login to the <a href="https://zitadel.cloud">ZITADEL Customer Portal</a> and enable the Technical Advisory <a href="https://zitadel.cloud/admin/notifications">Notifications</a> in your settings.
|
|
|
|
## Categories
|
|
|
|
### Breaking Behavior Change
|
|
|
|
A breaking behavior change refers to a modification or update that changes the behavior of ZITADEL.
|
|
This change does not necessarily affect the APIs or any functions you are calling, so it may not require an update to your code.
|
|
However, if you rely on specific results or behaviors, they may no longer be guaranteed after the change is implemented.
|
|
Therefore, it is important to be aware of breaking behavior changes and their potential impact on your use of ZITADEL, and to take appropriate action if needed to ensure continued functionality.
|
|
|
|
### Expected downtime during upgrade
|
|
|
|
Expected downtime during upgrade means that ZITADEL might become unavailable during an upgrade.
|
|
ZITADEL is built for [zero downtime upgrades](/docs/concepts/architecture/solution#zero-downtime-updates) at upgrades can be executed without downtime by just updating to a more recent version.
|
|
When deploying certain changes a zero downtime upgrade might not be possible, for example to guarantee data integrity.
|
|
In such cases we will issue a technical advisory to make you aware of this unexpected behavior.
|