# Which Problems Are Solved
I fixed spelling, grammar and translation misstakes in the german
translation file.
I noticed something else. Some strings use the formal form ("sie") of
address and some strings use the informal (du) form of address.
# Additional Context
- Discussion #8211
# 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
To improve performance a new table and method is implemented on
eventstore. The goal of this table is to index searchable fields on
command side to use it on command and query side.
The table allows to store one primitive value (numeric, text) per row.
The eventstore framework is extended by the `Search`-method which allows
to search for objects.
The `Command`-interface is extended by the `SearchOperations()`-method
which does manipulate the the `search`-table.
# How the Problems Are Solved
This PR adds the capability of improving performance for command and
query side by using the `Search`-method of the eventstore instead of
using one of the `Filter`-methods.
# Open Tasks
- [x] Add feature flag
- [x] Unit tests
- [ ] ~~Benchmarks if needed~~
- [x] Ensure no behavior change
- [x] Add setup step to fill table with current data
- [x] Add projection which ensures data added between setup and start of
the new version are also added to the table
# Additional Changes
The `Search`-method is currently used by `ProjectGrant`-command side.
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/8094
# 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
When we switched to V2 tokens (#7822), the user agent was incorrectly
set for sessions created though the login UI.
Additionally, when calling the ListMyUserSessions from the AuthService,
any session without the fingerprint ID (e.g. created through the session
API) would be listed.
# How the Problems Are Solved
- Use the intended ID of the user agent (fingerprint)
- Ignore empty user agent IDs when listing the user sessions
# Additional Changes
None.
# Additional Context
- relates #7822
- closes#8213
In issue #7841 @mahmoodfathy commented an issue when the API call for
Listing My ZITADEL Manager Roles is called with any kind of query
(orgQuery, projectQuery, projectGrantQuery...). A column XXXXXX does not
exist (SQLSTATE 42703) error is thrown.
The issue was focused in getMembershipFromQuery where filtering queries
functions are called: prepareOrgMember, prepareIAMMember,
prepareProjectMember and prepareProjectGrantMember
Those functions allow queries for columns that are not members of the
table to be queried so I've added a conditional clause to avoid using
the queries that cannot be called.
For example, for prepareOrgMember, member.id, member.project_id and
member.grant_id columns are not added to the filter queries
```
for _, q := range query.Queries {
if q.Col().table.name == membershipAlias.name &&
!slices.Contains([]string{membershipIAMID.name, membershipProjectID.name, membershipGrantID.name}, q.Col().name) {
builder = q.toQuery(builder)
}
}
return builder.MustSql()
```
Here I show one screenshot where the error "column XXXXXX does not exist
(SQLSTATE 42703)" is no longer thrown using an orgQuery.
Should close#7841
### Definition of Ready
- [X] I am happy with the code
- [X] Short description of the feature/issue is added in the pr
description
- [X] PR is linked to the corresponding user story
- [X] Acceptance criteria are met
- [ ] All open todos and follow ups are defined in a new ticket and
justified
- [ ] Deviations from the acceptance criteria and design are agreed with
the PO and documented.
- [X] No debug or dead code
- [X] My code has no repetitions
- [X] Critical parts are tested automatically
- [ ] Where possible E2E tests are implemented
- [ ] Documentation/examples are up-to-date
- [ ] All non-functional requirements are met
- [X] Functionality of the acceptance criteria is checked manually on
the dev system.
---------
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
- When the endpoint http://{CUSTOM-DOMAIN}/v2beta/settings/login/idps is
called the type for an activated SAML provider is not sent.
- The IDENTITY_PROVIDER_TYPE_SAML is missing
# How the Problems Are Solved
- Adds the missing IDENTITY_PROVIDER_TYPE_SAML to the
IdentityProviderType proto definition
- Adds the missing case for idpTypeToPb
- Adds the missing test case for idpTypeToPb
Here's a screenshot showing the endpoint response:
# Additional Context
- Closes#7885
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
UUIDs stored in LDAP are Octet Strings and have to be parsed, so that
they can be stored as IDs as they are not valid UTF8.
# How the Problems Are Solved
Try to parse the RawValue from LDAP as UUID, otherwise try to base64
decode and then parse as UUID, else use the data as string as before.
# Additional Changes
None
# Additional Context
Closes#7601
# 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
- Some smtp server/client combination may have problems with non-ASCII
sender names for example using an umlaut
# How the Problems Are Solved
- The same RFC1342 mechanism that was added in
#https://github.com/zitadel/zitadel/pull/6637 and later improved by
@eliobischof with BEncoding has been added to the sender name that goes
in the From header
# Additional Context
- Closes#7976
# Which Problems Are Solved
In case the user bind (user password check for LDAP IdP) fails, there's
no information about what went wrong.
This makes it hard to even impossible to find the cause.
# How the Problems Are Solved
Added logging of the error.
# Additional Changes
Additionally added a log in case no single user (none / multiple) are
found.
# Additional Context
- reported internally
# 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
Allow verification of imported passwords hashed with plain md5, without
salt. These are password digests typically created by one of:
- `printf "password" | md5sum` on most linux systems.
- PHP's `md5("password")`
- Python3's `hashlib.md5(b"password").hexdigest()`
# How the Problems Are Solved
- Upgrade passwap to
[v0.6.0](https://github.com/zitadel/passwap/releases/tag/v0.6.0)
- Add md5plain as a new verfier option in `defaults.yaml`
# Additional Changes
- Updated documentation to explain difference between `md5` (crypt) and
`md5plain` verifiers.
# Additional Context
- Requested by customer for import case
# 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>
