8000 fix(account): don't drop application.client from the kcContext by e210 · Pull Request #1049 · keycloakify/keycloakify · GitHub
[go: up one dir, main page]

Skip to content

fix(account): don't drop application.client from the kcContext - #1049

Merged
garronej merged 1 commit into
keycloakify:mainfrom
e210:fix-1040-account-applications-client
Oct 2, 2026
Merged

garronej merged 1 commit into
keycloakify:mainfrom
e210:fix-1040-account-applications-client

Conversation

@e210
@e210 e210 commented Aug 5, 2026 •
Copy link
Copy Markdown
Contributor

On the applications.ftl page of the Multi-Page account theme, every application.client is a ClientModel, so the org.keycloak.models blocklist dropped it. The stock Applications page then throws on application.client.clientId and renders nothing.

Adds an exception scoped to that exact path, next to the existing OTPPolicy one. Verified end to end on Keycloak 26.7.0.

Fixes #1040

Summary by CodeRabbit

  • Bug Fixes
    • Fixed an issue where application data could fail to load on the applications page when it included client details.
    • Improved serialization of application information for more reliable page rendering.

@coderabbitai
8000 coderabbitai Bot commented Aug 5, 2026 •
Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 18550ec8-29d3-4cc6-af76-fb624e1acebc

📥 Commits

Reviewing files that changed from the base of the PR and between 225ba45 and 0f71da0.

📒 Files selected for processing (1)
  • src/bin/keycloakify/generateFtl/kcContextDeclarationTemplate.ftl
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/bin/keycloakify/generateFtl/kcContextDeclarationTemplate.ftl

📝 Walkthrough

Walkthrough

The serializer now permits ClientModel values at applications.applications[*].client on applications.ftl, preventing those values from being discarded as internal Keycloak objects.

Changes

Applications client serialization

Layer / File(s) Summary
Serializer exception for application clients
src/bin/keycloakify/generateFtl/kcContextDeclarationTemplate.ftl
Adds a path-specific exception so ClientModel values on applications.ftl bypass the internal-Keycloak serialization abort.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the fix to retain application.client in kcContext.
Linked Issues check ✅ Passed The change preserves application.client fields, prevents applications.ftl failures, and keeps the broader model protection in place for issue #1040.
Out of Scope Changes check ✅ Passed The change is limited to the serializer exception required to retain applications.applications[].client.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@garronej garronej left a comment
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

The mechanism introduced in 61e56ec (released in v11.9.13) to keep Keycloak
internals out of the kcContext discards any object whose class lives under
`org.keycloak.models`.

On the `applications.ftl` page of the multi page account theme each
`applications.applications[i].client` is a `ClientModel`, so the whole object
was dropped. `Applications.tsx` dereferences `application.client.clientId`
inside a `.map` without a guard, so the page doesn't merely lose data, it
throws `TypeError: Cannot read properties of undefined (reading 'name')` and
renders nothing at all.

That page is meant to expose the client, so this is a false positive rather
than an internal leaking out. Add an exception scoped to that exact path, next
to the existing `OTPPolicy` and `RequiredActionProviderModel` ones. Matching on
the path rather than on the class name keeps the exception narrow: a
`ClientModel` reached through any other path, or on any other page, is still
filtered out, and `client.realm`, `client.container`, `client.secret` and the
`*Stream` properties remain excluded by the pre-existing rules.

Verified end to end on Keycloak 26.7.0 with the multi page account theme.

Fixes keycloakify#1040
@e210
e210 force-pushed the fix-1040-account-applications-client branch from 83ba80b to 0f71da0 Compare August 6, 2026 06:16
@coderabbitai
coderabbitai Bot commented Aug 6, 2026
Copy link
Copy Markdown
Contributor

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

@e210
e210 requested a review from garronej August 26, 2026 12:52
@e210
e210 commented Oct 2, 2026
Copy link
Copy Markdown
Contributor Author

@garronej this is ready whenever you have a moment — the themeType == "account" guard you suggested is applied in 0f71da0c. The review is still marked as changes-requested, so I wanted to flag that there's nothing outstanding on my side.

@garronej
garronej merged commit 985a8b0 into keycloakify:main Oct 2, 2026
1 check passed
@garronej
garronej commented Oct 2, 2026
Copy link
Copy Markdown
Collaborator

Sorry for the delay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multi-Page account theme: applications.applications[].client is dropped from kcContext

2 participants

0