feat(admin-ui): surface error/warning logs in production for environment diagnostics (#2811)#2876
Conversation
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
…ent diagnostics (#2811) Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds shared logging and log-level helpers, expands API error-message resolution, and migrates Cedarling, app-shell, auth-server, plugin, and user-management logging call sites from ChangesLogger infrastructure and migration
Sequence Diagram(s)Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 15
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx (1)
177-181:⚠️ Potential issue | 🟠 MajorSanitize production log payloads in SessionListPage error handlers (remove auth_user/raw err)
Both
logger.errorcalls inadmin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsxincludeauth_userplus session/user identifiers and the raw caughterr.admin-ui/app/utils/logger.tsforwards log arguments directly toconsole.*with no redaction/sanitization, so these values will be emitted as-is.Suggested fix
- logger.error('Failed to delete session', { - sessionId, - auth_user: item.sessionAttributes?.auth_user, - err, - }) + logger.error('Failed to delete session', { + operation: 'delete_session', + error: err instanceof Error ? err.message : String(err), + }) ... - logger.error('Failed to revoke session', { - userDn, - auth_user: item.sessionAttributes?.auth_user, - err, - }) + logger.error('Failed to revoke session', { + operation: 'revoke_session', + error: err instanceof Error ? err.message : String(err), + })🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx` around lines 177 - 181, The logger.error calls in SessionListPage (referencing sessionId, item.sessionAttributes?.auth_user, and err) are emitting raw sensitive data; remove auth_user from the payload and avoid passing the raw err object. Update both logger.error usages to only include non-sensitive identifiers (e.g., sessionId or a masked user id) and include minimal error details such as err.name and err.message (or a sanitized error code), not the full err object or raw user attributes; ensure any masking function (e.g., maskUserId) is applied to user identifiers before logging and replace the err field with err.message/err.name.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@admin-ui/app/cedarling/hooks/useCedarling.ts`:
- Around line 151-154: The logger.error call is passing the stray audience token
string 'both' as a positional argument; remove that token and call logger.error
with the intended message/metadata only (e.g., logger.error(`Cedarling
authorization failed for "${resolvedResourceId}" (${actionLabel}):
${rawMessage}`) or, if structured metadata is required by the logger, pass an
object like logger.error({ audience: 'both' }, message) — update the call at the
logger.error(...) site that references resolvedResourceId, actionLabel, and
rawMessage so no raw 'both' string is emitted as a log payload.
In `@admin-ui/app/routes/Apps/Gluu/GluuAppSidebar.tsx`:
- Around line 115-117: The current catch in loadMenus leaves pluginMenus empty
and isReady (computed from pluginMenus.length) stuck true/false causing
permanent loader; introduce a explicit state flag (e.g., menusLoaded and/or
menusError) in the GluuAppSidebar component, set menusLoaded = true in the
finally block and set menusError = true inside the catch, update the readiness
check (isReady) to require menusLoaded (e.g., isReady = menusLoaded &&
pluginMenus.length > 0), and render a non-blocking fallback UI or retry action
when menusError or menusLoaded && pluginMenus.length === 0 instead of leaving
the spinner running; update loadMenus, pluginMenus usage, and the render path
accordingly.
In `@admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx`:
- Around line 110-113: The catch block in the async click handler handleAccept
currently rethrows the error (logger.error(...); throw error) which can create
an unhandled promise rejection because onClick does not await the promise;
remove the rethrow and instead handle the error locally: call the UI error
handler (e.g., set an error state or invoke the toast/notification function)
with resolveApiErrorMessage(error as Error), keep the logger.error call, and
then return/exit normally so the promise resolves; update the catch in
handleAccept to log, show a toast/state update, and not rethrow.
In `@admin-ui/app/utils/logger.ts`:
- Around line 22-26: The loop emits every level between from and to instead of a
single entry; change the logic in the logger to print exactly one message at the
requested level by removing the for-loop and doing a single lookup using the
target rank (use the ending rank variable, e.g. to) to compute level =
LOG_LEVELS[to] and then call the console method once via
console[METHOD_BY_LEVEL[level]](...args); update any variable names accordingly
(LOG_LEVELS, METHOD_BY_LEVEL, level, print) so only the intended level is
logged.
In `@admin-ui/orval/interceptors.ts`:
- Around line 56-60: The logger.error calls in admin-ui/orval/interceptors.ts
are tagging session-recovery and session-cleanup failures with the 'dev'
audience which hides them in production; locate the logger.error invocations
that currently pass 'dev' as the first argument (the call shown as
logger.error('dev', 'Failed to recover Admin UI session:', ...) and the similar
call around lines 117-121) and change the audience to an operational audience
(e.g., 'ops') or remove the audience parameter entirely so these errors are
treated as operational and will appear in production diagnostics.
In `@admin-ui/plugins/admin/components/Assets/hooks/useAssetMutations.ts`:
- Around line 123-126: The audit logging catch currently calls
callbacksRef.current?.onError?.(auditError) which can surface an audit-only
failure as a mutation error; remove that callback invocation so audit failures
are side-effect only. In the catch block in useAssetMutations (where auditError
is constructed), keep the logger.error call (logger.error(`[Asset audit]
logAction failed for asset inum=${inum}`, auditError)) and any telemetry, but do
not call callbacksRef.current?.onError; leave the real onError usage to the
delete mutation's error path.
- Line 126: The log currently prints the raw asset identifier by interpolating
inum in the logger.error call inside useAssetMutations.ts; replace that direct
interpolation with a sanitized or tokenized value (e.g., compute redactedInum =
sanitizeIdentifier(inum) or tokenFor(inum)) and log that instead, or pass the
raw id as sanitized metadata (e.g., metadata: { assetId: redactedInum }) to the
logger; update the logger.error invocation that references inum so only the
redacted/tokenized identifier or sanitized metadata is emitted, and add or reuse
a sanitizeIdentifier/tokenFor utility function to centralize masking.
In
`@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsx`:
- Line 207: Multiple logger.error callsites in AgamaFlows.tsx are passing raw
error objects (e.g., at the logged callsites around lines 207, 241-244, 253,
376, 475, 503, 511-514) which can leak sensitive request headers; update all
uses of logger.error in the AgamaFlows component to log only safe string fields:
use error instanceof Error ? error.message : String(error), and for Axios-like
errors detect axios error shape and log controlled fields such as
error.response?.status and error.response?.data?.message while explicitly
deleting or omitting error.config and any headers before calling logger.error;
ensure every invocation of logger.error in AgamaFlows.tsx (including the
upload/project handlers and network catch blocks) follows this pattern.
In
`@admin-ui/plugins/auth-server/components/JsonViewer/components/JsonViewerDialog.tsx`:
- Around line 102-104: The toast currently interpolates raw exception text via
the detail variable in JsonViewerDialog.tsx (see variable detail and the
dispatch(updateToast(...)) call); change the dispatched toast to a concise,
user-safe message (e.g. "Unable to copy to clipboard") instead of including
detail, while keeping the full error logged via logger.error(err) for
diagnostics; update the dispatch call to use a static message and leave
logger.error as-is (or enhance it to include context) so users don't see raw
backend/runtime exception text.
In `@admin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsx`:
- Around line 61-64: The logger.error call inside SsaAddPage (the logger.error
invocation that currently includes the stray 'dev' argument) should be updated
to remove the first 'dev' parameter so it follows the migrated logger pattern;
leave the message string "Failed to submit SSA form:" and the error payload
(error instanceof Error ? error : String(error)) as the remaining arguments so
the log call becomes logger.error(<message>, <errorPayload>) in the
SsaAddPage.tsx submit/submit handler.
In `@admin-ui/plugins/scripts/components/CustomScriptListPage.tsx`:
- Around line 139-143: The deletion failure is being logged to the 'dev'
audience which hides it from production; in the CustomScriptListPage where the
deletion error is handled (the logger.error call inside the delete handler),
remove the 'dev' audience argument (or replace it with the standard error
channel) so the call uses the default/error path (e.g., logger.error('Failed to
delete custom script:', err instanceof Error ? err : String(err))) ensuring
production visibility.
In `@admin-ui/plugins/scripts/components/helper/auditUtils.ts`:
- Around line 20-23: The audit failure is being logged to the 'dev' audience,
which hides it in production; update the logger.error call (the one that
currently passes 'dev' and uses actionType and error) to use a
production-visible audience such as 'both' or 'prod' per the logger contract so
audit logging failures are emitted to operational channels; keep the existing
message and error formatting (actionType and error instanceof Error ? error :
String(error)) but replace the first argument 'dev' with the appropriate
production-visible audience.
In `@admin-ui/plugins/services/Components/hooks/useCacheAudit.ts`:
- Around line 31-34: In useCacheAudit.ts within the useCacheAudit hook, the
logger.error call currently passes the literal 'dev' as the first argument which
prevents the audit-failure from appearing in production; remove the 'dev'
environment tag (or replace it with a neutral/contextual tag such as
'cache-audit' or no tag) so logger.error(...) is invoked unconditionally with
the error details (preserving the existing message and error instanceof Error ?
error : String(error) expression) to ensure production visibility.
In `@admin-ui/plugins/user-management/components/PasswordChangeModal.tsx`:
- Around line 141-145: The catch block in PasswordChangeModal.tsx currently logs
all failures with logger.error even though a 404 "no active session" is
expected; update the catch to check the error response/status (e.g., (error as
any).response?.status === 404 or inspect the error type) and suppress or log it
at info/debug level for 404s while keeping logger.error for other
statuses/unknown errors so only real failures are surfaced.
In `@admin-ui/plugins/user-management/components/UserEditPage.tsx`:
- Around line 125-129: The logger.error call in UserEditPage.tsx that handles
session revocation (the logger.error call passing the literal 'dev') is
incorrectly scoped to development; remove the 'dev' environment tag and log the
full error unconditionally so production diagnostics see it—replace the current
call in the revoke-session error handler with a single logger.error invocation
that includes a clear message ("Failed to revoke user session:") and the error
details (err instanceof Error ? err : String(err)) so the failure surfaces in
production logs.
---
Outside diff comments:
In
`@admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx`:
- Around line 177-181: The logger.error calls in SessionListPage (referencing
sessionId, item.sessionAttributes?.auth_user, and err) are emitting raw
sensitive data; remove auth_user from the payload and avoid passing the raw err
object. Update both logger.error usages to only include non-sensitive
identifiers (e.g., sessionId or a masked user id) and include minimal error
details such as err.name and err.message (or a sanitized error code), not the
full err object or raw user attributes; ensure any masking function (e.g.,
maskUserId) is applied to user identifiers before logging and replace the err
field with err.message/err.name.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a82b9861-1fd3-4e20-a60f-adcabce66584
📒 Files selected for processing (102)
admin-ui/app/cedarling/hooks/useCedarling.tsadmin-ui/app/components/App/PermissionsPolicyInitializer.tsxadmin-ui/app/components/Wizard/Wizard.tsxadmin-ui/app/context/theme/themeContext.tsxadmin-ui/app/i18n.tsadmin-ui/app/layout/default.tsxadmin-ui/app/redux/api/backend-api.tsadmin-ui/app/redux/listeners/authListener.tsadmin-ui/app/redux/listeners/licenseListener.tsadmin-ui/app/redux/listeners/sessionListener.tsadmin-ui/app/routes/Apps/Gluu/GluuAppSidebar.tsxadmin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsxadmin-ui/app/routes/Apps/Gluu/GluuScriptErrorModal.tsxadmin-ui/app/routes/Apps/Gluu/GluuSessionTimeout.tsxadmin-ui/app/routes/Apps/Gluu/ThemeDropdown.tsxadmin-ui/app/routes/Apps/Profile/hooks/useProfileDetails.tsadmin-ui/app/routes/License/hooks/useLicenseDetails.tsadmin-ui/app/routes/Pages/ByeBye.tsxadmin-ui/app/routes/index.tsxadmin-ui/app/utils/AppAuthProvider.tsxadmin-ui/app/utils/apiErrorMessage.tsadmin-ui/app/utils/devLogger.tsadmin-ui/app/utils/logLevel.tsadmin-ui/app/utils/logger.tsadmin-ui/app/utils/menuFilters.tsadmin-ui/app/utils/pagingUtils.tsadmin-ui/app/utils/storage.tsadmin-ui/app/utils/triggerWebhookForFeature.tsadmin-ui/app/utils/types/LoggerTypes.tsadmin-ui/app/utils/types/index.tsadmin-ui/orval/__tests__/interceptors.test.tsadmin-ui/orval/interceptors.tsadmin-ui/plugins/PluginMenuResolver.tsadmin-ui/plugins/admin/components/Assets/JansAssetListPage.tsxadmin-ui/plugins/admin/components/Assets/hooks/useAssetAudit.tsadmin-ui/plugins/admin/components/Assets/hooks/useAssetMutations.tsadmin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsxadmin-ui/plugins/admin/components/Settings/SettingsPage.tsxadmin-ui/plugins/admin/components/Webhook/WebhookForm.tsxadmin-ui/plugins/admin/components/Webhook/WebhookListPage.tsxadmin-ui/plugins/admin/components/Webhook/hooks/useWebhookAudit.tsadmin-ui/plugins/admin/components/Webhook/hooks/useWebhookMutations.tsadmin-ui/plugins/auth-server/__tests__/api/setup.tsadmin-ui/plugins/auth-server/components/AuthServerProperties/components/AuthServerPropertiesPage.tsxadmin-ui/plugins/auth-server/components/AuthServerProperties/hooks/useAuthServerScripts.tsadmin-ui/plugins/auth-server/components/Authentication/Acrs/AcrsEditPage.tsxadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsxadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsxadmin-ui/plugins/auth-server/components/Authentication/Aliases/Aliases.tsxadmin-ui/plugins/auth-server/components/Authentication/DefaultAcr/DefaultAcr.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/components/ConfigApiPropertiesForm.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/components/ConfigApiPropertiesPage.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/utils/valueUtils.tsadmin-ui/plugins/auth-server/components/JsonViewer/components/JsonViewerDialog.tsxadmin-ui/plugins/auth-server/components/Keys/hooks/useJwkApi.tsadmin-ui/plugins/auth-server/components/Logging/components/LoggingPage.tsxadmin-ui/plugins/auth-server/components/Logging/hooks/useLoggingApi.tsadmin-ui/plugins/auth-server/components/OidcClients/__tests__/hooks/useClientUmaResources.test.tsadmin-ui/plugins/auth-server/components/OidcClients/components/ClientAddPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientEditPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientListPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/helper/utils.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useClientTokens.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useClientUmaResources.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useCreateClient.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useDeleteClient.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useUpdateClient.tsadmin-ui/plugins/auth-server/components/Scopes/components/ScopeAddPage.tsxadmin-ui/plugins/auth-server/components/Scopes/components/ScopeEditPage.tsxadmin-ui/plugins/auth-server/components/Scopes/components/ScopeListPage.tsxadmin-ui/plugins/auth-server/components/Scopes/hooks/useScopeMutations.tsadmin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsxadmin-ui/plugins/auth-server/components/Sessions/hooks/useSessionMutations.tsadmin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsxadmin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsxadmin-ui/plugins/auth-server/components/Ssa/helper/utils.tsadmin-ui/plugins/auth-server/components/Ssa/hooks/useSsaApi.tsadmin-ui/plugins/auth-server/components/Ssa/hooks/useSsaMutations.tsadmin-ui/plugins/auth-server/services/jsonPropertiesService.tsadmin-ui/plugins/auth-server/utils/sessionExpiredRedirect.tsadmin-ui/plugins/fido/hooks/useFidoApi.tsadmin-ui/plugins/internal/loadPluginMetadata.tsadmin-ui/plugins/saml/components/WebsiteSsoIdentityBrokeringList.tsxadmin-ui/plugins/saml/components/WebsiteSsoServiceProviderList.tsxadmin-ui/plugins/saml/components/hooks/useSamlApi.tsadmin-ui/plugins/scripts/components/CustomScriptListPage.tsxadmin-ui/plugins/scripts/components/helper/auditUtils.tsadmin-ui/plugins/scripts/components/hooks/useCustomScriptApi.tsadmin-ui/plugins/services/Components/CachePage.tsxadmin-ui/plugins/services/Components/hooks/useCacheAudit.tsadmin-ui/plugins/smtp/components/SmtpEditPage.tsxadmin-ui/plugins/user-claims/components/UserClaimsListPage.tsxadmin-ui/plugins/user-claims/hooks/useAttributeApi.tsadmin-ui/plugins/user-claims/hooks/useSchemaAuditLogger.tsadmin-ui/plugins/user-claims/hooks/useSchemaWebhook.tsadmin-ui/plugins/user-management/__tests__/api/Users.test.tsadmin-ui/plugins/user-management/components/PasswordChangeModal.tsxadmin-ui/plugins/user-management/components/UserEditPage.tsxadmin-ui/plugins/user-management/components/UserList.tsxadmin-ui/plugins/user-management/helper/utils.tsadmin-ui/plugins/user-management/hooks/useUserMutations.ts
💤 Files with no reviewable changes (1)
- admin-ui/app/utils/devLogger.ts
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@admin-ui/plugins/scripts/components/CustomScriptListPage.tsx`:
- Around line 139-142: Replace the use of raw exception text in the user toast:
keep the detailed log with logger.error('Failed to delete custom script:', err
instanceof Error ? err : String(err)) but change the value passed to
dispatch(updateToast(...)) so it always uses a fixed/localized safe message
(e.g. t('messages.error_deleting_script')) rather than err.message; update the
errorMessage assignment or inline argument used in dispatch(updateToast(true,
'error', ...)) to remove any err-derived content.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 05e15427-6d49-4bf2-9300-aeeaea784a85
📒 Files selected for processing (16)
admin-ui/app/cedarling/hooks/useCedarling.tsadmin-ui/app/routes/Apps/Gluu/GluuAppSidebar.tsxadmin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsxadmin-ui/app/utils/triggerWebhookForFeature.tsadmin-ui/orval/interceptors.tsadmin-ui/plugins/admin/components/Assets/hooks/useAssetMutations.tsadmin-ui/plugins/auth-server/components/AuthServerProperties/hooks/useAuthServerScripts.tsadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/components/ConfigApiPropertiesForm.tsxadmin-ui/plugins/auth-server/components/JsonViewer/components/JsonViewerDialog.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsxadmin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsxadmin-ui/plugins/scripts/components/CustomScriptListPage.tsxadmin-ui/plugins/scripts/components/helper/auditUtils.tsadmin-ui/plugins/services/Components/hooks/useCacheAudit.tsadmin-ui/plugins/user-management/components/UserEditPage.tsx
💤 Files with no reviewable changes (7)
- admin-ui/app/utils/triggerWebhookForFeature.ts
- admin-ui/app/cedarling/hooks/useCedarling.ts
- admin-ui/plugins/services/Components/hooks/useCacheAudit.ts
- admin-ui/plugins/scripts/components/helper/auditUtils.ts
- admin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsx
- admin-ui/plugins/auth-server/components/AuthServerProperties/hooks/useAuthServerScripts.ts
- admin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsx
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 30
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (8)
admin-ui/plugins/user-claims/hooks/useSchemaAuditLogger.ts (1)
30-35: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse
logger.error()for audit logging failures.Audit logging failures are operational diagnostics that should be visible in production. Use
logger.error(...)instead oflogger(...)to ensure proper error-level categorization and production console visibility.Suggested fix
} catch (error) { - logger( + logger.error( '[useSchemaAuditLogger] Failed to log audit action:', error instanceof Error ? error : String(error), )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/user-claims/hooks/useSchemaAuditLogger.ts` around lines 30 - 35, In the catch block inside useSchemaAuditLogger (the handler that logs audit actions), replace the generic logger(...) call with logger.error(...) so failures are emitted at error level; update the call that currently passes '[useSchemaAuditLogger] Failed to log audit action:' and the error payload (error instanceof Error ? error : String(error)) to be passed to logger.error(...) instead to ensure production/error-level visibility.admin-ui/plugins/saml/components/hooks/useSamlApi.ts (1)
142-147: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse
logger.error()for audit logging failures.Audit logging failures are operational diagnostics that should be visible in production. Use
logger.error(...)instead oflogger(...)to ensure proper error-level categorization and production console visibility.Suggested fix
} catch (error) { - logger( + logger.error( `Failed to log ${resource} audit action:`, error instanceof Error ? error : String(error), )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/saml/components/hooks/useSamlApi.ts` around lines 142 - 147, Replace the generic logger call in the catch block of useSamlApi.ts with an error-level call so audit logging failures are surfaced; specifically, in the catch where logger(`Failed to log ${resource} audit action:`, ...) is invoked, call logger.error(...) instead and pass the same message and error argument (keeping the error instanceof Error ? error : String(error) logic intact).admin-ui/plugins/saml/components/WebsiteSsoIdentityBrokeringList.tsx (1)
134-139: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse
logger.error()for deletion failures.Identity provider deletion failures are operational errors that should be visible in production. Use
logger.error(...)instead oflogger(...)to ensure proper error-level categorization and production diagnostics.Suggested fix
} catch (error) { - logger( + logger.error( 'Failed to delete identity provider:', error instanceof Error ? error : String(error), )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/saml/components/WebsiteSsoIdentityBrokeringList.tsx` around lines 134 - 139, In the catch block that handles identity provider deletion failures in WebsiteSsoIdentityBrokeringList (the catch after the delete flow—likely inside the deleteIdentityProvider/onDelete handler), replace the generic logger(...) call with logger.error(...), preserving the existing error formatting (error instanceof Error ? error : String(error)) and message text so failures are logged at error level for production monitoring.admin-ui/plugins/user-management/components/UserEditPage.tsx (1)
123-129:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winExpected 404s logged unconditionally create diagnostic noise.
The logger call at line 125 executes for every session revocation failure (including expected 404 "no active session" responses), while the user-facing toast is conditionally suppressed for 404s at lines 126-128. This inconsistency generates false-positive failure logs in production diagnostics.
🔧 Suggested fix
Align logging with the toast behavior to suppress expected 404s:
} catch (err) { const status = (err as { response?: { status?: number } }).response?.status - logger('Failed to revoke user session:', err instanceof Error ? err : String(err)) if (status !== 404) { + logger('Failed to revoke user session:', err instanceof Error ? err : String(err)) dispatch(updateToast(true, 'error', t('messages.session_revoke_failed'))) } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/user-management/components/UserEditPage.tsx` around lines 123 - 129, The logger call in the catch of the session revoke flow logs all errors (logger in UserEditPage.tsx) including expected 404s; change the catch to inspect status = (err as { response?: { status?: number } }).response?.status and only call logger(...) when status !== 404, keeping the current dispatch(updateToast(...)) behavior (i.e., suppress both toast and log for 404s) so diagnostics don't record expected "no active session" responses; ensure you still log full error details for non-404 failures.admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx (2)
206-210:⚠️ Potential issue | 🟠 MajorMask
userDn/auth_userin production logs
userDnis generally considered PII/personal data (e.g., under GDPR and similar privacy frameworks), and this code logs it directly inlogger('Failed to revoke session', ...)alongsideauth_user. Avoid emitting these identifiers to production logs—omit them or replace with a correlation ID (or a one-way hash) while still retaining enough context to troubleshoot.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx` around lines 206 - 210, The log call in SessionListPage.tsx is emitting PII: replace direct logging of userDn and item.sessionAttributes?.auth_user in the logger('Failed to revoke session', ...) call with a non-identifying value (e.g., omit them in production or substitute a correlation ID or one-way hash derived from userDn/auth_user) so logs retain troubleshooting context without raw PII; update the logging site (the logger invocation) to compute and pass the maskedId/correlationId instead of the plain userDn/auth_user and ensure any helper used for hashing/masking is deterministic and documented.
177-181:⚠️ Potential issue | 🟠 MajorMask/pseudonymize usernames in production log context.
In
admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx(lines 177-181), the error log includesauth_user(username) in the structured metadata. Usernames are personal data under GDPR, so apply data minimization by masking/pseudonymizing the value (or use a non-PII correlation/user id) before logging.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx` around lines 177 - 181, The logger call currently includes raw username via item.sessionAttributes?.auth_user; change this to log a pseudonymized value instead (e.g., compute a deterministic hash of auth_user or mask it like first char + redaction) and pass that masked/hash into the logger metadata (keep sessionId as-is); update the code around the existing logger(...) call in SessionListPage (the invocation that currently logs sessionId and auth_user) to replace auth_user with the pseudonymized value or, if a non-PII user identifier is available (e.g., user_id), log that instead.admin-ui/plugins/auth-server/components/Ssa/hooks/useSsaMutations.ts (1)
41-45:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid logging raw Error objects that may contain sensitive stack traces.
All three logger calls pass raw Error objects when the
instanceofcheck succeeds. Use.messageproperty to log only safe message strings while still preserving the{ jti }context.🔒 Proposed fix
logger( 'Audit logging failed:', - auditError instanceof Error ? auditError : String(auditError), + auditError instanceof Error ? auditError.message : String(auditError), { jti }, )logger( 'Query invalidation failed after delete:', - invalidateError instanceof Error ? invalidateError : String(invalidateError), + invalidateError instanceof Error ? invalidateError.message : String(invalidateError), { jti }, )logger( 'Post-delete callback failed:', - callbackError instanceof Error ? callbackError : String(callbackError), + callbackError instanceof Error ? callbackError.message : String(callbackError), { jti }, )Also applies to: 52-56, 63-67
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Ssa/hooks/useSsaMutations.ts` around lines 41 - 45, The logger calls in useSsaMutations are passing raw Error objects (auditError) which may include sensitive stacks; change each logging invocation (the logger(...) calls that reference auditError and jti) to log auditError.message (or String(auditError) fallback) instead of the Error object itself, preserving the { jti } context; update all occurrences that currently use auditError instanceof Error ? auditError : String(auditError) (including the similar blocks later) to use auditError instanceof Error ? auditError.message : String(auditError).admin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsx (1)
153-160:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFire-and-forget UMA deletion provides no user feedback on failure.
The
deleteUmaResourcecall on line 155 uses.catch()to log errors but does not notify the user of failure. The modal closes immediately (line 158), giving the impression that deletion succeeded even when it fails. Compare withClientListPage(lines 224–238), whichawaits the delete operation and handles errors with proper user feedback.🔧 Proposed fix to await deletion and add toast feedback
+import { useAppDispatch } from '`@/redux/hooks`' +import { updateToast } from 'Redux/features/toastSlice' + const ClientCibaParUmaPanel = ({...}: ClientCibaParUmaPanelProps) => { const { t } = useTranslation() + const dispatch = useAppDispatch() ... - const onDeletionConfirmed = (_message: string) => { + const onDeletionConfirmed = async (_message: string) => { if (!selectedUMA?.id) return - deleteUmaResource(String(selectedUMA.id)).catch((error) => { - logger('UMA resource deletion failed:', error) - }) - setConfirmModal(false) - setOpen(false) + try { + await deleteUmaResource(String(selectedUMA.id)) + dispatch(updateToast(true, 'success')) + } catch (error) { + const errorMsg = error instanceof Error ? error.message : t('messages.error_in_deleting') + dispatch(updateToast(true, 'error', errorMsg)) + logger('UMA resource deletion failed:', error instanceof Error ? error : String(error)) + } finally { + setConfirmModal(false) + setOpen(false) + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsx` around lines 153 - 160, Make onDeletionConfirmed async and await deleteUmaResource inside a try/catch: call await deleteUmaResource(String(selectedUMA.id)) in onDeletionConfirmed, and on success call setConfirmModal(false) and setOpen(false) and show a success toast; on failure log the error (logger(...)) and show an error toast (do NOT close the modal so the user sees the failure). Update the onDeletionConfirmed function signature and use try/catch to provide user feedback instead of the current fire-and-forget .catch() approach.
♻️ Duplicate comments (3)
admin-ui/plugins/scripts/components/CustomScriptListPage.tsx (1)
138-141: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse
logger.error()for deletion failures.Custom script deletion failures are operational errors that should be visible in production. Use
logger.error(...)instead oflogger(...)to ensure proper error-level categorization and production diagnostics.Note: The toast message correctly uses a localized fixed string rather than raw error details, aligning with the PR's guardrails.
Suggested fix
} catch (err) { - logger('Failed to delete custom script:', err instanceof Error ? err : String(err)) + logger.error('Failed to delete custom script:', err instanceof Error ? err : String(err)) dispatch(updateToast(true, 'error', t('messages.error_deleting_script'))) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/scripts/components/CustomScriptListPage.tsx` around lines 138 - 141, Replace the generic logger call in the custom script deletion catch block with an error-level log; specifically change the call to logger(...) in the catch inside CustomScriptListPage (the deletion handler where you currently call logger('Failed to delete custom script:', err instanceof Error ? err : String(err))) to logger.error(...) keeping the same message and err formatting, and leave the dispatch(updateToast(...)) and localization (t('messages.error_deleting_script')) unchanged.admin-ui/plugins/user-management/components/PasswordChangeModal.tsx (1)
141-145:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winExpected 404s logged as failures create diagnostic noise.
The inline comment states "log other failures" (implying 404s are excluded), but the
loggercall executes unconditionally for every caught error, including expected 404 "no active session" responses. This generates false-positive failure logs in production diagnostics.🔧 Suggested fix
Option 1: Suppress expected 404s from logs to match the comment intent:
} catch (error) { + const status = (error as { response?: { status?: number } })?.response?.status // A 404 is expected (the user has no active session); log other failures // for diagnosis without surfacing them to the user. - logger('Failed to revoke user session after password change:', error as Error) + if (status !== 404) { + logger( + 'Failed to revoke user session after password change:', + error instanceof Error ? error : String(error), + ) + } }Option 2: Update the comment to reflect that all errors are logged:
} catch (error) { - // A 404 is expected (the user has no active session); log other failures - // for diagnosis without surfacing them to the user. + // A 404 is expected when no active session exists. All revocation failures + // (including expected 404s) are logged for production diagnostics. logger('Failed to revoke user session after password change:', error as Error) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/user-management/components/PasswordChangeModal.tsx` around lines 141 - 145, The catch in PasswordChangeModal that calls logger('Failed to revoke user session after password change:', error as Error) logs expected 404s; change it to only log unexpected errors by detecting a 404 and ignoring it (e.g., guard using (error as any).response?.status === 404 or an axios/isFetch-specific check) and otherwise call logger with the error; update the comment to reflect that 404s are intentionally suppressed.admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsx (1)
377-377:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSanitize error event before logging.
The
reader.onerrorcallback receives aProgressEvent<FileReader>, not a plain string. Logging the raw event object may expose internal browser state or file paths. Cast to a safe string or extracterror.typeto avoid leaking unnecessary details.🔒 Proposed fix
- reader.onerror = (error) => { - logger('Error reading SHA256 file:', error) + reader.onerror = (event) => { + logger('Error reading SHA256 file:', event.type || 'FileReader error') toast.error('Failed to read SHA256 file') }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsx` at line 377, The onerror handler for the FileReader (reader.onerror) is logging the raw ProgressEvent via logger('Error reading SHA256 file:', error); update the handler to sanitize the event before logging by extracting safe fields (e.g., reader.error?.name or reader.error?.message or event.type) or converting to a safe string summary instead of dumping the whole event object; change the logger call in AgamaFlows.tsx (the reader.onerror callback) to log a concise, non-sensitive string such as "Error reading SHA256 file: <error-type-or-message>" rather than the raw event.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@admin-ui/app/cedarling/client/CedarlingClient.ts`:
- Line 46: Replace the console.log call in CedarlingClient's token_authorize
path with the unified logger used elsewhere in the file: locate the
token_authorize handler inside the CedarlingClient class and change the
console.log invocation to the same logger method used for the earlier
operational diagnostic (use the same logger level/method as the other log in
this file) so the message goes through the shared logging infrastructure.
In `@admin-ui/app/cedarling/hooks/useCedarling.ts`:
- Around line 98-100: Replace the console.log diagnostic statements inside the
useCedarling hook with the shared logger so messages go through the unified
logging infra; locate the console.log calls that print messages like `Cedarling
authorization skipped for "${resolvedResourceId}" (...)` (and the two other
similar console.log blocks) and change them to use the existing logger (e.g.,
logger.debug(...) or logger.info(...)) preserving the original interpolated
message text and context; ensure the logger import/instance already used
elsewhere in this file (the logger call around line ~161) is reused so no new
logging setup is added.
In `@admin-ui/app/components/App/PermissionsPolicyInitializer.tsx`:
- Line 63: Remove the unnecessary type cast in the logger call: replace the call
that logs "Cedarling: failed to decode policy store bytes." which currently uses
"error as LogArg" so that it simply passes the caught error directly to logger
(i.e., logger('Cedarling: failed to decode policy store bytes.', error)). Locate
the statement in PermissionsPolicyInitializer.tsx where logger(...) is invoked
with the caught variable named error and remove the "as LogArg" cast so the
Error/unknown is passed naturally.
- Line 76: Replace the stray console.log in the PermissionsPolicyInitializer
success path with the project's logger (e.g., call logger.info('Cedarling
initialize SUCCEEDED')) so the success message uses the same logging facility as
the error paths; ensure you use the existing logger instance imported/used in
this file (the same one referenced by the error logs in this component) rather
than adding a new console call.
In `@admin-ui/app/context/theme/themeContext.tsx`:
- Line 144: The logger call currently just logs the bare error (logger(error
instanceof Error ? error : String(error))); update it to include a descriptive
message about what failed (e.g., "Failed to load/apply theme" or similar) and
include the error details, using the same error expression (error instanceof
Error ? error : String(error)) so the log matches the other catch blocks and
provides context; modify the logger invocation in the themeContext catch block
(the logger call and surrounding catch handler) to prepend that message.
In `@admin-ui/app/redux/listeners/authListener.ts`:
- Line 170: The current call to logger('Failed to obtain API token for session
creation') omits the actual error; update the catch/failed branch where logger
is invoked to include the error details (e.g., logger('Failed to obtain API
token for session creation', err) or logger.error(..., { error:
serializeError(err) })), referencing the same listener code path in
authListener.ts and the existing logger function; ensure you use the actual
error variable from the surrounding catch (commonly named err or e) and
sanitize/serialize it if needed before logging.
- Line 135: Replace unsafe direct logging of err?.response?.data in
authListener.ts by extracting and logging a redacted, safe message: import and
use resolveApiErrorMessage(err) (and optionally err?.response?.status) instead
of passing the full response.data to logger. Update the logger calls around the
existing logger(...) invocations (the calls shown and the other occurrences in
the same file) to call logger('Problems getting OAuth2 configuration.',
resolveApiErrorMessage(err), { status: err?.response?.status }) or similar so
only the safe message and status code are logged, not the raw response data.
In `@admin-ui/app/redux/listeners/licenseListener.ts`:
- Line 95: Replace bare logger(err instanceof Error ? err : String(err)) calls
in admin-ui/app/redux/listeners/licenseListener.ts with contextual error logs:
include a descriptive message plus the error (e.g., logger('Error checking MAU
threshold', err)), logger('Error uploading SSA token', err), and logger('Error
checking license config', err) at the three locations handling MAU threshold
check, SSA token upload, and license config check so each log provides immediate
diagnostic context; preserve existing error value logic (err instanceof Error ?
err : String(err)) when passing the error argument.
In `@admin-ui/app/routes/Apps/Gluu/GluuSessionTimeout.tsx`:
- Line 57: The logger call in the handleLogout error path currently logs only
the error object (logger(err...)); update it to include a descriptive context
message such as "Error in logout flow:" so the log reads a combined message and
error details; locate the handleLogout function and the logger call and change
the logger invocation to prepend that context (ensuring you still serialize
non-Error values as before).
In `@admin-ui/app/routes/License/hooks/useLicenseDetails.ts`:
- Around line 88-90: Remove the isDevelopment gating around the logger calls in
useLicenseDetails (the block that currently logs "License reset audit post
failed:" and the similar logger at lines 104-106); instead always call
logger(...) so production diagnostic errors are emitted (the shared logger
utility will handle audience-based gating). Locate the error-handling branches
in the useLicenseDetails hook where e is logged (the two places wrapped by
isDevelopment) and delete the isDevelopment conditionals so the logger
invocation runs unconditionally, preserving the existing error formatting (e
instanceof Error ? e : String(e)).
In `@admin-ui/orval/__tests__/interceptors.test.ts`:
- Around line 17-24: The mock for logger currently returns an object with
methods but the real export is a plain function (logger), so replace the mock
implementation to export logger as a jest.fn() (i.e., jest.mock(...) => ({
logger: jest.fn() })) and then update any test usages that call logger.log /
logger.error / logger.warn / logger.debug to call the function directly (or
assert against logger.mock.calls); ensure references to the unique symbol logger
in interceptors.test.ts are updated accordingly so tests use the function
signature rather than object methods.
In `@admin-ui/plugins/auth-server/__tests__/api/setup.ts`:
- Line 27: Replace the direct console.log call in the test setup that prints
"Issuer and token already available." with the project logger so it follows the
migrated logging pattern; locate the console.log usage in
admin-ui/plugins/auth-server/__tests__/api/setup.ts (the statement that logs
"Issuer and token already available.") and change it to use the shared logger
API (e.g., logger or logger.debug/log) consistent with other migrated calls.
In
`@admin-ui/plugins/auth-server/components/Authentication/Acrs/AcrsEditPage.tsx`:
- Line 238: The logger call in AcrsEditPage.tsx that currently passes the raw
error object to logger (logger('Unexpected error during form submission:',
error)) may leak sensitive request metadata; update the form submission error
handling in the submit handler (the block where logger is called) to log a
sanitized string instead—use error.message or the existing
resolveApiErrorMessage(error) helper to extract a safe message and pass that to
logger along with any non-sensitive context.
In
`@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsx`:
- Line 118: Replace raw error object logging in AgamaProjectConfigModal (calls
to logger with the imported error/importError) with a sanitized message — use
resolveApiErrorMessage(error) or error.message instead of passing the full error
object; update both occurrences where logger('Error importing config:', error)
and similar importError logging is used so only the resolved string is logged
(import resolveApiErrorMessage if not already imported).
- Line 210: The current logger call in AgamaProjectConfigModal (logger('Error
saving file:', e instanceof Error ? e : String(e))) logs raw Error objects
including stack traces; change it to log only the safe message by using e
instanceof Error ? e.message : String(e) (i.e., replace the ternary to use
e.message when e is an Error) so the save/error handler only emits the error
string and not sensitive stack information.
- Line 143: The logger call in AgamaProjectConfigModal's clipboard error handler
logs the raw Error object (logger('Failed to copy to clipboard:', error
instanceof Error ? error : String(error))) which can expose stack traces; change
it to log only the safe error message by using error instanceof Error ?
error.message : String(error) (keep the same logger call and message text) so
only the error string is emitted rather than the full Error object.
In
`@admin-ui/plugins/auth-server/components/JsonViewer/components/JsonViewerDialog.tsx`:
- Line 102: The current logger call in JsonViewerDialog (logger('Failed to copy
to clipboard:', err instanceof Error ? err : String(err))) may log full Error
objects and stack traces; change it to log only the safe error message by using
err instanceof Error ? err.message : String(err) so the logger call passes a
plain message string instead of the raw Error object. Locate the call site in
the JsonViewerDialog component and replace the second argument accordingly to
avoid exposing sensitive stack traces.
In `@admin-ui/plugins/auth-server/components/Keys/hooks/useJwkApi.ts`:
- Line 22: In useJwkApi.ts inside the useJwkApi hook replace the call to logger
that currently uses stringifyError(error) with the defensive pattern used
elsewhere: pass the raw error as error instanceof Error ? error : String(error)
so the stack trace is preserved (keep using stringifyError only where a plain
string is required, e.g., when constructing a normalized Error for the hook’s
error path).
In
`@admin-ui/plugins/auth-server/components/OidcClients/components/ClientAddPage.tsx`:
- Around line 40-42: The catch block in ClientAddPage swallows errors after
logging (logger('Failed to create client:', ...)); update it to mirror
useUpdateClient by dispatching a toast with updateToast(true, 'error', errorMsg)
where errorMsg is derived from the caught error (Error.message or String(error))
and then rethrow the error so callers/submit handlers can handle it; locate the
catch inside the createClient/mutation call in the ClientAddPage component and
ensure you call the same toast semantics and then throw error to propagate.
In
`@admin-ui/plugins/auth-server/components/OidcClients/components/ClientEditPage.tsx`:
- Around line 59-61: The catch in ClientEditPage.tsx that currently only calls
logger('Failed to update client:', ...) should instead dispatch the same error
toast and rethrow the error so the UI shows feedback and upstream handlers can
react; follow the pattern used in useUpdateClient (dispatch an error toast with
the caught error) and then rethrow, matching the behavior from
ClientAddPage.tsx's error handling. Ensure you reference the same toast-dispatch
utility used elsewhere (the dispatchErrorToast or equivalent) and keep the
existing logger call before rethrowing.
In
`@admin-ui/plugins/auth-server/components/OidcClients/components/ClientListPage.tsx`:
- Around line 233-235: The catch block around deleteClient currently only logs
the error (logger('Failed to delete client', ...)) and then the finally block
closes the modal, swallowing the failure; update the catch to dispatch an error
toast (using the same toast/error dispatch pattern used by the useDeleteClient
hook in other components) with a clear message (e.g., "Failed to delete client")
and the error details, and then rethrow or return early so the modal closing in
the finally block does not give the appearance of success; locate the try/catch
surrounding deleteClient and replace the catch body to call the toast/error
handler before allowing the function to proceed.
In `@admin-ui/plugins/auth-server/components/OidcClients/helper/utils.ts`:
- Around line 174-175: The catch block in utils.ts uses an unsafe cast "error as
Error" when logging; update the catch to perform a type-safe check: in the
catch, test "if (error instanceof Error)" and call logger('Failed to download
client tokens CSV:', error) in that branch, otherwise call logger('Failed to
download client tokens CSV:', String(error)) as a fallback; locate the catch
around the download CSV logic in the helper/utils.ts file to apply this change.
In
`@admin-ui/plugins/auth-server/components/OidcClients/hooks/useCreateClient.ts`:
- Around line 51-54: The audit-failure logging currently passes the raw Error
object to logger in useCreateClient.ts (logger(..., auditError instanceof Error
? auditError : String(auditError))) which can leak stack traces/PII; change it
to log a sanitized string instead—use resolveApiErrorMessage(auditError as
Error) or auditError.message when auditError is an Error (falling back to
String(auditError)), and pass that string to logger so only a safe message is
logged (update the logger call in the useCreateClient hook where auditError is
handled).
In `@admin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsx`:
- Line 61: The logger call in SsaAddPage.tsx currently logs the raw Error object
which may include sensitive stack traces; update the logger invocation inside
the SSA form submission error handling (the line starting with logger('Failed to
submit SSA form:', ...)) to log only a safe string by using error.message when
error is an Error or by calling resolveApiErrorMessage(error) (or always using
resolveApiErrorMessage) so only non-sensitive text is logged.
In `@admin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsx`:
- Line 138: The logger call in SsaListPage currently logs raw Error objects
(logger('Failed to download SSA JWT:', error ...)), which can expose
stacks/headers; update both occurrences to log only a safe message string by
calling resolveApiErrorMessage(error) (fallback to error.message or
String(error) if needed) and pass that single string to logger (e.g.,
logger('Failed to download SSA JWT: ' + resolveApiErrorMessage(error))). Locate
the logger usages in the SsaListPage component (where download SSA errors are
caught) and replace the raw error logging with the safe-message approach using
resolveApiErrorMessage and a clear contextual prefix.
- Line 126: The current log call logs the entire Axios error object
(ssaJwtQuery.error) which can expose sensitive request metadata; update the
logging in SsaListPage (where logger is called) to only log a safe error message
by extracting error?.message or using a small helper like
getErrorMessage(ssaJwtQuery.error) and pass that string to logger('Failed to
fetch SSA JWT:', message) instead of the full error object.
In `@admin-ui/plugins/auth-server/components/Ssa/helper/utils.ts`:
- Line 33: The logger call in utils.ts currently logs raw Error objects
(logger('Failed to log SSA creation:', error instanceof Error ? error :
String(error))) which may include sensitive stacks; change both occurrences (the
one at the shown line and the similar call around line 54) to only log the error
message when error instanceof Error (use error.message) and otherwise
String(error), i.e. replace the conditional to error instanceof Error ?
error.message : String(error) so only safe message text is emitted.
In `@admin-ui/plugins/fido/hooks/useFidoApi.ts`:
- Around line 104-106: In the catch handler inside the useFidoApi hook where
audit logging failures are currently logged with logger('Audit logging failed:',
auditError), change the call to logger.error('Audit logging failed:',
auditError) so the failure is emitted at error severity; also confirm the logger
used by useFidoApi supports an error method (update the import/type if
necessary).
In `@admin-ui/plugins/saml/components/WebsiteSsoServiceProviderList.tsx`:
- Around line 95-97: The catch block in WebsiteSsoServiceProviderList.tsx logs
deletion failures with logger(...) which doesn't set an error level; update the
catch to call logger.error(...) instead (i.e., replace the logger(...)
invocation inside the catch for the service provider delete flow) so deletion
failures are logged at error level and visible in production diagnostics.
In `@admin-ui/plugins/user-claims/hooks/useAttributeApi.ts`:
- Around line 105-107: The mutation error handlers in useAttributeApi.ts
currently call logger(...) which logs at the wrong level; update the catch
handlers for the create, update, and delete attribute mutations (the
mutateAsync(...).catch(...) blocks used inside the createAttribute,
updateAttribute, and deleteAttribute flows) to call logger.error(...) and adjust
the inline comments to reflect these are production-visible error logs rather
than dev breadcrumbs so failures are recorded at error level for production
diagnostics.
---
Outside diff comments:
In
`@admin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsx`:
- Around line 153-160: Make onDeletionConfirmed async and await
deleteUmaResource inside a try/catch: call await
deleteUmaResource(String(selectedUMA.id)) in onDeletionConfirmed, and on success
call setConfirmModal(false) and setOpen(false) and show a success toast; on
failure log the error (logger(...)) and show an error toast (do NOT close the
modal so the user sees the failure). Update the onDeletionConfirmed function
signature and use try/catch to provide user feedback instead of the current
fire-and-forget .catch() approach.
In
`@admin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsx`:
- Around line 206-210: The log call in SessionListPage.tsx is emitting PII:
replace direct logging of userDn and item.sessionAttributes?.auth_user in the
logger('Failed to revoke session', ...) call with a non-identifying value (e.g.,
omit them in production or substitute a correlation ID or one-way hash derived
from userDn/auth_user) so logs retain troubleshooting context without raw PII;
update the logging site (the logger invocation) to compute and pass the
maskedId/correlationId instead of the plain userDn/auth_user and ensure any
helper used for hashing/masking is deterministic and documented.
- Around line 177-181: The logger call currently includes raw username via
item.sessionAttributes?.auth_user; change this to log a pseudonymized value
instead (e.g., compute a deterministic hash of auth_user or mask it like first
char + redaction) and pass that masked/hash into the logger metadata (keep
sessionId as-is); update the code around the existing logger(...) call in
SessionListPage (the invocation that currently logs sessionId and auth_user) to
replace auth_user with the pseudonymized value or, if a non-PII user identifier
is available (e.g., user_id), log that instead.
In `@admin-ui/plugins/auth-server/components/Ssa/hooks/useSsaMutations.ts`:
- Around line 41-45: The logger calls in useSsaMutations are passing raw Error
objects (auditError) which may include sensitive stacks; change each logging
invocation (the logger(...) calls that reference auditError and jti) to log
auditError.message (or String(auditError) fallback) instead of the Error object
itself, preserving the { jti } context; update all occurrences that currently
use auditError instanceof Error ? auditError : String(auditError) (including the
similar blocks later) to use auditError instanceof Error ? auditError.message :
String(auditError).
In `@admin-ui/plugins/saml/components/hooks/useSamlApi.ts`:
- Around line 142-147: Replace the generic logger call in the catch block of
useSamlApi.ts with an error-level call so audit logging failures are surfaced;
specifically, in the catch where logger(`Failed to log ${resource} audit
action:`, ...) is invoked, call logger.error(...) instead and pass the same
message and error argument (keeping the error instanceof Error ? error :
String(error) logic intact).
In `@admin-ui/plugins/saml/components/WebsiteSsoIdentityBrokeringList.tsx`:
- Around line 134-139: In the catch block that handles identity provider
deletion failures in WebsiteSsoIdentityBrokeringList (the catch after the delete
flow—likely inside the deleteIdentityProvider/onDelete handler), replace the
generic logger(...) call with logger.error(...), preserving the existing error
formatting (error instanceof Error ? error : String(error)) and message text so
failures are logged at error level for production monitoring.
In `@admin-ui/plugins/user-claims/hooks/useSchemaAuditLogger.ts`:
- Around line 30-35: In the catch block inside useSchemaAuditLogger (the handler
that logs audit actions), replace the generic logger(...) call with
logger.error(...) so failures are emitted at error level; update the call that
currently passes '[useSchemaAuditLogger] Failed to log audit action:' and the
error payload (error instanceof Error ? error : String(error)) to be passed to
logger.error(...) instead to ensure production/error-level visibility.
In `@admin-ui/plugins/user-management/components/UserEditPage.tsx`:
- Around line 123-129: The logger call in the catch of the session revoke flow
logs all errors (logger in UserEditPage.tsx) including expected 404s; change the
catch to inspect status = (err as { response?: { status?: number }
}).response?.status and only call logger(...) when status !== 404, keeping the
current dispatch(updateToast(...)) behavior (i.e., suppress both toast and log
for 404s) so diagnostics don't record expected "no active session" responses;
ensure you still log full error details for non-404 failures.
---
Duplicate comments:
In
`@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsx`:
- Line 377: The onerror handler for the FileReader (reader.onerror) is logging
the raw ProgressEvent via logger('Error reading SHA256 file:', error); update
the handler to sanitize the event before logging by extracting safe fields
(e.g., reader.error?.name or reader.error?.message or event.type) or converting
to a safe string summary instead of dumping the whole event object; change the
logger call in AgamaFlows.tsx (the reader.onerror callback) to log a concise,
non-sensitive string such as "Error reading SHA256 file:
<error-type-or-message>" rather than the raw event.
In `@admin-ui/plugins/scripts/components/CustomScriptListPage.tsx`:
- Around line 138-141: Replace the generic logger call in the custom script
deletion catch block with an error-level log; specifically change the call to
logger(...) in the catch inside CustomScriptListPage (the deletion handler where
you currently call logger('Failed to delete custom script:', err instanceof
Error ? err : String(err))) to logger.error(...) keeping the same message and
err formatting, and leave the dispatch(updateToast(...)) and localization
(t('messages.error_deleting_script')) unchanged.
In `@admin-ui/plugins/user-management/components/PasswordChangeModal.tsx`:
- Around line 141-145: The catch in PasswordChangeModal that calls
logger('Failed to revoke user session after password change:', error as Error)
logs expected 404s; change it to only log unexpected errors by detecting a 404
and ignoring it (e.g., guard using (error as any).response?.status === 404 or an
axios/isFetch-specific check) and otherwise call logger with the error; update
the comment to reflect that 404s are intentionally suppressed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 48cddf32-ec17-425d-99b9-bc381c7b0485
📒 Files selected for processing (97)
admin-ui/app/cedarling/client/CedarlingClient.tsadmin-ui/app/cedarling/hooks/useCedarling.tsadmin-ui/app/components/App/PermissionsPolicyInitializer.tsxadmin-ui/app/components/Wizard/Wizard.tsxadmin-ui/app/context/theme/themeContext.tsxadmin-ui/app/i18n.tsadmin-ui/app/layout/default.tsxadmin-ui/app/redux/api/backend-api.tsadmin-ui/app/redux/listeners/authListener.tsadmin-ui/app/redux/listeners/licenseListener.tsadmin-ui/app/redux/listeners/sessionListener.tsadmin-ui/app/routes/Apps/Gluu/GluuAppSidebar.tsxadmin-ui/app/routes/Apps/Gluu/GluuCommitDialog.tsxadmin-ui/app/routes/Apps/Gluu/GluuScriptErrorModal.tsxadmin-ui/app/routes/Apps/Gluu/GluuSessionTimeout.tsxadmin-ui/app/routes/Apps/Gluu/ThemeDropdown.tsxadmin-ui/app/routes/Apps/Profile/hooks/useProfileDetails.tsadmin-ui/app/routes/License/hooks/useLicenseDetails.tsadmin-ui/app/routes/Pages/ByeBye.tsxadmin-ui/app/routes/index.tsxadmin-ui/app/utils/AppAuthProvider.tsxadmin-ui/app/utils/logger.tsadmin-ui/app/utils/menuFilters.tsadmin-ui/app/utils/pagingUtils.tsadmin-ui/app/utils/storage.tsadmin-ui/app/utils/triggerWebhookForFeature.tsadmin-ui/orval/__tests__/interceptors.test.tsadmin-ui/orval/interceptors.tsadmin-ui/plugins/PluginMenuResolver.tsadmin-ui/plugins/admin/components/Assets/JansAssetListPage.tsxadmin-ui/plugins/admin/components/Assets/hooks/useAssetAudit.tsadmin-ui/plugins/admin/components/Assets/hooks/useAssetMutations.tsadmin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsxadmin-ui/plugins/admin/components/Settings/SettingsPage.tsxadmin-ui/plugins/admin/components/Webhook/WebhookForm.tsxadmin-ui/plugins/admin/components/Webhook/WebhookListPage.tsxadmin-ui/plugins/admin/components/Webhook/hooks/useWebhookAudit.tsadmin-ui/plugins/admin/components/Webhook/hooks/useWebhookMutations.tsadmin-ui/plugins/auth-server/__tests__/api/setup.tsadmin-ui/plugins/auth-server/components/AuthServerProperties/components/AuthServerPropertiesPage.tsxadmin-ui/plugins/auth-server/components/AuthServerProperties/hooks/useAuthServerScripts.tsadmin-ui/plugins/auth-server/components/Authentication/Acrs/AcrsEditPage.tsxadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaFlows.tsxadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsxadmin-ui/plugins/auth-server/components/Authentication/Aliases/Aliases.tsxadmin-ui/plugins/auth-server/components/Authentication/DefaultAcr/DefaultAcr.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/components/ConfigApiPropertiesForm.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/components/ConfigApiPropertiesPage.tsxadmin-ui/plugins/auth-server/components/ConfigApiProperties/utils/valueUtils.tsadmin-ui/plugins/auth-server/components/JsonViewer/components/JsonViewerDialog.tsxadmin-ui/plugins/auth-server/components/Keys/hooks/useJwkApi.tsadmin-ui/plugins/auth-server/components/Logging/components/LoggingPage.tsxadmin-ui/plugins/auth-server/components/Logging/hooks/useLoggingApi.tsadmin-ui/plugins/auth-server/components/OidcClients/__tests__/hooks/useClientUmaResources.test.tsadmin-ui/plugins/auth-server/components/OidcClients/components/ClientAddPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientCibaParUmaPanel.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientEditPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/components/ClientListPage.tsxadmin-ui/plugins/auth-server/components/OidcClients/helper/utils.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useClientTokens.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useClientUmaResources.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useCreateClient.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useDeleteClient.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useUpdateClient.tsadmin-ui/plugins/auth-server/components/Scopes/components/ScopeAddPage.tsxadmin-ui/plugins/auth-server/components/Scopes/components/ScopeEditPage.tsxadmin-ui/plugins/auth-server/components/Scopes/components/ScopeListPage.tsxadmin-ui/plugins/auth-server/components/Scopes/hooks/useScopeMutations.tsadmin-ui/plugins/auth-server/components/Sessions/components/SessionListPage.tsxadmin-ui/plugins/auth-server/components/Sessions/hooks/useSessionMutations.tsadmin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsxadmin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsxadmin-ui/plugins/auth-server/components/Ssa/helper/utils.tsadmin-ui/plugins/auth-server/components/Ssa/hooks/useSsaApi.tsadmin-ui/plugins/auth-server/components/Ssa/hooks/useSsaMutations.tsadmin-ui/plugins/auth-server/services/jsonPropertiesService.tsadmin-ui/plugins/auth-server/utils/sessionExpiredRedirect.tsadmin-ui/plugins/fido/hooks/useFidoApi.tsadmin-ui/plugins/internal/loadPluginMetadata.tsadmin-ui/plugins/saml/components/WebsiteSsoIdentityBrokeringList.tsxadmin-ui/plugins/saml/components/WebsiteSsoServiceProviderList.tsxadmin-ui/plugins/saml/components/hooks/useSamlApi.tsadmin-ui/plugins/scripts/components/CustomScriptListPage.tsxadmin-ui/plugins/scripts/components/helper/auditUtils.tsadmin-ui/plugins/scripts/components/hooks/useCustomScriptApi.tsadmin-ui/plugins/services/Components/CachePage.tsxadmin-ui/plugins/services/Components/hooks/useCacheAudit.tsadmin-ui/plugins/smtp/components/SmtpEditPage.tsxadmin-ui/plugins/user-claims/components/UserClaimsListPage.tsxadmin-ui/plugins/user-claims/hooks/useAttributeApi.tsadmin-ui/plugins/user-claims/hooks/useSchemaAuditLogger.tsadmin-ui/plugins/user-claims/hooks/useSchemaWebhook.tsadmin-ui/plugins/user-management/components/PasswordChangeModal.tsxadmin-ui/plugins/user-management/components/UserEditPage.tsxadmin-ui/plugins/user-management/components/UserList.tsxadmin-ui/plugins/user-management/helper/utils.tsadmin-ui/plugins/user-management/hooks/useUserMutations.ts
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
admin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsx (1)
156-156:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUse
resolveApiErrorMessagefor consistency with other error logs in this file.Lines 127 and 139 in this file already use
resolveApiErrorMessageto safely extract error messages from API failures. Line 156 should follow the same pattern to avoid logging raw Error objects (which may be Axios errors with sensitive headers) and to maintain consistency.🔒 Proposed fix for consistency
} catch (error) { - logger('Delete SSA failed:', error instanceof Error ? error : String(error)) + logger('Delete SSA failed:', resolveApiErrorMessage(error as Error)) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsx` at line 156, Replace the raw error logging call with the project's safe extractor: in the SsaListPage delete handler (the place that currently calls logger('Delete SSA failed:', error instanceof Error ? error : String(error))), call resolveApiErrorMessage(error) and pass that result to logger so the message becomes logger('Delete SSA failed:', resolveApiErrorMessage(error)); this follows the pattern used earlier in this file (lines using resolveApiErrorMessage) and avoids logging raw Error/Axios objects.
♻️ Duplicate comments (4)
admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsx (2)
143-143:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid logging raw Error objects that may expose stack traces.
When
error instanceof Erroris true, the raw Error object (including its stack trace) is logged. Extract onlyerror.messageto prevent internal file paths from appearing in production console logs.🔒 Proposed fix
- logger('Failed to copy to clipboard:', error instanceof Error ? error : String(error)) + logger('Failed to copy to clipboard:', error instanceof Error ? error.message : String(error)) dispatch(updateToast(true, 'error', t('messages.copy_failed')))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsx` at line 143, In AgamaProjectConfigModal, avoid logging raw Error objects in the clipboard handler: change the logger call that currently passes error instanceof Error ? error : String(error) to pass error instanceof Error ? error.message : String(error) so only the error message is logged (reference the logger invocation in AgamaProjectConfigModal and the clipboard-copy error branch).
210-210:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid logging raw Error objects that may expose stack traces.
When
e instanceof Erroris true, the raw Error object (including its stack trace) is logged. Extract onlye.messageto prevent internal file paths from appearing in production console logs.🔒 Proposed fix
- logger('Error saving file:', e instanceof Error ? e : String(e)) + logger('Error saving file:', e instanceof Error ? e.message : String(e)) dispatch(updateToast(true, 'error', 'An error occurred while saving the file'))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsx` at line 210, The logger call inside AgamaProjectConfigModal (the save error handler where it does logger('Error saving file:', e instanceof Error ? e : String(e))) should avoid logging full Error objects; update it to log only the error message when e is an Error (e instanceof Error ? e.message : String(e)) so stack traces/internal paths are not emitted to logs while preserving the error text.admin-ui/app/redux/listeners/licenseListener.ts (2)
204-204:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid logging raw Error objects that may contain sensitive Axios metadata.
The caught error from
adminuiPostSsais likely an Axios error that can includeconfig.headerswith sensitive tokens. UseresolveApiErrorMessage(err as Error)to log only the safe message string.🔒 Proposed fix
} catch (err) { dispatch(checkLicenseConfigValidResponse(false)) - logger('Error uploading SSA token:', err instanceof Error ? err : String(err)) + logger('Error uploading SSA token:', resolveApiErrorMessage(err as Error)) dispatch(uploadNewSsaTokenResponse(getLicenseErrorMessage(err as Error | ApiErrorLike)))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/app/redux/listeners/licenseListener.ts` at line 204, Replace the raw error logging in the catch handler that calls logger('Error uploading SSA token:', err ...) so it doesn't emit sensitive Axios metadata; call resolveApiErrorMessage(err as Error) to extract a safe string and pass that to logger (e.g., logger('Error uploading SSA token:', resolveApiErrorMessage(err as Error))). Update the catch in the license upload flow (where adminuiPostSsa is called) to use resolveApiErrorMessage for logging.
216-216:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid logging raw Error objects that may contain sensitive Axios metadata.
The caught error from
checkAdminuiLicenseConfigApiis likely an Axios error with sensitive request metadata. UseresolveApiErrorMessage(error as Error)to extract only the safe message.🔒 Proposed fix
} catch (error) { - logger('Error checking license config:', error instanceof Error ? error : String(error)) + logger('Error checking license config:', resolveApiErrorMessage(error as Error)) dispatch(checkLicenseConfigValidResponse(false))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@admin-ui/app/redux/listeners/licenseListener.ts` at line 216, Replace the direct logging of the caught error object with a safe, sanitized message using resolveApiErrorMessage to avoid leaking Axios metadata: in the licenseListener code where checkAdminuiLicenseConfigApi's catch calls logger('Error checking license config:', error ...), call resolveApiErrorMessage(error as Error) and pass that result to logger (e.g., logger('Error checking license config:', resolveApiErrorMessage(error as Error))). Ensure you reference the existing logger and resolveApiErrorMessage symbols rather than logging the raw error object.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@admin-ui/app/redux/listeners/licenseListener.ts`:
- Line 95: Replace the raw error logging for the getStat call by importing and
using resolveApiErrorMessage to avoid leaking Axios metadata: add an import for
resolveApiErrorMessage and change the logger invocation that currently does
logger('Error checking MAU threshold:', err instanceof Error ? err :
String(err)) to logger('Error checking MAU threshold:',
resolveApiErrorMessage(err as Error)); this keeps the same log text but outputs
a safe string from resolveApiErrorMessage instead of the raw Error object.
In `@admin-ui/plugins/auth-server/components/OidcClients/helper/utils.ts`:
- Line 175: Replace the logger call to avoid including full Error objects — when
logging in utils.ts (the logger invocation that currently does logger('Failed to
download client tokens CSV:', error instanceof Error ? error : String(error))),
use error.message if error instanceof Error, otherwise fall back to
String(error); update the call site so the log receives a concise message (e.g.,
logger('Failed to download client tokens CSV:', error instanceof Error ?
error.message : String(error))).
---
Outside diff comments:
In `@admin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsx`:
- Line 156: Replace the raw error logging call with the project's safe
extractor: in the SsaListPage delete handler (the place that currently calls
logger('Delete SSA failed:', error instanceof Error ? error : String(error))),
call resolveApiErrorMessage(error) and pass that result to logger so the message
becomes logger('Delete SSA failed:', resolveApiErrorMessage(error)); this
follows the pattern used earlier in this file (lines using
resolveApiErrorMessage) and avoids logging raw Error/Axios objects.
---
Duplicate comments:
In `@admin-ui/app/redux/listeners/licenseListener.ts`:
- Line 204: Replace the raw error logging in the catch handler that calls
logger('Error uploading SSA token:', err ...) so it doesn't emit sensitive Axios
metadata; call resolveApiErrorMessage(err as Error) to extract a safe string and
pass that to logger (e.g., logger('Error uploading SSA token:',
resolveApiErrorMessage(err as Error))). Update the catch in the license upload
flow (where adminuiPostSsa is called) to use resolveApiErrorMessage for logging.
- Line 216: Replace the direct logging of the caught error object with a safe,
sanitized message using resolveApiErrorMessage to avoid leaking Axios metadata:
in the licenseListener code where checkAdminuiLicenseConfigApi's catch calls
logger('Error checking license config:', error ...), call
resolveApiErrorMessage(error as Error) and pass that result to logger (e.g.,
logger('Error checking license config:', resolveApiErrorMessage(error as
Error))). Ensure you reference the existing logger and resolveApiErrorMessage
symbols rather than logging the raw error object.
In
`@admin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsx`:
- Line 143: In AgamaProjectConfigModal, avoid logging raw Error objects in the
clipboard handler: change the logger call that currently passes error instanceof
Error ? error : String(error) to pass error instanceof Error ? error.message :
String(error) so only the error message is logged (reference the logger
invocation in AgamaProjectConfigModal and the clipboard-copy error branch).
- Line 210: The logger call inside AgamaProjectConfigModal (the save error
handler where it does logger('Error saving file:', e instanceof Error ? e :
String(e))) should avoid logging full Error objects; update it to log only the
error message when e is an Error (e instanceof Error ? e.message : String(e)) so
stack traces/internal paths are not emitted to logs while preserving the error
text.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a249e78a-0231-40ff-9ee3-7e3811b6b797
📒 Files selected for processing (15)
admin-ui/app/components/App/PermissionsPolicyInitializer.tsxadmin-ui/app/context/theme/themeContext.tsxadmin-ui/app/redux/listeners/authListener.tsadmin-ui/app/redux/listeners/licenseListener.tsadmin-ui/app/routes/Apps/Gluu/GluuSessionTimeout.tsxadmin-ui/app/routes/License/hooks/useLicenseDetails.tsadmin-ui/orval/__tests__/interceptors.test.tsadmin-ui/plugins/auth-server/components/Authentication/Acrs/AcrsEditPage.tsxadmin-ui/plugins/auth-server/components/Authentication/AgamaFlows/AgamaProjectConfigModal.tsxadmin-ui/plugins/auth-server/components/OidcClients/helper/utils.tsadmin-ui/plugins/auth-server/components/OidcClients/hooks/useCreateClient.tsadmin-ui/plugins/auth-server/components/Ssa/components/SsaAddPage.tsxadmin-ui/plugins/auth-server/components/Ssa/components/SsaListPage.tsxadmin-ui/plugins/auth-server/components/Ssa/helper/utils.tsadmin-ui/plugins/user-claims/hooks/useAttributeApi.ts
💤 Files with no reviewable changes (1)
- admin-ui/plugins/user-claims/hooks/useAttributeApi.ts
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
| window.localStorage.setItem(key, value) | ||
| } catch (e) { | ||
| devLogger.warn(`storage.set failed for "${key}":`, e instanceof Error ? e : String(e)) | ||
| logger(`storage.set failed for "${key}":`, e instanceof Error ? e : String(e)) |
There was a problem hiding this comment.
This log falls in which category? trace , info, debug, error...?
How the logger identifies the type (level) of log as there is no level indicator passed from here?
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
duttarnab
left a comment
There was a problem hiding this comment.
Are there no logs indicating the successful initialization of Cedarling and the execution of each authorization request? These are very important logs.
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
Signed-off-by: faisalsiddique4400 <faisalsiddique10886@gmail.com>
|



feat(admin-ui): surface error/warning logs in production for environment diagnostics (#2811)
Summary
Replaces the production-suppressed
devLoggerwith a singleloggerwhose verbosity is controlled by a log level. Operational warnings and errors now reach the browser console in deployed builds, so configuration and initialization failures are diagnosable without rebuilding the Admin UI.What changed
app/utils/logger.ts:logger(...)writes to the console honoring the active log level;logger.log(...)is plainconsole.log.app/utils/logLevel.ts: reads and writes the level fromlocalStorage['gluu.logLevel'], validated against the existingLOG_LEVELS(TRACE/DEBUG/INFO/WARN/ERROR), defaultINFO.app/utils/devLogger.tsand migrated every call site tologger().logger().buildLogPayloadomits thetokensarray.Verification
Follow-ups before this fully satisfies #2811
logger()re-emits the same message at every level from the active floor up toERROR(3 lines at defaultINFO). It should emit once at the call's severity. Needs fixing for criteria Admin UI: MAU - Date range showing undefined and ? #2.devLogger.warnbreadcrumbs (for example "Invalid paging size") now log atERROR. Re-classify which are operational vs dev-only so prod is not noisy.logger.logis unconditional. Confirm it is intended for prod or gate it.Ticket
Closes: #2811
Summary by CodeRabbit
New Features
Bug Fixes
Improvements