# Which Problems Are Solved
Fields table entry is not removed when removing instance domain.
# How the Problems Are Solved
Remove the fields entry, instead of setting it.
# Additional Changes
None
# Additional Context
Needs to be backported to v3.x
# Which Problems Are Solved
Flakiness in integration tests regarding gofakeit functions, which
provided the same names on 2 different occasions.
# How the Problems Are Solved
Attach a random string to the provided names, so that they are not
dependent on the gofakeit code.
# Additional Changes
None
# Additional Context
None
---------
Co-authored-by: Marco A. <marco@zitadel.com>
# Which Problems Are Solved
The deletion of expired sessions does not go through even though a
success response is returned to the user. These expired and supposedly
deleted (to the user) sessions are then returned when the `ListSessions`
API is called.
This PR fixes this issue by:
1. Allowing deletion of expired sessions
2. Providing an `expiration_date` filter in `ListSession` API to filter
sessions by expiration date
# How the Problems Are Solved
1. Remove expired session check during deletion
2. Add an `expiration_date` filter to the `ListSession` API
# Additional Changes
N/A
# Additional Context
- Closes#10045
---------
Co-authored-by: Marco A. <marco@zitadel.com>
# Which Problems Are Solved
There is an outstanding bug wherein a session projection can fail to
complete and an session OTP challenge is blocked because the projection
doesn't exist. Not sure why the session projection can fail to persist -
I can't find any error logs or failed events to crosscheck. However, I
can clearly see the session events persisted with user/password checks
and the OTP challenged added on the session - but no session projection
on sessions8 table.
This only seems to come up under somewhat higher loads - about 5
logins/s and only for about 1% of cases. (where a "login" is:
authRequest, createSession, getAuthCodeWithSession, tokenExchange, and
finally, otpSmsChallenge...💥).
# How the Problems Are Solved
This is only half a fix, but an important one as it can block login for
affected users. Instead of triggering and checking the session
projection on notification enqueuing, build a write model directly from
the ES.
# Additional Changes
# Additional Context
This doesn't touch the "legacy" notification handler as to limit the
blast radius of this change. But might be worth adding there too.
The test is difficult to update correctly so is somewhat incomplete. Any
suggestions for refactoring or test helpers I'm missing would be
welcome.
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
In the SAML responses from some IDPs (e.g. ADFS and Shibboleth), the
`<NameID>` part could be missing in `<Subject>`, and in some cases, the
`<Subject>` part might be missing as well. This causes Zitadel to fail
the SAML login with the following error message:
```
ID=SAML-EFG32 Message=Errors.Intent.ResponseInvalid
```
# How the Problems Are Solved
This is solved by adding a workaround to accept a transient mapping
attribute when the `NameID` or the `Subject` is missing in the SAML
response. This requires setting the custom transient mapping attribute
in the SAML IDP config in Zitadel, and it should be present in the SAML
response as well.
<img width="639" height="173" alt="image"
src="https://github.com/user-attachments/assets/cbb792f1-aa6c-4b16-ad31-bd126d164eae"
/>
# Additional Changes
N/A
# Additional Context
- Closes#10251
# Which Problems Are Solved
There is a good amount of people from the community that need to
retrieve users matching some metadata stored on the user itself.
It is currently not possible to achieve that, the current solution
entails retrieving the user first, reading the metas and aggregating the
data together based on the metas.
We want to offer a way to search through user metas and return the user
info matching the search.
# How the Problems Are Solved
This PR contains only the protobuf so that it's easier to review.
# Additional Changes
Converter methods have been moved to their own package to avoid
cluttering and have better organization. The converter methods have also
been tested
# Additional Context
Discussion #9053
# Which Problems Are Solved
The Actions v2beta API is not yet promoted to GA.
# How the Problems Are Solved
Promote Actions v2Beta API to Actions v2 API.
# Additional Changes
None
# Additional Context
None
# Which Problems Are Solved
Currently the username uniqueness is on instance level, we want to
achieve a way to set it at organization level.
# How the Problems Are Solved
Addition of endpoints and a resource on organization level, where this
setting can be managed. If nothing it set, the uniqueness is expected to
be at instance level, where only users with instance permissions should
be able to change this setting.
# Additional Changes
None
# Additional Context
Includes #10086Closes#9964
---------
Co-authored-by: Marco A. <marco@zitadel.com>
# Which Problems Are Solved
[Permissions v2](https://github.com/zitadel/zitadel/issues/9972) is not
possible in the current implementation.
# How the Problems Are Solved
We remove Permissions v2 from project grants related API calls, to
alleviate this problems.
Resulting in some removals of testing, implementations and performance
impact
# Additional Changes
None
# Additional Context
None
## Which problems are solved
The execution of statements of projections did not have the context
present.
## How the problems were solved
Pass the context to the execute function
## Additional info
This change is required to use the repositories of the relational tables
in projections.
Removes manual schema and application name setup via raw SQL and
switches to using River’s built-in schema configuration.
# Which Problems Are Solved
River provides a configuration flag to set the schema of the queue.
Zitadel sets the schema through database statements which is not needed
anymore.
# How the Problems Are Solved
Set the schema in the river configuration and removed old code
# Which Problems Are Solved
There is no information contained in the context info sent to Actions
v2.
# How the Problems Are Solved
Add application information to the context information sent to Actions
v2, to give more information about the execution.
# Additional Changes
None
# Additional Context
Closes#9377
# Which Problems Are Solved
The OIDC session endpoint allows to pass a `id_token_hint` to identify
the session to terminate. In case the application is not able to pass
that, e.g. Console currently allows multiple sessions to be open, but
will only store the id_token of the current session, allowing to pass
the `logout_hint` to identify the user adds some new possibilities.
# How the Problems Are Solved
In case the end_session_endpoint is called with no `id_token_hint`, but
a `logout_hint` and the v2 login UI is configured, the information is
passed to the login UI also as `login_hint` parameter to allow the login
UI to determine the session to be terminated, resp. let the user decide.
# Additional Changes
Also added the `ui_locales` as parameter to handle and pass to the V2
login UI.
# Dependencies ⚠️
~These changes depend on https://github.com/zitadel/oidc/pull/774~
# Additional Context
closes#9847
---------
Co-authored-by: Marco Ardizzone <marco@zitadel.com>
# Which Problems Are Solved
Actions v2beta API does not adhere to the [API
design](https://github.com/zitadel/zitadel/blob/main/API_DESIGN.md)
fully.
# How the Problems Are Solved
- Correct body usage for ListExecutions
- Correct REST path for ListTargets and ListExecutions
- Correct attribute names for ListTargetsResponse and
ListExecutionsResponse
# Additional Changes
- Remove unused object import.
# Additional Context
Closes#10138
---------
Co-authored-by: Marco A. <marco@zitadel.com>
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
Okta sends a random password in the request to create a user during SCIM
provisioning, irrespective of whether the `Sync Password` option is
enabled or disabled on Okta, and this password does not comply with the
default password complexity set in Zitadel. This PR adds a workaround to
create users without issues in such cases.
# How the Problems Are Solved
- A new metadata configuration called
`urn:zitadel:scim:ignorePasswordOnCreate` is added to the Machine User
that is used for provisioning
- During SCIM user creation requests, if the
`urn:zitadel:scim:ignorePasswordOnCreate` is set to `true` in the
Machine User's metadata, the password set in the create request is
ignored
# Additional Changes
# Additional Context
The random password is ignored (if set in the metadata) only during
customer creation. This change does not affect SCIM password updates.
- Closes#10009
---------
Co-authored-by: Marco A. <marco@zitadel.com>
- Turkish language support is added.
- Updated other language files to add Turkish selection.
# Which Problems Are Solved
- Zitadel was not supporting Turkish language. Now supporting.
# How the Problems Are Solved
- Turkish language files are added and updated other language files in
below paths to add Turkish support;
- /console/src/assets/i18n/
- /internal/api/ui/login/static/i18n
- /internal/notification/static/i18n
- /internal/static/i18n
# Additional Changes
- Made changes below files for codes/docs changes;
- /console/src/app/utils/language.ts
- /console/src/app/app.module.ts
- /docs/docs/guides/manage/customize/texts.md
- /internal/api/ui/login/static/templates/external_not_found_option.html
- /internal/query/v2-default.json
- /login/apps/login/src/lib/i18n.ts
---------
Co-authored-by: Marco A. <marco@zitadel.com>
# Which Problems Are Solved
When adding 2 orgs with the same ID, you get a positive response from
the API, later when the org is projected, it errors due to the id
already in use
# How the Problems Are Solved
Check org with orgID specified does not already exist before adding
events
# Additional Changes
Added additional test case for adding same org with same name twice
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/10127
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
The SAML session (v2 login) currently does not push a
`AuthenticationSucceededOnApplication` milestone upon successful SAML
login for the first time. The changes in this PR address this issue.
# How the Problems Are Solved
Add a new function to set the appropriate milestone, and call this
function after a successful SAML request.
# Additional Changes
N/A
# Additional Context
- Closes#9592
---------
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
The latest merge on main corrupted some unit tests.
# How the Problems Are Solved
Fix them as intended on the PR.
# Additional Changes
None
# Additional Context
relates to
4c942f3477
# Which Problems Are Solved
Enhancing integration test for creating org; currently the test does not
check if the created org has the assigned custom id, this will resolve
this issue.
# Which Problems Are Solved
After changing some internal logic, which should have failed the
integration test, but didn't, I noticed that some integration tests were
never executed. The make command lists all `integration_test` packages,
but some are named `integration`
# How the Problems Are Solved
Correct wrong integration test package names.
# Additional Changes
None
# Additional Context
- noticed internally
- backport to 3.x and 2.x
# Which Problems Are Solved
Fixes issue when users would get an error message when attempting to
resend invitation code when logging in
# How the Problems Are Solved
Changing the permission check for looking for `org.write` to
`ommand.checkPermissionUpdateUser()`
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/10100
- backport to 3.x
# Which Problems Are Solved
The CORS handler for the new connectRPC handlers was missing, leading to
unhandled preflight requests and a unusable api for browser based calls,
e.g. cross domain gRPC-web requests.
# How the Problems Are Solved
- Added the http CORS middleware to the connectRPC handlers.
- Added `Grpc-Timeout`, `Connect-Protocol-Version`,`Connect-Timeout-Ms`
to the default allowed headers (this improves also the old grpc-web
handling)
- Added `Grpc-Status`, `Grpc-Message`, `Grpc-Status-Details-Bin` to the
default exposed headers (this improves also the old grpc-web handling)
# Additional Changes
None
# Additional Context
noticed internally while testing other issues
# Which Problems Are Solved
When an organization domain is verified, e.g. also when creating a new
organization (incl. generated domain), existing usernames are checked if
the domain has been claimed.
The query was not optimized for instances with many users and
organizations.
# How the Problems Are Solved
- Replace the query, which was searching over the users projection with
(computed loginnames) with a dedicated query checking the loginnames
projection directly.
- All occurrences have been updated to use the new query.
# Additional Changes
None
# Additional Context
- reported through support
- requires backport to v3.x
# Which Problems Are Solved
When authenticating with email or phone number in the login V1, users
were not able to request a password reset and would be given a "User not
found" error.
This was due to a check of the loginname of the auth request, which in
those cases would not match the user's stored loginname.
# How the Problems Are Solved
Switch to a check of the resolved userID in the auth request. (We still
check the user again, since the ID might be a placeholder for an unknown
user and we do not want to disclose any information by omitting a check
and reduce the response time.)
# Additional Changes
None
# Additional Context
- reported through support
- requires backport to v3.x
# Which Problems Are Solved
Customers reported, that if the session / access token in Console
expired and they re-authenticated, the user list would be empty.
While reproducing the issue, we discovered that the necessary
organization information, would be missing in the access token, since
this would already be missing in the OIDC session creation when using an
id_token_hint.
# How the Problems Are Solved
- Ensure the user's organization is set in the login v1 auth request.
This is used to create the OIDC and token information.
# Additional Changes
None
# Additional Context
- reported by customers
- requires backport to v3.x
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
1. The sorting columns in the gRPC endpoint
`ListInstanceTrustedDomains()` are incorrect, and return the following
error when invalid sorting options are chosen:
```
Unknown (2)
ERROR: missing FROM-clause entry for table "instance_domains" (SQLSTATE 42P01)
```
The sorting columns that are valid to list `instance_trusted_domains`
are
* `trusted_domain_field_name_unspecified`
* `trusted_domain_field_name_domain`
* `trusted_domain_field_name_creation_date`
However, the currently configured sorting columns are
* `domain_field_name_unspecified`
* `domain_field_name_domain`
* `domain_field_name_primary`
* `domain_field_name_generated`
* `domain_field_name_creation_date`
Configuring the actual columns of `instance_trusted_domains` makes this
endpoint **backward incompatible**. Therefore, the fix in this PR is to
no longer return an error when an invalid sorting column (non-existing
column) is chosen and to sort the results by `creation_date` for invalid
sorting columns.
2. This PR also fixes the `sorting_column` included in the responses of
both `ListInstanceTrustedDomains()` and `ListInstanceDomains()`
endpoints, as they now point to the default option irrespective of the
chosen option in the request i.e.,
* `TRUSTED_DOMAIN_FIELD_NAME_UNSPECIFIED` in case of
`ListInstanceTrustedDomains()`, and
* `DOMAIN_FIELD_NAME_UNSPECIFIED` in case of `ListInstanceDomains()`
# How the Problems Are Solved
* Map the sorting columns to valid columns of `instance_trusted_domain`
- If the sorting column is not one of the columns, the mapping defaults
to `creation_date`
* Set the `sorting_column` explicitly (from the request) in the
`ListInstanceDomainsResponse` and `ListInstanceTrustedDomainsResponse`
# Additional Changes
A small fix to return the chosen `sorting_column` in the responses of
the `ListInstanceTrustedDomains()` and `ListInstanceDomains()` endpoints
# Additional Context
- Closes#9839
# Which Problems Are Solved
The commands for the resource based v2beta AuthorizationService API are
added.
Authorizations, previously knows as user grants, give a user in a
specific organization and project context roles.
The project can be owned or granted.
The given roles can be used to restrict access within the projects
applications.
The commands for the resource based v2beta InteralPermissionService API
are added.
Administrators, previously knows as memberships, give a user in a
specific organization and project context roles.
The project can be owned or granted.
The give roles give the user permissions to manage different resources
in Zitadel.
API definitions from https://github.com/zitadel/zitadel/issues/9165 are
implemented.
Contains endpoints for user metadata.
# How the Problems Are Solved
### New Methods
- CreateAuthorization
- UpdateAuthorization
- DeleteAuthorization
- ActivateAuthorization
- DeactivateAuthorization
- ListAuthorizations
- CreateAdministrator
- UpdateAdministrator
- DeleteAdministrator
- ListAdministrators
- SetUserMetadata to set metadata on a user
- DeleteUserMetadata to delete metadata on a user
- ListUserMetadata to query for metadata of a user
## Deprecated Methods
### v1.ManagementService
- GetUserGrantByID
- ListUserGrants
- AddUserGrant
- UpdateUserGrant
- DeactivateUserGrant
- ReactivateUserGrant
- RemoveUserGrant
- BulkRemoveUserGrant
### v1.AuthService
- ListMyUserGrants
- ListMyProjectPermissions
# Additional Changes
- Permission checks for metadata functionality on query and command side
- correct existence checks for resources, for example you can only be an
administrator on an existing project
- combined all member tables to singular query for the administrators
- add permission checks for command an query side functionality
- combined functions on command side where necessary for easier
maintainability
# Additional Context
Closes#9165
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
The current maintained gRPC server in combination with a REST (grpc)
gateway is getting harder and harder to maintain. Additionally, there
have been and still are issues with supporting / displaying `oneOf`s
correctly.
We therefore decided to exchange the server implementation to
connectRPC, which apart from supporting connect as protocol, also also
"standard" gRCP clients as well as HTTP/1.1 / rest like clients, e.g.
curl directly call the server without any additional gateway.
# How the Problems Are Solved
- All v2 services are moved to connectRPC implementation. (v1 services
are still served as pure grpc servers)
- All gRPC server interceptors were migrated / copied to a corresponding
connectRPC interceptor.
- API.ListGrpcServices and API. ListGrpcMethods were changed to include
the connect services and endpoints.
- gRPC server reflection was changed to a `StaticReflector` using the
`ListGrpcServices` list.
- The `grpc.Server` interfaces was split into different combinations to
be able to handle the different cases (grpc server and prefixed gateway,
connect server with grpc gateway, connect server only, ...)
- Docs of services serving connectRPC only with no additional gateway
(instance, webkey, project, app, org v2 beta) are changed to expose that
- since the plugin is not yet available on buf, we download it using
`postinstall` hook of the docs
# Additional Changes
- WebKey service is added as v2 service (in addition to the current
v2beta)
# Additional Context
closes#9483
---------
Co-authored-by: Elio Bischof <elio@zitadel.com>
# Which Problems Are Solved
The production endpoint of the service ping was wrong.
Additionally we discussed in the sprint review, that we could randomize
the default interval to prevent all systems to report data at the very
same time and also require a minimal interval.
# How the Problems Are Solved
- fixed the endpoint
- If the interval is set to @daily (default), we generate a random time
(minute, hour) as a cron format.
- Check if the interval is more than 30min and return an error if not.
- Fixed yaml indent on `ResourceCount`
# Additional Changes
None
# Additional Context
as discussed internally
This PR is still WIP and needs changes to at least the tests.
# Which Problems Are Solved
To be able to report analytical / telemetry data from deployed Zitadel
systems back to a central endpoint, we designed a "service ping"
functionality. See also https://github.com/zitadel/zitadel/issues/9706.
This PR adds the first implementation to allow collection base data as
well as report amount of resources such as organizations, users per
organization and more.
# How the Problems Are Solved
- Added a worker to handle the different `ReportType` variations.
- Schedule a periodic job to start a `ServicePingReport`
- Configuration added to allow customization of what data will be
reported
- Setup step to generate and store a `systemID`
# Additional Changes
None
# Additional Context
relates to #9869
# Which Problems Are Solved
To prevent presenting unusable WebAuthN credentials to the user /
browser, we filtered out all credentials, which do not match the
requested RP ID. Since credentials set up through Login V1 and Console
do not have an RP ID stored, they never matched. This was previously
intended, since the Login V2 could be served on a separate domain.
The problem is, that if it is hosted on the same domain, the credentials
would also be filtered out and user would not be able to login.
# How the Problems Are Solved
Change the filtering to return credentials, if no RP ID is stored and
the requested RP ID matches the instance domain.
# Additional Changes
None
# Additional Context
Noted internally when testing the login v2
# Which Problems Are Solved
We provide a seamless way to initialize Zitadel and the login together.
# How the Problems Are Solved
Additionally to the `IAM_OWNER` role, a set up admin user also gets the
`IAM_LOGIN_CLIENT` role if it is a machine user with a PAT.
# Additional Changes
- Simplifies the load balancing example, as the intermediate
configuration step is not needed anymore.
# Additional Context
- Depends on #10116
- Contributes to https://github.com/zitadel/zitadel-charts/issues/332
- Contributes to https://github.com/zitadel/zitadel/issues/10016
---------
Co-authored-by: Stefan Benz <46600784+stebenz@users.noreply.github.com>
# Which Problems Are Solved
This PR *partially* addresses #9450 . Specifically, it implements the
resource based API for app keys.
This PR, together with https://github.com/zitadel/zitadel/pull/10077
completes #9450 .
# How the Problems Are Solved
- Implementation of the following endpoints: `CreateApplicationKey`,
`DeleteApplicationKey`, `GetApplicationKey`, `ListApplicationKeys`
- `ListApplicationKeys` can filter by project, app or organization ID.
Sorting is also possible according to some criteria.
- All endpoints use permissions V2
# TODO
- [x] Deprecate old endpoints
# Additional Context
Closes#9450
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
The current user V2 API returns a `[]byte` containing a whole HTML
document including the form on `StartIdentifyProviderIntent` for intents
based on form post (e.g. SAML POST bindings). This is not usable for
most clients as they cannot handle that and render a whole page inside
their app.
For redirect based intents, the url to which the client needs to
redirect is returned.
# How the Problems Are Solved
- Changed the returned type to a new `FormData` message containing the
url and a `fields` map.
- internal changes:
- Session.GetAuth now returns an `Auth` interfacce and error instead of
(content string, redirect bool)
- Auth interface has two implementations: `RedirectAuth` and `FormAuth`
- All use of the GetAuth function now type switch on the returned auth
object
- A template has been added to the login UI to execute the form post
automatically (as is).
# Additional Changes
- Some intent integration test did not check the redirect url and were
wrongly configured.
# Additional Context
- relates to zitadel/typescript#410
# Which Problems Are Solved
Remove the feature flag that allowed triggers in introspection. This
option was a fallback in case introspection would not function properly
without triggers. The API documentation asked for anyone using this flag
to raise an issue. No such issue was received, hence we concluded it is
safe to remove it.
# How the Problems Are Solved
- Remove flags from the system and instance level feature APIs.
- Remove trigger functions that are no longer used
- Adjust tests that used the flag.
# Additional Changes
- none
# Additional Context
- Closes#10026
- Flag was introduced in #7356
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
This PR *partially* addresses #9450 . Specifically, it implements the
resource based API for the apps. APIs for app keys ARE not part of this
PR.
# How the Problems Are Solved
- `CreateApplication`, `PatchApplication` (update) and
`RegenerateClientSecret` endpoints are now unique for all app types:
API, SAML and OIDC apps.
- All new endpoints have integration tests
- All new endpoints are using permission checks V2
# Additional Changes
- The `ListApplications` endpoint allows to do sorting (see protobuf for
details) and filtering by app type (see protobuf).
- SAML and OIDC update endpoint can now receive requests for partial
updates
# Additional Context
Partially addresses #9450
