Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion src/runtime/app/composables/session.ts
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,10 @@ export function useUserSession(): UserSessionComposable {
accept: 'application/json',
},
retry: false,
}).catch(() => null)
}).catch(reason => {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix lint error for arrow function parentheses.

Line 35 currently violates @stylistic/arrow-parens; this can fail lint/CI.

Minimal lint fix
-    }).catch(reason => {
+    }).catch((reason) => {
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
}).catch(reason => {
}).catch((reason) => {
🧰 Tools
🪛 ESLint

[error] 35-35: Expected parentheses around arrow function argument having a body with curly braces.

(@stylistic/arrow-parens)

🤖 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 `@src/runtime/app/composables/session.ts` at line 35, The arrow function
parameter in the `.catch()` method violates the `@stylistic/arrow-parens`
linting rule. Wrap the single parameter `reason` in parentheses by changing
`.catch(reason => {` to `.catch((reason) => {` to comply with the linting
requirement.

Source: Linters/SAST tools

console.log('Failure on fetching session', reason)
return null
Comment on lines +35 to +37

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Avoid logging raw fetch rejection objects.

At Line 36, logging reason directly can leak sensitive auth/session error details into client/server logs. Prefer a sanitized message (and only include minimal safe fields in development mode).

Suggested safer pattern
-    }).catch(reason => {
-      console.log('Failure on fetching session', reason)
+    }).catch((reason) => {
+      const message = reason instanceof Error ? reason.message : String(reason)
+      if (import.meta.dev) {
+        console.error('Failure on fetching session:', message)
+      }
       return null
     })
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
}).catch(reason => {
console.log('Failure on fetching session', reason)
return null
}).catch((reason) => {
const message = reason instanceof Error ? reason.message : String(reason)
if (import.meta.dev) {
console.error('Failure on fetching session:', message)
}
return null
})
🧰 Tools
🪛 ESLint

[error] 35-35: Expected parentheses around arrow function argument having a body with curly braces.

(@stylistic/arrow-parens)

🤖 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 `@src/runtime/app/composables/session.ts` around lines 35 - 37, The catch
handler in the session composable is logging the raw rejection reason object
directly, which can expose sensitive authentication and session details in logs.
Replace the direct logging of the raw `reason` parameter with a sanitized error
message that does not include sensitive information. If error details are needed
for development debugging, consider logging only safe, minimal information and
only when in development mode, while production should use a generic safe
message.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We may somewhat fix the issue by yielding sessionState.value here instead of null. It would allow to preserve the session state on fetch failure, instead of losing it.

})
if (!authReadyState.value) {
authReadyState.value = true
}
Expand Down
Loading