# Which Problems Are Solved
Previously, the login lifetime input fields allowed negative values and,
in some cases, zero values, which were not valid according to the
business rules.
# How the Problems Are Solved
The issue was resolved by adding min and step properties to the relevant
HTML input fields. This ensures that only valid values are entered,
adhering to the specific requirements for each field.
Co-authored-by: Max Peintner <max@caos.ch>
- **docs: s/Secondfactor/Second factor/**
- **docs: s/IDP/IdP/**
- **docs: s/Hardwaretokens/Hardware tokens/**
- **docs: standardize multi-factor vs multi factor vs multifactor**
# Which Problems Are Solved
- English strings are improved
# How the Problems Are Solved
- With better strings
---------
Co-authored-by: Fabi <fabienne@zitadel.com>
- Fully translated all UI elements, documentation, and error messages
- Added Hungarian as a new supported language option
- Updated language selection menus and related configuration files
- Ensured consistency across all translated content
# Which Problems Are Solved
- ZITADEL was not accessible for Hungarian-speaking users due to lack of
language support
- Hungarian users had to rely on English or other languages to use the
platform
- Potential user base was limited due to language barrier
# How the Problems Are Solved
- Translated all user interface elements, including console and login
interfaces
- Translated all documentation files to Hungarian
- Added Hungarian translations for all error messages and notifications
- Implemented Hungarian as a selectable language option in the system
# Additional Changes
- Updated language selection menus to include Hungarian
- Modified configuration files to support Hungarian language
- Ensured consistent terminology and style across all translated content
- Added Hungarian language option to relevant dropdown menus and
settings
# Additional Context
- Relates to the ongoing internationalization efforts of ZITADEL
- Enhances accessibility for Hungarian-speaking developers and users
- Expands ZITADEL's potential user base in Hungary and
Hungarian-speaking regions
---------
Co-authored-by: Max Peintner <max@caos.ch>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
Adding a SAML IDPs with an empty metadata XML and URL leads to failed
projection events. The main IDP template projection succeeds, but the
subtable projection for SAML template fails, because the metadata field
is not nullable in that table. The SAML IDP shows up in list queries,
because the list method only queries the main template projection.
However, getting a SAML IDP created without metadata by ID misses the
SAML specific IDP data.
# How the Problems Are Solved
- The command for adding a SAML IDP properly ensures that non-empty
metadata is either given by XML or resolved by URL.
- The console doesn't send requests with empty metadata anymore. This
works by explicitly setting a single oneof option for either XML or URL
and emptying the other one.
# Additional Context
Closes#8443
# Which Problems Are Solved
NPM dependencies are outdated.
# How the Problems Are Solved
```bash
cd console
yarn upgrade
yarn add typescript@5.1
```
```bash
cd load-test
npm update
```
# Which Problems Are Solved
Twilio supports a robust, multi-channel verification service that
notably supports multi-region SMS sender numbers required for our use
case. Currently, Zitadel does much of the work of the Twilio Verify (eg.
localization, code generation, messaging) but doesn't support the pool
of sender numbers that Twilio Verify does.
# How the Problems Are Solved
To support this API, we need to be able to store the Twilio Service ID
and send that in a verification request where appropriate: phone number
verification and SMS 2FA code paths.
This PR does the following:
- Adds the ability to use Twilio Verify of standard messaging through
Twilio
- Adds support for international numbers and more reliable verification
messages sent from multiple numbers
- Adds a new Twilio configuration option to support Twilio Verify in the
admin console
- Sends verification SMS messages through Twilio Verify
- Implements Twilio Verification Checks for codes generated through the
same
# Additional Changes
# Additional Context
- base was implemented by @zhirschtritt in
https://github.com/zitadel/zitadel/pull/8268❤️
- closes https://github.com/zitadel/zitadel/issues/8581
---------
Co-authored-by: Zachary Hirschtritt <zachary.hirschtritt@klaviyo.com>
Co-authored-by: Joey Biscoglia <joey.biscoglia@klaviyo.com>
# Which Problems Are Solved
ZITADEL's user grants deactivation mechanism did not work correctly.
Deactivated user grants were still provided in token, which could lead
to unauthorized access to applications and resources.
Additionally, the management and auth API always returned the state as
active or did not provide any information about the state.
# How the Problems Are Solved
- Correctly check the user grant state on active for tokens and user
information (userinfo, introspection, saml attributes)
- Map state in API and display in Console
There were some problems after changing from SMTP providers to email
providers (https://github.com/zitadel/zitadel/pull/8545):
- panic (nil pointer) on SMTP provider retrieval for HTTP configs
- old SMTP configuration created before the multi SMTP configurations
(without id)
- were not projected / listed
- could not be always be activated
- Console treated HTTP configs as SMTP
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
The exact timestamp including the seconds and milliseconds in the user
audit log is not shown, either in the direct log or in the tooltip that
appears when hovering over the item.
# How the Problems Are Solved
The exact timestamp is added to the tooltip that appears when hovering
over the item.
# Additional Changes
None
# Additional Context
- Closes#8371
---------
Co-authored-by: Max Peintner <max@caos.ch>
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
As an administrator I want to be able to invite users to my application
with the API V2, some user data I will already prefil, the user should
add the authentication method themself (password, passkey, sso).
# How the Problems Are Solved
- A user can now be created with a email explicitly set to false.
- If a user has no verified email and no authentication method, an
`InviteCode` can be created through the User V2 API.
- the code can be returned or sent through email
- additionally `URLTemplate` and an `ApplicatioName` can provided for
the email
- The code can be resent and verified through the User V2 API
- The V1 login allows users to verify and resend the code and set a
password (analog user initialization)
- The message text for the user invitation can be customized
# Additional Changes
- `verifyUserPasskeyCode` directly uses `crypto.VerifyCode` (instead of
`verifyEncryptedCode`)
- `verifyEncryptedCode` is removed (unnecessarily queried for the code
generator)
# Additional Context
- closes#8310
- TODO: login V2 will have to implement invite flow:
https://github.com/zitadel/typescript/issues/166
# Which Problems Are Solved
The end_session_endpoint currently always requires the userAgent cookie
to be able to terminate session created through the hosted login UI.
Only tokens issued through the Login V2 can be used to directly
terminate a specific session and without the need of a cookie.
This PR adds the possibility to terminate a single V1 session or all V1
sessions belonging to the same user agent without the need of the
userAgent cookie by providing an id_token as `id_token_hint` which
contains the id of a V1 session as `sid`.
# How the Problems Are Solved
- #8525 added the `sid` claim for id_tokens issued through the login UI
- The `sid` can now be checked for the `V1_` prefix and queries for
either the userAgentID and depending on the
`OIDCSingleV1SessionTermination` flag all userIDs of active session from
the same user agent id
- The `OIDCSingleV1SessionTermination` flag is added with default value
false to keep the existing behavior of terminating all sessions even in
case of providing an id_token_hint
# Additional Changes
- pass `context.Context` into session view functions for querying the
database with that context
# Additional Context
- relates to #8499
- closes#8501
# Which Problems Are Solved
After the creation of an LDAP IDP on instance or org level, the button
changes to 'Save' and with each click a new IDP will be created.
# How the Problems Are Solved
Similar to what was done in #7572, we check if the IDP was just created
# Additional Changes
None
# Additional Context
- Closes#8444
- Follow-up for PR #7572
Co-authored-by: Max Peintner <max@caos.ch>
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
There were UX issue with the autolinking prompt page and users were not
able to link their account or would not understand what to do. Since the
trust to the IdP is already bound by the configuration, the user can
directly be linked without any user input.
# How the Problems Are Solved
- remove the prompt page and directly link the user if possible
- remove corresponding customization texts from the API and Console
# Additional Changes
None
# Additional Context
- relates to https://github.com/zitadel/zitadel/issues/7977
- discussed with customers
- created as a `fix` to be able to backport
---------
Co-authored-by: Max Peintner <max@caos.ch>
# Which Problems Are Solved
The navigation in the console default settings is flaky. Sometimes it
arbitrarily jumps to the organizations page.
# How the Problems Are Solved
The lifecycle hooks were extended to react differently to changes that
come from 'outside' and from the component itself.
# Additional Changes
The e2e tests are supposed to run against Firefox and Chrome. However
they are run twice against Electon. Fixing this revealed the console
navigation flakiness that was less visible on Electron.
The following issues are also fixed with this PR to reduce flakiness in
e2e tests.
- The custom command in the pipeline is removed from the e2e action
step, so the browser argument is respected.
- The npm packages of the e2e tests are updated to their latest version.
- Notification tests run against a clean state now so they don't depend
on each other anymore. This resolved some flakiness and improved
debuggability of the tests.
- E2E page load timeout is increased, reducing flakiness.
- E2E tests wait on some elements to be enabled before they interact
with them, reducing flakiness.
# Additional Context
- Closes#8404
- Follow-up: https://github.com/zitadel/zitadel/issues/8471
The e2e tests ran three times in a row successfully in the pipeline
against both browsers.
---------
Co-authored-by: Max Peintner <max@caos.ch>
Co-authored-by: Livio Spring <livio.a@gmail.com>
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
The filter option was not displayed on the user list page for users who
only have `user.read` permission, e.g. an IAM_OWNER_VIEWER or
ORG_OWNER_VIEWER
# How the Problems Are Solved
- Filter is correctly displayed.
# Additional Changes
None.
# Additional Context
- noticed by a customer
- needs backports
# Which Problems Are Solved
As of now, **automatic creation** and **automatic linking options** were
only considered if the corresponding **allowed option** (account
creation / linking allowed) was enabled.
With this PR, this is no longer needed and allows administrators to
address cases, where only an **automatic creation** is allowed, but
users themselves should not be allowed to **manually** create new
accounts using an identity provider or edit the information during the
process.
Also, allowing users to only link to the proposed existing account is
now possible with an enabled **automatic linking option**, while
disabling **account linking allowed**.
# How the Problems Are Solved
- Check for **automatic** options without the corresponding **allowed**
option.
- added technical advisory to notify about the possible behavior change
# Additional Changes
- display the error message on the IdP linking step in the login UI (in
case there is one)
- display an error in case no option is possible
- exchanged deprecated `eventstoreExpect` with `expectEventstore` in
touched test files
# Additional Context
closes https://github.com/zitadel/zitadel/issues/7393
---------
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
ZITADEL uses HTML for emails and renders certain information such as
usernames dynamically. That information can be entered by users or
administrators. Due to a missing output sanitization, these emails could
include malicious code.
This may potentially lead to a threat where an attacker, without
privileges, could send out altered notifications that are part of the
registration processes. An attacker could create a malicious link, where
the injected code would be rendered as part of the email.
During investigation of this issue a related issue was found and
mitigated, where on the user's detail page the username was not
sanitized and would also render HTML, giving an attacker the same
vulnerability.
While it was possible to inject HTML including javascript, the execution
of such scripts would be prevented by most email clients and the Content
Security Policy in Console UI.
# How the Problems Are Solved
- All arguments used for email are sanitized (`html.EscapeString`)
- The email text no longer `html.UnescapeString` (HTML in custom text is
still possible)
- Console no longer uses `[innerHtml]` to render the username
# Additional Changes
None
# Additional Context
- raised via email
---------
Co-authored-by: peintnermax <max@caos.ch>
This fixes a problem where the org settings were hidden.
The console reads the context from either a query param or the local
storage. When one context was found, it executed a single request with
orgId filter. This let to a single org and then to a hidden org setting,
as we hide org settings for instances with a single result.
# Which Problems Are Solved
I fixed more spelling and grammar misstakes in the German language
files.
# Additional Context
- Follow-up for PR #8240
Co-authored-by: Fabi <fabienne@zitadel.com>
This reverts commit e126ccc9aa.
# Which Problems Are Solved
#8295 introduced the possibility to handle idps on a single callback,
but broke current setups.
# How the Problems Are Solved
- Revert the change until a proper solution is found. Revert is needed
as docs were also changed.
# Additional Changes
None.
# Additional Context
- relates to #8295
# Which Problems Are Solved
The default vue logout URL doesn't work with the @zitadel/vue defaults
# How the Problems Are Solved
A trailing slash is added to the default logout URL.
# Additional Context
Found while testing https://github.com/zitadel/zitadel-vue/pull/53
This reduces the initial payload of the `listMyProjectOrgs` to get the
active org by setting the limit of the initial orgs to 100.
Partial of #8272
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Both the login UI and the IdP intent flow have their own IdP callback
endpoints.
This makes configuration hard to impossible (e.g. Github only allows one
endpoint) for customers.
# How the Problems Are Solved
- The login UI prefixes the `state` parameter when creating an auth /
SAML request.
- All requests now use the `/idp/callback` or the corresponding
variation (e.g. SAML)
- On callback, the state, resp. its prefix is checked. In case of the
login UI prefix, the request will be forwarded to the existing login UI
handler without the prefix state.
Existing setups will therefore not be affected and also requests started
before this release can be handled without any impact.
- Console only lists the "new" endpoint(s). Any
`/login/externalidp/callback` is removed.
# Additional Changes
- Cleaned up some images from the IdP documentation.
- fix the error handling in `handleExternalNotFoundOptionCheck`
# Additional Context
- closes#8236
# Which Problems Are Solved
In the console a wrong translation is shown for the password re auth
time, it is shown that it is the time after which users have to renew
their password, but it is the time, after which they have to
authenticate again with their password
# How the Problems Are Solved
Translations are changed in all languages
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
- A note should be added to the ZITADEL management console showing that
the name and function in the javascript have to be the same
# How the Problems Are Solved
- A new cnsl-info-section is added to the create/update action dialog
# Additional Context
Here's a screenshot showing the note:
- Closes#7874
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
- The UI layout is broken in Upload your Profile Picture
# How the Problems Are Solved
- MatDialog module was missing
# Additional Context
Here's a screenshot showing the fix
- Closes#8284
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
There are some undocumented parameters that can be used. A good example
is on the "Verify SMS OTP" page.
# How the Problems Are Solved
Expiry and Domain chips are added to the Verify SMS OTP and Verify Email
OTP message text configs in the console.
# Additional Context
- Closes#7134
---------
Co-authored-by: Fabi <fabienne@zitadel.com>
Co-authored-by: Elio Bischof <elio@zitadel.com>
# Which Problems Are Solved
- In Firefox there's an issue with mat-calendar. The header for days of
the week has a height that fills the entire space making dates to
overlap. This happens for both Personal Access Tokens and Keys dialogs.
# How the Problems Are Solved
- In FF there seems to be a problem with the following style in
tables.scss. If I remove that style in FF everything works fine:
```
th,
td {
padding: 0 0.5rem !important;
}
```
Although I tried to override it or remove !important I didn't like the
idea of having side effects all around the tables. As the issue was the
height for the header I tried to add a fixed height for the th elements
using a new specific selector in the tables.scss file. That way FF seems
to calculate the right height for the header and dates are shown
correctly.
If @peintnermax agrees maybe an issue can be opened for a future work to
remove as many !important properties as possible
Here's a screenshot for FF
And another one for Chrome
Maybe it's not too elegant but as it seems a bug on Firefox I think it's
a contained solution.
# Additional Context
- Closes#7877
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
In the configuration of external idps we show SAML SP as provider which
is confusing, as it is a SAML IdP which is configured
# How the Problems Are Solved
Rename SAML SP to SAML IdP
# Which Problems Are Solved
- As @stebenz reported, if we apply some user filters and show user's
details clicking on the table's entry, if we go back again (maybe the
action has to be repeated many times to see the error in action) the
filter seems to be ignored and the table shows all users.
# How the Problems Are Solved
- There's an issue with getting data for the user's table. On ngOnInit
the data is retrieved but also the data is retrieved again when the
filter is applied after going back from the user details view. Due to
asynchronous calls there are some times when the getData, called from
ngOnInit, finishes after the call from applySearchQuery, which applies
the filter, and that's why the data in the tables shows unfiltered data.
In the screenshot we see that we get two results from ngOnInit call
after getting the filtered data (1 result) overwriting the filtered
results.
- I've added a check on ngOnInit that verifies if we have already a
filter (query params) which means that we don't need to getData there as
the filter and getData is going to be applied when applySearchQuery is
called. Here's a video checking that the issue no longer happens:
https://github.com/zitadel/zitadel/assets/30386061/9907d94f-1326-4975-8664-2a0ff51f4568
# Additional Changes
- I think it's better to change the button text to apply the filter from
Finish to Apply
# Additional Context
- Closes#8049
# Which Problems Are Solved
- The console shows the Instance Settings title and a description.
Instance settings should be replaced with Default settings
# How the Problems Are Solved
- The DESCRIPTIONS.SETTINGS.INSTANCE.TITLE and
DESCRIPTIONS.SETTINGS.INSTANCE.DESCRIPTION have been replaced with
Default Settings and in the corresponding translation files.
Here's a screenshot:
# Additional Changes
- The docs have been updated to replace remaining texts mentioning
Instance Settings with Default Settings
- Two unused texts have been deleted from the translation files
- VSCode with Prettier have applied some markdown changes
# Additional Context
- Closes#7632
---------
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
- Zitadel doesn't have a way to test SMTP settings either before
creating a new provider or once the SMTP provider has been created.
- Zitadel SMTP messages can be more informative for usual errors
# How the Problems Are Solved
- A new step is added to the new/update SMTP provider wizard that allows
us to test a configuration. The result is shown in a text area.
- From the table of SMTP providers you can test your settings too.
- The email address to send the email is by default the email address
for the logged in user as suggested.
- Some of the SMTP error messages have been changed to give more
information about the possible situation. For example: could not contact
with the SMTP server, check the port, firewall issues... instead of
could not dial
Here's a video showing this new option in action:
https://github.com/zitadel/zitadel/assets/30386061/50128ba1-c9fa-4481-8eec-e79a3ca69bda
# 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
- Closes#4504
# Which Problems Are Solved
Some organizations / customers have the requirement, that there users
regularly need to change their password.
ZITADEL already had the possibility to manage a `password age policy` (
thought the API) with the maximum amount of days a password should be
valid, resp. days after with the user should be warned of the upcoming
expiration.
The policy could not be managed though the Console UI and was not
checked in the Login UI.
# How the Problems Are Solved
- The policy can be managed in the Console UI's settings sections on an
instance and organization level.
- During an authentication in the Login UI, if a policy is set with an
expiry (>0) and the user's last password change exceeds the amount of
days set, the user will be prompted to change their password.
- The prompt message of the Login UI can be customized in the Custom
Login Texts though the Console and API on the instance and each
organization.
- The information when the user last changed their password is returned
in the Auth, Management and User V2 API.
- The policy can be retrieved in the settings service as `password
expiry settings`.
# Additional Changes
None.
# Additional Context
- closes#8081
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
@mffap reported in issue #8084 that there was an oferflow error when the
PAT token was displayed which made copying it almost impossible
# How the Problems Are Solved
It seems there was an issue with the token text not wrapping well as the
token is a long word. Sometimes the token was displayed well but it was
only because the token contains hyphens that made the text go into a new
line but if no hyphen was there there was an overflow issue.
I've used a new class for the token to be displayed and used the css
properties explained in
[mdn](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_text/Wrapping_breaking_text)
```
overflow-wrap: break-word;
word-break: break-all;
```
Here's a video showing the fix in action:
https://github.com/zitadel/zitadel/assets/30386061/096de18d-4424-46b8-a287-cce6539c2053
# Additional Context
- Closes#8084
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
fix {{.Lastname}} chip on test message settings
# How the Problems Are Solved
{{.LastName}} should appear in the text field
# Additional Changes
No additional changes
# Additional Context
- Closes#8076
Co-authored-by: Daniel Moisa <dani93moisa@gmail.com>
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
- For devices with screen width lower than 600 px the "Default Settings"
button is not shown unless you put the device in landscape mode
# How the Problems Are Solved
- I've modified the styles so this button is always displayed (I've
tested up to 350 px devices) but for devices width lower than 375px the
font size will be x-small. Thanks to the cog icon and the smaller text
if seems to work fine
Here are two screenshots for a 400 px device:
and a 360 px device:
# Additional Context
- Closes#7574
# Which Problems Are Solved
- Styles from the material design component dialog are not being applied
(no padding, wrong theme colors for titles...)
# How the Problems Are Solved
- The MatDialogModule has been added to secret-generator.module.ts so
the styles are applied
Here's a video showing the fix in action:
https://github.com/doncicuto/zitadel/assets/30386061/32567e58-b7d6-48da-8369-b48e23828a5c
# Additional Context
- Closes#8085
Co-authored-by: Fabi <fabienne@zitadel.com>
