Overview - Zitadel/zitadel

zitadel/zitadel

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
next
288f064e fix(api): check permission based on provided data on user update # Which Problems Are Solved User are allowed to change their own data including email and phone. However, they were unintentionally able to also set them to verified without according permission. # How the Problems Are Solved Fix self-management of email and phone and disallow setting them to verified without according permission. # Additional Changes None # Additional Context - requires backport to v4.x and v3.x (cherry picked from commit 0261536243e500dccfd8c7f547d592c822478327)
14 hours ago by livio-a
Succeeded
next
14 hours ago
Succeeded
next
d2a6af8e fix(token-v2): compare subject to user id # Which Problems Are Solved Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. This is an example of such a cleartext: `V2_354201447279099906-at_354201447279165442:354201364702363650` ## Impact V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user iD. V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the DB. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token: `V2_354201447279099906-at_354201447279165442:` The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. # How the Problems Are Solved Compare the token subject with the stored user ID. If they don't match, consider the token invalid, as some type of tampering must have happened. (cherry picked from commit feab8e1fa371f3ad654640fc869b2c14f2fdb602)
9 days ago by livio-a
Succeeded
next
9 days ago
Failed
next
12 days ago
Succeeded
next
14 days ago
Succeeded
next
14 days ago
Succeeded
next
14 days ago
Succeeded
next
14 days ago
Succeeded
next
922f9ad5 fix: improve NX caching (#11434) # Which Problems Are Solved This PR improves our NX caching, especially for the console and api. It makes sure that if the console is changed the api is also rebuilt and if the api is changed the functional-ui tests are rerun. It is important to note this only fixes a subset of our problems. # How the Problems Are Solved NX ignores .gitignored files even if they are explicitly added to the inputs of an NX target. To counteract this one can add these files to a .nxignore file with a negated pattern. https://nx.dev/docs/reference/inputs#token-behavior-with-nested-projects . This solution is not documented per se but can be find in this Github issue: https://github.com/nrwl/nx/issues/6821 . Further more nx calculates the hashes of inputs at the start and does not recalculate them even if a dependency of a target changes. To solve this problem one needs to use https://nx.dev/docs/reference/inputs#outputs-of-dependent-tasks . This comment of an NX developer helped me further to understand the actual behaviour of NX: https://github.com/nrwl/nx/issues/33379#issuecomment-3657929455 . # Additional Changes Because the functional-ui tests now correctly run again they had to be fixed. This pr unifies the field names in the user create v1 and v2 ui. # Additional Context To document this somewhere, this proposed fix does not work: https://github.com/nrwl/nx/issues/6821#issuecomment-1309475504 . In my local testing NX runtime inputs also get executed at the beginning of the NX loop and ignore subsequent changes by targets. While testing this fix and browsing through NX code I found this, which could be helpful in the future and isn't documented: https://github.com/nrwl/nx/pull/31428 (cherry picked from commit 7b6395c34891f363982c07f42f4f1b9a0bac1640)
27 days ago by livio-a
Succeeded
next
27 days ago
Succeeded
next
d3321c8c fix(login): use constructUrl for implicit IdP success/failure URLs (#11389) Closes #11386 # Which Problems Are Solved This PR fixes an issue where the `successUrl` and `failureUrl` for implicit IdP flows (initiated via OIDC `idp:id:...` scopes) were being constructed using `request.nextUrl.origin`. This failed to account for: - `x-zitadel-forward-host` headers (essential for proper public URL resolution). - `NEXT_PUBLIC_BASE_PATH` configuration. # How the Problems Are Solved The fix replaces the manual string concatenation with the shared `constructUrl` helper, ensuring consistent and correct URL generation. Co-authored-by: Livio Spring <livio.a@gmail.com> (cherry picked from commit a10d13e2ecf2b7aa152d1d81dd95c34fc39a438c)
1 month ago by livio-a
Failed
next
1 month ago
Succeeded
next
c5b03392 fix(features): increment version to deal with removed event types (#11402) # Which Problems Are Solved User with older instances, created at version 3.3.3 or earlier may have been affected with feature flags no longer applying. Older version of Zitadel had a bug in console where toggling a single feature would apply a state to all features, creating around 12 events each request. Then 4 feature flags and their event types were removed in v4, meaning that the `offset` value in the projection's current state could be wrong by 4 if the instance was affected by the above bug. # How the Problems Are Solved Increment the feature projection versions, so that the tables get recomputed and the current states entries becomes accurate again. # Additional Changes - none # Additional Context - Original bug: https://github.com/zitadel/zitadel/issues/10459 - Reported through support
1 month ago by muhlemmer
Succeeded
next
c5b03392 fix(features): increment version to deal with removed event types (#11402) # Which Problems Are Solved User with older instances, created at version 3.3.3 or earlier may have been affected with feature flags no longer applying. Older version of Zitadel had a bug in console where toggling a single feature would apply a state to all features, creating around 12 events each request. Then 4 feature flags and their event types were removed in v4, meaning that the `offset` value in the projection's current state could be wrong by 4 if the instance was affected by the above bug. # How the Problems Are Solved Increment the feature projection versions, so that the tables get recomputed and the current states entries becomes accurate again. # Additional Changes - none # Additional Context - Original bug: https://github.com/zitadel/zitadel/issues/10459 - Reported through support
1 month ago by muhlemmer
Failed
next
1 month ago
Succeeded
next
d08f14c5 chore: remove linting step on next
1 month ago by livio-a
Failed
next
1 month ago
Failed
next
b85ab69e fix(login): generalize error message on code verifications # Which Problems Are Solved Using public endpoints in the login UI which accept a userID as a query parameter like the password reset endpoint, it was possible to check if a userID exists, since the response would be different depending if the id exists or not. # How the Problems Are Solved - Return generic error if either user does not exists or codes are wrong - Use the default organization's policy instead of the failing when the user's policy can't be loaded # Additional Changes None # Additional Context requires backport to v4.x and v3.x (cherry picked from commit 90395403959dcc8ca4b501613ef71f5161e83d83)
1 month ago by livio-a
Failed
next
1 month ago