# Which Problems Are Solved
The docker-compose examples expose the database to the world.
# How the Problems Are Solved
Remove the `ports` config from the `db` service.
# Which Problems Are Solved
It is not clear that the phone number can be requested in a separat oidc
scope
# How the Problems Are Solved
Added the phone scope to the scope documentation
# 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
Certificates created for a SAML IdP (used for metadata and request
singing) did not have any validity set. While it's not required for
SAML, when trying to import the certificate into a (keychain) tool it
might fail.
# How the Problems Are Solved
The validity is set based on the `CertificateLifetime` set in the
runtime config.
## After the fix:
If an IdP was created with a certificate without validity, an admin can
regenerate the certificate:
- for instance wide IdPs:
https://zitadel.com/docs/apis/resources/admin/admin-service-regenerate-saml-provider-certificate#regenerate-saml-identity-provider-certificate
- for organization specific IdPs:
https://zitadel.com/docs/apis/resources/mgmt/management-service-regenerate-saml-provider-certificate#regenerate-saml-identity-provider-certificate
Due to the new certificate, the metadata will change and will need to be
updated at the external IdP.
# Additional Changes
Additionally the `CertificateSize` instead of the `Size` (used for keys)
is used for generating the certificate, resp. the underlying key pair.
# Additional Context
- noted by a customer
- needs backports
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
# Which Problems Are Solved
Improve the performance of the `admin/v1/import` API endpoint.
Specifaclly the import of large amount of project grants.
# How the Problems Are Solved
`AddProjectGrantWithID` and `AddProjectGrantMember` methods of
`Commands` used to get the current state of the Writemodel to check if
the current GrantID or the combination of GrantID & UserID wasn't
already used. However, the Added events already have protection against
duplication by the `UniqueConstaint` methods.
The queries become very slow when there is a great amount of project
grants. Because all the events are pushed to the aggregate ID of the
project, we had to obtain all related project events, including events
of grantIDs we do not care about. This O(n) duration for bached import
jobs adding many organization granted to a single project.
This change removes the unnecesary state query to improve performance.
# Additional Changes
- Add integration tests for import
# Additional Context
- reported internally
# Which Problems Are Solved
This fix adds tracing spans to all V1 API import related functions. This
is to troubleshoot import related performance issues reported to us.
# How the Problems Are Solved
Add a tracing span to `api/grpc/admin/import.go` and all related
functions that are called in the `command` package.
# Additional Changes
- none
# Additional Context
- Reported by internal communication
# 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
Describes how to develop ZITADEL using dev containers.
# Additional Changes
Sets default env variables for using postgres as database in the dev
container.
# Which Problems Are Solved
If there is no custom text given, the call ends in an internal error as
no events have to be pushed.
# How the Problems Are Solved
If no events have to be pushed, no trying to push an empty list of
events.
# Additional Changes
No additional changes.
# Additional Context
Closes#6954
# 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>
# Which Problems Are Solved
Zitadel never stored or returned the requested `response_mode` in oidc
Auth Requests. This caused the oidc library to fallback to the default
based on the response_type.
# How the Problems Are Solved
- Store the `response_mode` in the Auth request repo
- Store the `response_mode` in the Auth request v2 events
- Return the `resonse_mode` from the Auth Request v1 and v2
`ResponseMode()` methods. (Was hard-coded to an empty string)
# Additional Changes
- Populate the `response_modes_supported` to the oidc Discovery
Configuration. When it was empty, the standard specifies the default of
`query` and `fragment`. However, our oidc library also supports
`form_post` and by this fix, zitadel now also supports this.
# Additional Context
- Closes#6586
- Reported
https://discord.com/channels/927474939156643850/1151508313717084220
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Introduced with #6909, the authentication check (API client) and the
token verification on the introspection endpoint where parallelized to
improve performance. Only the first error would be considered and
returned (and the second completely ignored).
This could lead to situations where both the client authentication and
token verification failed and the response would result in a 200 OK with
`active: false`.
# How the Problems Are Solved
- The client authentication check error will always be prioritized.
- An error in the token check will no longer terminate the client
authentication check.
# Additional Changes
None.
# Additional Context
- reported in Discord:
https://discord.com/channels/927474939156643850/1242770807105781760
# Which Problems Are Solved
- Lack of documentation on integrating the Pylon framework with ZITADEL
# How the Problems Are Solved
- Adds examples to the ZITADEL documentation on how to integrate with
the Pylon framework.
- Provides clear, step-by-step instructions and code snippets for
seamless integration.
# Additional Changes
- Updates some formatting related issues. This includes changes to
trailing semicolons and array newlines in two or three instances without
significantly altering the previous formatting.
5b23416a8c
# Additional Context
Add the pylon framework to the ZITADEL documentation examples as
previously discussed with @fforootd.
- [Pylon](https://github.com/getcronit/pylon)
- [Pylon Documentation](https://pylon.cronit.io)
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
- Swedish speakers cannot use their beautiful native language ;-)
# How the Problems Are Solved
- Contributes Swedish language for Login, Console, common texts and
Emails
# Additional Changes
- none
# Additional Context
- The PR currently provides all translation files according to
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#contribute-internationalization.
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Postgres versions < 16 require an alias for subqueries. The query
executed in the new eventstore didn't add this alias.
# How the Problems Are Solved
Added the alias to the subquery
# Fallback to Vercel CI
Since we cannot share the vercel_token on forks we cannot deploy by
vercel CLI.
This PR reverts to the last working state by using vercel CI.
I will look into a fix with an npm script or a turbo config to ignore
builds on folder changes.
# Which Problems Are Solved
an admin wants to know how to register a new user with some custom
fields
# How the Problems Are Solved
We already had examples about user metadata and onboard new users, but
the link between those and how to use it was missing.
# 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#7951
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
Add a list of files to the contribution guidelines for a new language,
which also need an extension.
# Which Problems Are Solved
At the moment we state where a contributor needs to add new translation
files, but then some lists are missing and the language is not shown to
end users.
# How the Problems Are Solved
Add contribution guidelines
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
An admin / application might want to be able to reduce the amount of
roles returned in the token, for example if a user is granted to many
organizations or for specific cases where the application want to narrow
down the access for that token to a specific organization or multiple.
This can now be achieved by providing a scope with the id of the
organization, resp. multiple scopes for every organization, which should
be included.
```
urn:zitadel:iam:org:roles🆔{orgID}
```
**Note:** the new scope does not work when Introspection / Userinfo are
set to legacy mode.
# How the Problems Are Solved
The user info query now has two variants:
1. Variant that returns all organization authorization grants if the new
scope wasn't provided for backward compatibility.
2. Variant that filters the organizations based on the IDs passed in one
or more of the above scopes and returns only those authorization grants.
The query is defined as a `text/template` and both variants are rendered
once in package `init()`.
# Additional Changes
- In the integration tests `assertProjectRoleClaims` now also checks the
org IDs in the roles.
# Additional Context
- Closes#7996
# Which Problems Are Solved
If users create discussions about the new API on their own, it could
become hard to keep the overview.
# How the Problems Are Solved
We invite to participate in a single dedicated discussion.
# Additional Changes
Removes the link to the office hours event, as it took place already.
# Which Problems Are Solved
This allows us to build multiple docs in parallel and only runs when
docs/proto are changed.
# Additional Changes
- [ ] Change "required" in GitHub from Vercel to the docs flow
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Some management requests did not state that the `x-zitadel-orgid` can /
needs to be sent as part of the request.
# How the Problems Are Solved
Added it as paart of the swagger / openAPI documentation.
# Additional Changes
None.
# Additional Context
- noted by a customer
# Which Problems Are Solved
Request to the ZITADEL API currently require multi factor authentication
if the user has set up any second factor.
However, the login UI will only prompt the user to check factors that
are allowed by the login policy.
This can lead to situations, where the user has set up a factor (e.g.
some OTP) which was not allowed by the policy, therefore will not have
to verify the factor, the ZITADEL API however will require the check
since the user has set it up.
# How the Problems Are Solved
The requirement for multi factor authentication based on the user's
authentication methods is removed when accessing the ZITADEL APIs.
Those requests will only require MFA in case the login policy does so
because of `requireMFA` or `requireMFAForLocalUsers`.
# Additional Changes
None.
# Additional Context
- a customer reached out to support
- discussed internally
- relates #7822
- backport to 2.53.x
# Which Problems Are Solved
Introduced with #7822 the access token response incorrectly returned the
`state` parameter.
# How the Problems Are Solved
The `state` will only be returned for access token responses in an
implicit_flow.
# Additional Changes
None.
# Additional Context
- relates to #7822
- relates to
https://github.com/zitadel/oidc/issues/446#issuecomment-2144999644
- backport to 2.53.x
---------
Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
# Which Problems Are Solved
This PR fixes a typo in the documentation
# How the Problems Are Solved
N/A
# Additional Changes
N/A
# Additional Context
N/A
Co-authored-by: Fabi <fabienne@zitadel.com>
# Which Problems Are Solved
Access token checks make sure that there have not been any termination
events (user locked, deactivated, signed out, ...) in the meantime. This
events were filtered based on the creation date of the last session
event, which might cause latency issues in the database.
# How the Problems Are Solved
- Changed the query to use `position` instead of `created_at`.
- removed `AwaitOpenTransactions`
# Additional Changes
Added the `position` field to the `ReadModel`.
# Additional Context
- relates to #8088
- part of #7639
- backport to 2.53.x
# Which Problems Are Solved
When an error occurred during the oidc session creation from
client_credentials or jwt_profile, the error was ignored.
# How the Problems Are Solved
Return the error.
# Additional Changes
None.
# Additional Context
- relates to #7822
- noticed internally
- backport to 2.53.x
# Which Problems Are Solved
After migrating the access token events in #7822, milestones based on
authentication, resp. theses events would not be reached.
# How the Problems Are Solved
Additionally use the `oidc_session.Added` event to check for
`milestone.AuthenticationSucceededOnInstance` and
`milestone.AuthenticationSucceededOnApplication`.
# Additional Changes
None.
# Additional Context
- relates to #7822
- noticed internally
# Which Problems Are Solved
Terraform provider docs without introcution and "here" links were hard
to search for.
# How the Problems Are Solved
Updated docs page
# Additional Changes
changed the slug for more clarity and added a redirect
# Which Problems Are Solved
The init job fails if no database called *postgres* or *defaultdb* for
cockroach respectively exists.
# How the Problems Are Solved
The value is now configurable, for example by env variable
*ZITADEL_DATABASE_POSTGRES_ADMIN_EXISTINGDATABASE*
# Additional Context
- Closes#5810
# Which Problems Are Solved
Corrects reading of default configuration, despite reading all default
configs only required defaults are read.
# How the Problems Are Solved
Reading the defualt config of the `mirror`-command was moved to a
pre-run step of the command instead of doing it during initialization of
the executable.
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/8059
- https://discord.com/channels/927474939156643850/1248594307267559535
# Which Problems Are Solved
We identified some parts in the code, which could panic with a nil
pointer when accessed without auth request.
Additionally, if a GRPC method was called with an unmapped HTTP method,
e.g. POST instead of GET a 501 instead of a 405 was returned.
# How the Problems Are Solved
- Additional checks for existing authRequest
- custom http status code mapper for gateway
# Additional Changes
None.
# Additional Context
- noted internally in OPS
# Which Problems Are Solved
We have not enough internal and external input about our ideas for the
new API design.
# How the Problems Are Solved
We make the concepts easily accessible by publishing them in our docs
and making them concise.
# Additional Context
- Contributes to #6305
- Replaces the PR #7821 which defines protos in more detail
Only resources and settings are in the scope of this concept.
A possible solution for defining the outscoped methods could for example
look like this:
## ZITADELInsights
query services for auditing, analytics and data synchronization.
- Events
- Milestones
## ZITADELOperations
- Health
- Failed Events
- Views
- Metrics (version, uptime etc.)
# Which Problems Are Solved
During tests of 2.53.3 we noticed that in cases where the
`idTokenRoleAssertion` was disabled, claims set in the
preAccessTokenTrigger where also set in the id_token.
# How the Problems Are Solved
The userinfo of the id_token now uses a correct copy of their own.
# Additional Changes
None.
# Additional Context
- relates to #7822
- relates to #8046
# Which Problems Are Solved
After deployment of 2.53.x, customers noted that the roles claims where
always present in the tokens even if the corresponding option on the
client (accessTokenRoleAssertion, idTokenRoleAsseriton) was disabled.
Only the project flag (assertRolesOnAuthentication) would be considered.
Further it was noted, that the action on the preAccessTokenCreation
trigger would not be executed.
Additionally, while testing those issues we found out, that the user
information (name, givenname, family name, ...) where always present in
the id_token even if the option (idTokenUserInfo) was not enabled.
# How the Problems Are Solved
- The `getUserinfoOnce` which was used for access and id_tokens is
refactored to `getUserInfo` and no longer only queries the info once
from the database, but still provides a mechanism to be reused for
access and id_token where the corresponding `roleAssertion` and action
`triggerType` can be passed.
- `userInfo` on the other hand now directly makes sure the information
is only queried once from the database. Role claims are asserted every
time and action triggers are executed on every call.
- `userInfo` now also checks if the profile information need to be
returned.
# Additional Changes
None.
# Additional Context
- relates to #7822
- reported by customers
# Which Problems Are Solved
Introspection errors such as invalid audience and errors in the login UI
such as invalid user agents where all logged as severity error.
# How the Problems Are Solved
Log level for both general loggers is changed to `info`.
# Additional Changes
None
# Additional Context
- internal discussion
# Which Problems Are Solved
The session API was designed to be flexible enough for multiple use
cases / login scenarios, where the login could respect the login policy
or not. The session API itself does not have a corresponding policy and
would not check for a required MFA or alike. It therefore also did not
yet respect the lockout policy and would leave it to the login UI to
handle that.
Since the lockout policy is related to the user and not the login
itself, we decided to handle the lockout also on calls of the session
API.
# How the Problems Are Solved
If a lockout policy is set for either password or (T)OTP checks, the
corresponding check on the session API be run against the lockout check.
This means that any failed check, regardless if occurred in the session
API or the current hosted login will be counted against the maximum
allowed checks of that authentication mechanism. TOTP, OTP SMS and OTP
Email are each treated as a separate mechanism.
For implementation:
- The existing lockout check functions were refactored to be usable for
session API calls.
- `SessionCommand` type now returns not only an error, but also
`[]eventstore.Command`
- these will be executed in case of an error
# Additional Changes
None.
# Additional Context
Closes#7967
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
