feat: add auth gemini #144
Conversation
WalkthroughThis pull request refactors several API routes for improved readability and consistency. Minor formatting changes have been applied in the confirm-payment and insights page files, while multiple routes now export a constant Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
participant JWTService
participant GeminiAPI
Client->>API: POST /gemini-flash
API->>Client: Retrieve session token from cookies
API->>JWTService: jwtVerify(token)
JWTService-->>API: Return payload (with optional address)
alt Valid token with address
API->>API: Validate request body and scores
API->>GeminiAPI: Request analysis
GeminiAPI-->>API: Analysis response
API->>Client: Return analysis data
else Missing/invalid address
API->>Client: Return 401 Unauthorized ("Invalid session")
end
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
✅ Deploy Preview for lucent-florentine-971919 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
frontend/src/app/api/gemini-flash/route.ts (1)
128-131: Consider moving API key validation to initialization.The API key validation could be moved to the top of the file alongside JWT_SECRET validation for consistent environment variable handling.
const JWT_SECRET = process.env.JWT_SECRET; if (!JWT_SECRET) { throw new Error("JWT_SECRET environment variable is required"); } + +const GEMINI_API_KEY = process.env.GEMINI_API_KEY; +if (!GEMINI_API_KEY) { + throw new Error("GEMINI_API_KEY environment variable is required"); +} const secret = new TextEncoder().encode(JWT_SECRET);frontend/src/app/api/public-figures/route.ts (2)
161-176: Consider optimizing celebrity matching logic.The current implementation iterates through all celebrities to find the best match. For better performance with large datasets, consider:
- Using database-level sorting/filtering
- Implementing pagination
- Caching frequently accessed celebrities
- let bestMatch = celebrities[0]; - let bestSimilarity = calculateSimilarity( - userScores, - celebrities[0].scores as UserScores, - ); - - for (const celebrity of celebrities) { - const similarity = calculateSimilarity( - userScores, - celebrity.scores as UserScores, - ); - if (similarity < bestSimilarity) { - bestSimilarity = similarity; - bestMatch = celebrity; - } - } + // Calculate similarities in parallel + const celebritiesWithSimilarity = await Promise.all( + celebrities.map(async (celebrity) => ({ + celebrity, + similarity: calculateSimilarity( + userScores, + celebrity.scores as UserScores, + ), + })) + ); + + // Find the best match + const { celebrity: bestMatch } = celebritiesWithSimilarity.reduce( + (best, current) => + current.similarity < best.similarity ? current : best, + celebritiesWithSimilarity[0] + );
195-197: Consider providing more specific error messages.The catch blocks could provide more specific error messages to help with debugging:
- } catch { + } catch (error) { + console.error('Session verification failed:', error); return NextResponse.json({ error: "Invalid session" }, { status: 401 }); }Also applies to: 280-282
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
frontend/src/app/api/confirm-payment/route.ts(1 hunks)frontend/src/app/api/gemini-flash/route.ts(5 hunks)frontend/src/app/api/home/route.ts(1 hunks)frontend/src/app/api/insights/route.ts(1 hunks)frontend/src/app/api/nonce/route.ts(1 hunks)frontend/src/app/api/public-figures/route.ts(5 hunks)frontend/src/app/api/tests/route.ts(1 hunks)frontend/src/app/api/user/me/route.ts(1 hunks)frontend/src/app/api/user/subscription/route.ts(1 hunks)frontend/src/app/insights/page.tsx(12 hunks)
✅ Files skipped from review due to trivial changes (7)
- frontend/src/app/api/nonce/route.ts
- frontend/src/app/api/insights/route.ts
- frontend/src/app/api/user/subscription/route.ts
- frontend/src/app/api/tests/route.ts
- frontend/src/app/insights/page.tsx
- frontend/src/app/api/confirm-payment/route.ts
- frontend/src/app/api/home/route.ts
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Bundle Analysis
- GitHub Check: Code Quality & Build
🔇 Additional comments (4)
frontend/src/app/api/user/me/route.ts (1)
19-19: LGTM! Dynamic rendering configuration added.The addition of
dynamic = "force-dynamic"ensures that the route is always dynamically rendered, which is appropriate for an API endpoint that needs to return fresh user data on each request.frontend/src/app/api/gemini-flash/route.ts (2)
29-31: LGTM! JWT authentication and environment validation added.Good security practices:
- JWT verification for authentication
- Early validation of JWT_SECRET environment variable
- Type-safe TokenPayload interface
Also applies to: 33-39
42-55: Verify session token validation in other routes.The session validation logic has been implemented correctly here. For consistency, ensure similar validation is implemented across all authenticated routes.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for routes that might need session validation echo "Searching for API routes..." fd --type f "route.ts" "frontend/src/app/api" echo -e "\nChecking for session token validation..." rg -l "cookies\(\).get\(\"session\"\)" "frontend/src/app/api"Length of output: 2037
The shell script output shows that many API routes contain a check for
cookies().get("session"), which indicates that the token validation mechanism (based on session cookies) is used in a number of endpoints. To further confirm that these routes implement complete validation (for example, performing the JWT verification similar to the gemini-flash route), I'll search for the use ofjwtVerify()in the API routes. This will help us verify that not only is the session token being read but that it is also properly verified.
🏁 Script executed:
#!/bin/bash # Search for jwtVerify usage in API routes to verify full validation logic exists echo "Searching for jwtVerify usage in API routes..." rg -l "jwtVerify(" frontend/src/app/apiLength of output: 215
I'll run a corrected script to search for
jwtVerifyusage with an escaped parenthesis.
🏁 Script executed:
#!/bin/bash echo "Searching for jwtVerify usage in API routes..." rg -l "jwtVerify\\(" frontend/src/app/apiLength of output: 830
Session Token Validation Consistency Verified
Our investigation shows that several authenticated API routes (e.g.,
confirm-payment,ideology,home,initiate-payment, etc.) use bothcookies().get("session")andjwtVerify(...)similarly to the gemini‑flash route. This suggests that session token validation is implemented consistently across the endpoints.frontend/src/app/api/public-figures/route.ts (1)
7-9: LGTM! Consistent authentication pattern.The TokenPayload interface matches the one in gemini-flash route, maintaining consistency across the codebase.
This PR does the following:
Summary by CodeRabbit
Chores
Refactor
Style