fix: resolve auth api and dashboard issues#51
Conversation
WalkthroughRefactors the dashboard page into a Suspense-wrapped ChangesDashboard Refactor
Backend and Config Updates
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant DashboardPage
participant DashboardContent
participant useCommunities
participant useActivityFeed
participant Router
DashboardPage->>DashboardContent: render inside Suspense
DashboardContent->>useCommunities: fetch communities
DashboardContent->>useActivityFeed: fetch posts
useCommunities-->>DashboardContent: communities loaded
alt no tenantId in URL
DashboardContent->>Router: replace to /dashboard?tenantId=...
end
DashboardContent-->>DashboardPage: render feed UI
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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 `@backend/src/main.ts`:
- Around line 14-20: The CORS allowlist in allowedOrigins currently mixes
FRONTEND_URL with localhost/127.0.0.1 dev URLs unconditionally, which leaves dev
origins trusted in production. Update backend/src/main.ts so the allowedOrigins
construction in the startup/CORS setup only appends the localhost/127.0.0.1
entries when running in a development environment, and keep production limited
to the configured FRONTEND_URL; use the existing allowedOrigins symbol so the
gating is easy to find.
In `@backend/tsconfig.json`:
- Line 18: The tsconfig setting uses a TypeScript 6-only deprecation target,
which conflicts with the currently pinned TypeScript 5.7.x version. Update the
backend/tsconfig.json setting for ignoreDeprecations to a 5.x-compatible value,
or alternatively align the TypeScript version in backend/package.json to 6.0;
check the tsconfig field and the package.json TypeScript dependency together so
they match.
In `@frontend/.env.example`:
- Around line 1-2: The .env example secrets are using a real-looking base64
value, which can be flagged by secret scanners and copied into real environments
accidentally. Update the placeholders for AUTH_SECRET and NEXTAUTH_SECRET in the
.env.example file to obviously fake, non-secret values (for example, a
“changeme” style placeholder) so it is clear they must be replaced before use.
In `@frontend/src/hooks/use-communities.ts`:
- Around line 33-36: The catch block in useCommunities is clearing the hook’s
error state, which hides fetch failures from consumers like DiscoverPage. Update
the error handling in useCommunities so the catch path preserves the failure by
setting error to the caught exception (or a derived message) instead of
resetting it to null, while still clearing communities as needed; keep the
existing loading/reset flow in the hook’s fetch logic intact.
🪄 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: CHILL
Plan: Pro
Run ID: 9384b23e-08c4-46c8-b64d-1bd968f72984
📒 Files selected for processing (6)
backend/src/main.tsbackend/tsconfig.jsonfrontend/.env.examplefrontend/src/app/dashboard/dashboard-content.tsxfrontend/src/app/dashboard/page.tsxfrontend/src/hooks/use-communities.ts
| const allowedOrigins = [ | ||
| process.env.FRONTEND_URL, | ||
| 'http://localhost:3001', | ||
| 'http://127.0.0.1:3001', | ||
| 'http://localhost:8080', | ||
| 'http://127.0.0.1:8080', | ||
| ].filter(Boolean) as string[]; |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Dev-only origins remain allowed in production.
allowedOrigins unconditionally includes localhost:3001/127.0.0.1:3001/:8080 dev URLs alongside FRONTEND_URL, with no environment gating. In production this means the credentialed CORS allowlist always trusts local dev origins, unnecessarily widening the trust boundary for a credentials-enabled API.
🔒 Proposed fix — gate dev origins by environment
- const allowedOrigins = [
- process.env.FRONTEND_URL,
- 'http://localhost:3001',
- 'http://127.0.0.1:3001',
- 'http://localhost:8080',
- 'http://127.0.0.1:8080',
- ].filter(Boolean) as string[];
+ const devOrigins = [
+ 'http://localhost:3001',
+ 'http://127.0.0.1:3001',
+ 'http://localhost:8080',
+ 'http://127.0.0.1:8080',
+ ];
+ const allowedOrigins = [
+ process.env.FRONTEND_URL,
+ ...(process.env.NODE_ENV !== 'production' ? devOrigins : []),
+ ].filter(Boolean) as string[];📝 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.
| const allowedOrigins = [ | |
| process.env.FRONTEND_URL, | |
| 'http://localhost:3001', | |
| 'http://127.0.0.1:3001', | |
| 'http://localhost:8080', | |
| 'http://127.0.0.1:8080', | |
| ].filter(Boolean) as string[]; | |
| const devOrigins = [ | |
| 'http://localhost:3001', | |
| 'http://127.0.0.1:3001', | |
| 'http://localhost:8080', | |
| 'http://127.0.0.1:8080', | |
| ]; | |
| const allowedOrigins = [ | |
| process.env.FRONTEND_URL, | |
| ...(process.env.NODE_ENV !== 'production' ? devOrigins : []), | |
| ].filter(Boolean) as string[]; |
🤖 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 `@backend/src/main.ts` around lines 14 - 20, The CORS allowlist in
allowedOrigins currently mixes FRONTEND_URL with localhost/127.0.0.1 dev URLs
unconditionally, which leaves dev origins trusted in production. Update
backend/src/main.ts so the allowedOrigins construction in the startup/CORS setup
only appends the localhost/127.0.0.1 entries when running in a development
environment, and keep production limited to the configured FRONTEND_URL; use the
existing allowedOrigins symbol so the gating is easy to find.
| "rootDir": "./src", | ||
| "outDir": "./dist", | ||
| "baseUrl": "./", | ||
| "ignoreDeprecations": "6.0", |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check pinned typescript version in backend
fd package.json backend -x jq -r '.devDependencies.typescript // .dependencies.typescript' {}Repository: HappyHackingSpace/CommunityHub
Length of output: 175
🌐 Web query:
TypeScript ignoreDeprecations "6.0" 5.7.3 diagnostic TS5103 docs
💡 Result:
In TypeScript 5.7.3, the compiler option "ignoreDeprecations": "6.0" is invalid and will trigger diagnostic error TS5103: "Invalid value for '--ignoreDeprecations'" [1][2][3]. The "ignoreDeprecations": "6.0" setting is a feature introduced specifically in TypeScript 6.0 to allow developers to suppress deprecation warnings for features that are planned for removal in TypeScript 7.0 [4]. Because TypeScript 5.7.3 predates the 6.0 release, it does not recognize "6.0" as a valid argument for this configuration option [4][5]. If you are encountering deprecation warnings in TypeScript 5.7.3, you must use a version-appropriate value (such as "5.0") if supported by your specific environment, or address the underlying configuration issue directly by removing or updating the deprecated feature [6][1]. Attempting to use "6.0" in any TypeScript 5.x version will consistently result in error TS5103 [1][2][3].
Citations:
- 1: fix(docs): remove ignoreDeprecations in tsconfig.json microsoft/edge-ai#488
- 2: web UI build: TS
baseUrldeprecated in tsconfig.app.json breaks tsc -b (TypeScript 5.9) NousResearch/hermes-agent#35685 - 3: BUILD FIX: Agent-Farm Extension Compilation Failures Resolved (Issue #195) kushin77/code-server#195
- 4: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html
- 5: microsoft/TypeScript@v5.7.3...v6.0.3
- 6: [help] tsc "ignoreDeprecations": "6.0" microsoft/TypeScript#62916
backend/tsconfig.json uses a TypeScript 6-only value
backend/package.json pins TypeScript ^5.7.3, so ignoreDeprecations: "6.0" will fail on this branch with TS5103. Either switch to a 5.x-compatible value or upgrade TypeScript to 6.0.
🤖 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 `@backend/tsconfig.json` at line 18, The tsconfig setting uses a TypeScript
6-only deprecation target, which conflicts with the currently pinned TypeScript
5.7.x version. Update the backend/tsconfig.json setting for ignoreDeprecations
to a 5.x-compatible value, or alternatively align the TypeScript version in
backend/package.json to 6.0; check the tsconfig field and the package.json
TypeScript dependency together so they match.
| AUTH_SECRET=XKZ7Z1O3bhU4caz2D8ouu7dKhXyQ+ZUhsjvTwtHxp10= | ||
| NEXTAUTH_SECRET=XKZ7Z1O3bhU4caz2D8ouu7dKhXyQ+ZUhsjvTwtHxp10= |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Use an obvious placeholder instead of a real-looking secret value.
Both AUTH_SECRET and NEXTAUTH_SECRET use an identical, well-formed base64 string. Secret scanners flag this as a potential real credential, and if ever copy-pasted verbatim into a real .env, it provides no security. Prefer a clearly fake placeholder (e.g., AUTH_SECRET=changeme-generate-with-openssl-rand-base64-32).
🧰 Tools
🪛 Betterleaks (1.6.0)
[high] 1-1: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 2-2: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 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 `@frontend/.env.example` around lines 1 - 2, The .env example secrets are using
a real-looking base64 value, which can be flagged by secret scanners and copied
into real environments accidentally. Update the placeholders for AUTH_SECRET and
NEXTAUTH_SECRET in the .env.example file to obviously fake, non-secret values
(for example, a “changeme” style placeholder) so it is clear they must be
replaced before use.
Source: Linters/SAST tools
| } catch (err: any) { | ||
| console.error("Failed to fetch communities", err); | ||
| setError(err); | ||
| console.warn('Failed to fetch communities, using empty state', err?.message || err); | ||
| setCommunities([]); | ||
| setError(null); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Don't clear error state on fetch failure — it breaks downstream error UIs.
Resetting error to null in the catch block means the hook's error state is always null, so consumers can no longer distinguish "no communities" from "fetch failed."
DiscoverPage renders a spinner while loading, shows an error panel only when error is set, otherwise shows "No communities found" when filteredCommunities is empty. With this change, backend/network failures will silently render as "The directory is currently empty," hiding real failures from users.
🐛 Proposed fix to preserve error visibility
} catch (err: any) {
console.warn('Failed to fetch communities, using empty state', err?.message || err);
setCommunities([]);
- setError(null);
+ setError(err instanceof Error ? err : new Error(err?.message || 'Failed to fetch communities'));
} finally {📝 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.
| } catch (err: any) { | |
| console.error("Failed to fetch communities", err); | |
| setError(err); | |
| console.warn('Failed to fetch communities, using empty state', err?.message || err); | |
| setCommunities([]); | |
| setError(null); | |
| } catch (err: any) { | |
| console.warn('Failed to fetch communities, using empty state', err?.message || err); | |
| setCommunities([]); | |
| setError(err instanceof Error ? err : new Error(err?.message || 'Failed to fetch communities')); |
🤖 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 `@frontend/src/hooks/use-communities.ts` around lines 33 - 36, The catch block
in useCommunities is clearing the hook’s error state, which hides fetch failures
from consumers like DiscoverPage. Update the error handling in useCommunities so
the catch path preserves the failure by setting error to the caught exception
(or a derived message) instead of resetting it to null, while still clearing
communities as needed; keep the existing loading/reset flow in the hook’s fetch
logic intact.
1 participant
Summary by CodeRabbit
New Features
Bug Fixes