You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/api/auth/google redirects to Google OAuth (youtube.force-ssl scope, offline access, prompt=consent)
/api/auth/google/callback exchanges code, requires refresh_token, looks up channel via channels?part=snippet&mine=true, upserts encrypted refresh token
/api/cron returns 401 on bad secret, runs pipeline per channel with per-channel error capture
npm run check: 0 errors, 0 warnings
npm run build: exits 0 (adapter-netlify)
IMPORTANT correction: the first version of this PR overwrote main's enhanced cron endpoint (channel leasing, one-channel-per-invocation from 65eb995) with the execution plan's simpler version. That was my error — the maintainer's version is a strict superset of the plan's contract (401 on bad secret, dryRun flag, per-channel results), so commit 'fix: restore main's leased cron endpoint' reverted to it. This PR now only adds the two OAuth route files.
Files carry AGPL headers/tabs per AGENTS.md. Do not merge if any step's Verify failed.
Greptile Summary
Adds Google OAuth enrollment and supporting regression coverage.
Redirects channel owners to Google with offline YouTube moderation access and CSRF state binding.
Exchanges authorization codes, resolves the owner's YouTube channel, and stores its encrypted refresh token.
Adds OAuth success, configuration, state-validation, upstream-error, and token-redaction tests.
Retunes Codacy analyzers and documents repository review and verification rules.
Confidence Score: 3/5
The PR is not yet safe to merge because overlapping OAuth starts in one browser can invalidate a legitimate authorization callback.
The environment-validation issue is fixed and the open-enrollment concern was withdrawn, but the start route still stores only one OAuth state value per browser, so a second authorization start overwrites the first transaction and makes one callback fail.
Files Needing Attention: src/routes/api/auth/google/+server.ts and src/routes/api/auth/google/callback/+server.ts
Important Files Changed
Filename
Overview
src/routes/api/auth/google/+server.ts
Adds the Google authorization redirect and CSRF state cookie; the previously reported single-cookie collision remains.
src/routes/api/auth/google/callback/+server.ts
Adds state validation, token exchange, channel lookup, encrypted credential persistence, and explicit upstream failure handling.
src/routes/api/auth/google/oauth.test.ts
Adds focused regression coverage for OAuth parameters, state rejection, configuration errors, secret redaction, upstream failures, and enrollment.
AGENTS.md
Expands repository security, reliability, architecture, and verification guidance.
.codacy/codacy.config.json
Narrows Codacy analysis to stack-relevant Semgrep, Trivy, and Biome coverage.
Sequence Diagram
sequenceDiagram
participant B as Browser
participant A as Auth start route
participant G as Google OAuth
participant C as Callback route
participant Y as YouTube API
participant D as Database
B->>A: GET /api/auth/google
A-->>B: Set oauth_state cookie
A-->>B: 302 Google authorization URL
B->>G: Authorize channel access
G-->>C: code and state
C->>C: Verify state and configuration
C->>G: Exchange code for tokens
C->>Y: Resolve authenticated channel
C->>D: Upsert channel and encrypted refresh token
C-->>B: 302 /
It 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 reviews.auto_review.auto_pause_after_reviewed_commits setting.
Use the following commands to manage reviews:
@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.
Use the checkboxes below for quick actions:
▶️ Resume reviews
🔍 Trigger review
📝 Walkthrough
Summary by CodeRabbit
New Features
Added Google OAuth sign-in and YouTube channel connection, linking the authenticated channel back to the app with a post-login redirect.
Bug Fixes
Improved OAuth flow validation (state + required parameters), stronger error handling for token exchange and channel lookup, and safer handling of missing/invalid refresh credentials.
Tests
Added end-to-end-style Vitest coverage for successful login and major failure scenarios, including secure cookie behavior and prevention of token leakage.
Chores
Updated code-quality scanning configuration and tightened testing/review requirements.
Walkthrough
Adds Google OAuth authorization and callback routes that validate CSRF state, exchange authorization codes, retrieve and persist authenticated YouTube channels with encrypted refresh tokens, and redirect successful callbacks home. Tests cover validation, upstream failures, token handling, and persistence. Codacy configuration and review guidance are also updated.
Changes
Google OAuth flow
Layer / File(s)
Summary
Google OAuth authorization src/routes/api/auth/google/+server.ts, src/routes/api/auth/google/oauth.test.ts
The authorization route validates environment configuration, stores an HTTP-only oauth_state cookie, builds the Google OAuth URL, and redirects with HTTP 302. Tests cover redirect parameters, state handling, and missing configuration.
The callback validates state and code, exchanges the code for Google tokens, fetches the authenticated YouTube channel, encrypts and upserts its refresh token, and redirects to /. Tests cover validation failures, missing refresh tokens, YouTube errors, token leakage, and successful persistence.
Codacy language, Semgrep, Biome, tool, coverage, exclusion, metadata, warning, and verification settings are updated.
Testing and review guidance AGENTS.md
Testing guidance now requires failures for incorrect logic, and review rules cover secret handling, OAuth state, environment validation, external API errors, architecture, and process checks.
/api/auth/google redirects to Google OAuth (youtube.force-ssl scope, offline access, prompt=consent)
/api/auth/google/callback exchanges code, requires refresh_token, looks up channel via channels?part=snippet&mine=true, upserts encrypted refresh token
/api/cron returns 401 on bad secret, runs pipeline per channel with per-channel error capture
npm run check: 0 errors, 0 warnings
npm run build: exits 0 (adapter-netlify)
Files verbatim from the execution plan plus AGPL headers/tabs per AGENTS.md.
Do not merge if any step's Verify failed.
CodeAnt-AI Description
Add Google channel connection and run moderation across all channels
What Changed
Users can connect a YouTube channel through Google OAuth and return to the app with the channel enabled
Connected channel details and authorization are saved, and reconnecting updates the existing channel
Scheduled runs now process every configured channel and continue processing when one channel fails
Cron requests with an invalid secret are rejected with a 401 response
Impact
✅ One-step Google channel connection ✅ All configured channels processed by scheduled runs ✅ One channel failure no longer stops other channel runs
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Add Google OAuth connect flow and cron pipeline runner
✨ Enhancement🕐 20-40 Minutes
AI Description
• Add Google OAuth redirect and callback routes to connect a YouTube channel
• Exchange auth code for refresh token, fetch channel metadata, and upsert encrypted credentials
• Update cron endpoint to authenticate via secret and run the pipeline for every channel
The following are alternative approaches to this PR:
1. Keep per-invocation leasing (one channel per cron call)
➕ Avoids long-running cron requests on serverless platforms with strict time limits
➕ Prevents a single slow/failing channel from delaying all others
➕ Supports safe parallelism with multiple cron invocations
➖ More complex DB logic (leases/claiming)
➖ Requires the scheduler to trigger frequently enough to cover all channels
2. Hybrid batching (process N channels per run + time budget)
➕ Bounds runtime while still making progress across multiple channels per invocation
➕ Can prioritize channels and stop before platform deadline
➖ More scheduling/selection logic (batch size, ordering, resumability)
➖ Still needs careful handling to avoid starvation
3. Harden OAuth with state (+ optionally PKCE)
➕ Mitigates CSRF/callback injection risks during OAuth
➕ Improves defense-in-depth for auth flow
➖ Requires generating/storing/verifying state (cookies/session)
➖ Adds a bit of implementation complexity to otherwise simple routes
Recommendation: The OAuth approach (direct authorize redirect + token exchange + encrypted refresh-token storage) is pragmatic and fits SvelteKit server routes well, but the cron change is a strategic tradeoff. If this is deployed to serverless (e.g., Netlify), running every channel in a single request risks timeouts; consider restoring leasing or adopting a bounded batch/time-budget approach. Independently, adding an OAuth state parameter is advisable to harden the callback flow.
Files changed (3) +118 / -48
Enhancement (3) +118 / -48
+server.tsAdd Google OAuth authorize redirect endpoint+33/-0
Add Google OAuth authorize redirect endpoint
• Introduces a GET route that constructs Google OAuth authorization parameters (offline access, prompt=consent, YouTube scope) and redirects the user to Google's consent screen.
+server.tsHandle OAuth callback, fetch channel, and upsert encrypted refresh token+72/-0
Handle OAuth callback, fetch channel, and upsert encrypted refresh token
• Adds a callback GET route that exchanges the authorization code for tokens, requires a refresh token, fetches the authenticated user's YouTube channel, and upserts the channel record with an encrypted refresh token.
+server.tsRun pipeline for all channels with per-channel error capture+13/-48
Run pipeline for all channels with per-channel error capture
• Simplifies cron handling to validate a shared secret, iterate over all channels, run the pipeline per channel, and return a combined results object while capturing errors per channel.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
The pull request introduces significant security risks and architectural regressions that should prevent it from being merged in its current state. Specifically, the OAuth2 flow lacks CSRF protection via a 'state' parameter, and the callback route leaks sensitive access tokens in error responses. Additionally, the Codacy analysis is not up to standards, primarily due to these high-severity issues and multiple new quality findings.
From an architectural standpoint, the cron route has been refactored to use a sequential processing loop instead of the previous atomic lease system. This change introduces a performance bottleneck and increases the risk of request timeouts on serverless platforms as the number of channels grows. Functional requirements regarding environment variable consistency and automated testing were also unaddressed.
About this PR
The /api/cron route was refactored to process all channels in a single request, removing the atomic lease and concurrency protection logic. This change introduces scalability risks, including platform timeouts and potential duplicate processing if the request is retried.
No test files were included in the PR to verify the complex OAuth callback logic, token encryption, or the cron pipeline execution loop.
Test suggestions
Verify /api/auth/google initiates redirect with the specific required OAuth parameters.
Verify /api/auth/google/callback handles missing codes and failed token exchanges with 400 errors.
Verify /api/auth/google/callback fails if no refresh_token is returned by Google.
Verify /api/auth/google/callback correctly encrypts tokens and upserts channel records.
Verify /api/cron rejects requests with invalid or missing secrets (401).
Verify /api/cron processes all channels and returns a summary object with error capture.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify /api/auth/google initiates redirect with the specific required OAuth parameters.
2. Verify /api/auth/google/callback handles missing codes and failed token exchanges with 400 errors.
3. Verify /api/auth/google/callback fails if no refresh_token is returned by Google.
4. Verify /api/auth/google/callback correctly encrypts tokens and upserts channel records.
5. Verify /api/cron rejects requests with invalid or missing secrets (401).
6. Verify /api/cron processes all channels and returns a summary object with error capture.
`token exchange failed: ${JSON.stringify(tokens)} — if this channel was connected before, revoke app access at myaccount.google.com/permissions and retry`
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The error message includes JSON.stringify(tokens), which leaks the access_token and other sensitive OAuth metadata to the client. Log the full error to the server console and return a generic error message to the user to prevent token exposure.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The OAuth2 flow is missing a 'state' parameter. Implement a 'state' parameter by generating a random string, storing it in a secure, HTTP-only cookie, and verifying it in the callback route to prevent CSRF attacks.
Additionally, avoid using the non-null assertion operator (!) for GOOGLE_CLIENT_ID. If the environment variable is missing, this will throw a generic runtime error; it is safer to explicitly validate its presence at the top of the file or provide a fallback.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Awaiting runChannel inside the loop causes sequential execution, which will lead to timeouts as the number of channels increases. The previous implementation used an atomic lease system to process one channel per invocation, which is a much more scalable and robust pattern for cron jobs.
Try refactoring this to use concurrent execution with Promise.allSettled for the channel runs, or ideally, restore the atomic leasing logic to process channels one-by-one across multiple cron triggers.
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 6c3f73e — the atomic lease endpoint is restored: one channel per invocation, claimed with an expiring lease before runChannel, released (and lastRunAt recorded) in a finally. Per-channel failures return 500 so they never look like success.
The reason will be displayed to describe this comment to others. Learn more.
⚪ LOW RISK
Suggestion: Use env.DRY_RUN from the imported $env/dynamic/private module instead of process.env.DRY_RUN for consistency and to ensure compatibility with SvelteKit's environment handling.
Missing OAuth state validation allows login and channel-linking CSRF
The authorization request does not include a cryptographically random state value, and the callback has no corresponding state check. An attacker can initiate OAuth with their own Google account and cause the victim to follow the callback, associating the attacker's channel with the application's shared channel state. Generate and persist a state value for the initiating session, then require and validate it in the callback.
❌ OAuth callback can link an attacker-controlled channel.
❌ Shared channel configuration can be replaced through CSRF.
⚠️ Victims can be redirected into unauthorized account linking.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/+server.ts
**Line:** 24:30
**Comment:***Security: The authorization request does not include a cryptographically random `state` value, and the callback has no corresponding state check. An attacker can initiate OAuth with their own Google account and cause the victim to follow the callback, associating the attacker's channel with the application's shared channel state. Generate and persist a state value for the initiating session, then require and validate it in the callback.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Critical
Logic error
Successful cron runs do not record their execution timestamp, breaking persisted channel rotation state
The handler never updates channels.lastRunAt, despite the field being the persisted scheduling timestamp used for channel rotation. Every channel remains permanently marked as never run, so any rotation or fairness logic based on this field will repeatedly treat these channels as first-run candidates. Update the timestamp as part of the successful claim/run lifecycle.
This is a comment left during a code review.
**Path:** src/routes/api/cron/+server.ts
**Line:** 32:35
**Comment:***Logic Error: The handler never updates `channels.lastRunAt`, despite the field being the persisted scheduling timestamp used for channel rotation. Every channel remains permanently marked as never run, so any rotation or fairness logic based on this field will repeatedly treat these channels as first-run candidates. Update the timestamp as part of the successful claim/run lifecycle.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Critical
Type error
Unvalidated OAuth token fields can cause runtime failures or unusable stored credentials
The token response is used without validating that it is an object containing non-empty string values. A malformed or unexpected response can make tokens.refresh_token property access throw, pass a non-string refresh token into encrypt, or produce an invalid Bearer header from access_token. Validate both token fields before using or persisting them.
❌ OAuth connection can fail with an unhandled server error.
❌ Invalid refresh credentials can be persisted.
⚠️ Provider failures become inconsistent callback responses.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 41:49
**Comment:***Type Error: The token response is used without validating that it is an object containing non-empty string values. A malformed or unexpected response can make `tokens.refresh_token` property access throw, pass a non-string refresh token into `encrypt`, or produce an invalid `Bearer` header from `access_token`. Validate both token fields before using or persisting them.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Api mismatch
Unchecked provider responses turn YouTube failures into misleading callback errors
The YouTube response status is never checked and its body is parsed directly with json(). A non-2xx JSON response such as an expired or unauthorized access-token error is treated as a missing channel, while a non-JSON or transient response becomes an unhandled parsing failure. Check the HTTP status, validate the response shape, and return an error that preserves the provider failure so the OAuth flow can be retried correctly.
⚠️ Expired tokens are reported as missing channels.
⚠️ Transient YouTube failures become opaque callback errors.
❌ Non-JSON provider responses can produce HTTP 500 failures.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 53:55
**Comment:***Api Mismatch: The YouTube response status is never checked and its body is parsed directly with `json()`. A non-2xx JSON response such as an expired or unauthorized access-token error is treated as a missing channel, while a non-JSON or transient response becomes an unhandled parsing failure. Check the HTTP status, validate the response shape, and return an error that preserves the provider failure so the OAuth flow can be retried correctly.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR implements Google OAuth authentication but fails to meet quality standards and introduces a high-risk security vulnerability. Specifically, the OAuth flow is missing a 'state' parameter, leaving the system open to CSRF attacks. Furthermore, while the PR title mentions 'cron routes', these are entirely missing from the implementation, representing a significant gap in the expected acceptance criteria.
From a quality perspective, the newly introduced callback handler is flagged as complex and lacks any test coverage or automated verification. The code also relies on fragile patterns such as string interpolation for URL construction and non-null assertions for environment variables, which should be replaced with safer validation logic. These issues should be addressed before merging to ensure the security and reliability of the authentication flow.
About this PR
No automated tests or test files were included to verify the new OAuth redirection or callback logic. Given the complexity of the authentication flow, unit tests are required to prevent regressions.
The PR title and description specify 'cron routes', but the diff contains no changes to cron logic. This creates a mismatch between the PR scope and the 'Phase D' requirements.
Test suggestions
Verify /api/auth/google constructs the redirection URL with correct scope, access_type, and prompt parameters
Verify /api/auth/google/callback returns 400 when the code parameter is missing
Verify /api/auth/google/callback fails with an error if Google does not return a refresh_token
Verify the YouTube API response is handled correctly and results in a database upsert
Add unit tests for src/routes/api/auth/google/callback/+server.ts to address complexity and coverage gaps
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify /api/auth/google constructs the redirection URL with correct scope, access_type, and prompt parameters
2. Verify /api/auth/google/callback returns 400 when the code parameter is missing
3. Verify /api/auth/google/callback fails with an error if Google does not return a refresh_token
4. Verify the YouTube API response is handled correctly and results in a database upsert
5. Add unit tests for src/routes/api/auth/google/callback/+server.ts to address complexity and coverage gaps
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The OAuth flow is vulnerable to CSRF because it does not use a state parameter.
Try running the following prompt in your coding agent:
Implement a 'state' parameter for the Google OAuth flow in SvelteKit. Generate a random value, store it in an HttpOnly cookie in the GET handler, and verify it matches the 'state' query parameter in the callback handler.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Using non-null assertions for GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET can lead to hard-to-debug 400 errors during the token exchange if the environment is misconfigured. Explicitly checking for these values at the start of the request handler ensures that the server fails with a descriptive 500 error instead of sending a malformed request to Google.
Try running the following prompt in your IDE agent:
In src/routes/api/auth/google/callback/+server.ts, add a validation check at the beginning of the GET function to ensure GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are present in the environment. If they are missing, throw a 500 error. Then, remove the non-null assertions on lines 35 and 36.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
The non-null assertion on env.GOOGLE_CLIENT_ID bypasses type safety for an environment variable that is essential for constructing the OAuth redirect. If this variable is missing, the application will redirect to an invalid URL. It is safer to validate the presence of the variable and throw a clear error.
Try running the following prompt in your IDE agent:
Update the GET function in src/routes/api/auth/google/+server.ts to validate that env.GOOGLE_CLIENT_ID is defined, throwing an appropriate error if it is not, and remove the non-null assertion.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
Suggestion: The YouTube channels API response is processed via .json() without checking chRes.ok. If the API returns an error status code, the application may proceed with incorrect data. This is particularly risky given this file is identified as a complex component with no test coverage.
The OAuth callback throws an error message containing JSON.stringify(tokens), which can expose
access/refresh tokens to the client and/or server logs on token-exchange failures or missing
refresh_token scenarios. This is a credential disclosure risk for the connected YouTube account.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The callback handler includes the entire token response JSON in a thrown SvelteKit `error(...)` message. That response may include `access_token` (and other sensitive fields), which should never be returned to the browser or logged verbatim.
### Issue Context
This occurs when `!tokenRes.ok` or when `tokens.refresh_token` is missing.
### Fix
- Replace the client-facing error with a generic message (e.g. "token exchange failed") and optionally include only `error` / `error_description` fields.
- Log a sanitized server-side error (status code + non-secret error fields), never raw tokens.
### Fix Focus Areas
- src/routes/api/auth/google/callback/+server.ts[41-46]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. OAuth missing state✓ Resolved🐞 Bug⛨ Security
Description
The OAuth authorization request does not include a state parameter and the callback does not
validate one, leaving the flow without CSRF/code-injection protection. This makes it possible to
bind an unsolicited authorization response to this app instance (and becomes worse once user
sessions exist).
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The OAuth initiation endpoint constructs the Google authorization URL without a `state` parameter, and the callback accepts any `code` without verifying a state value. This breaks the standard OAuth CSRF/binding protection.
### Issue Context
Routes involved:
- `/api/auth/google` generates the authorization URL.
- `/api/auth/google/callback` exchanges the code and stores refresh tokens.
### Fix
- Generate a cryptographically random `state` value in `/api/auth/google`.
- Store it in an HttpOnly cookie (Secure + SameSite=Lax/Strict) or server-side session.
- Add `state` to the authorization URL.
- In the callback, require `state` and verify it matches the stored value; reject otherwise.
- Clear the stored state after successful verification.
### Fix Focus Areas
- src/routes/api/auth/google/+server.ts[23-32]
- src/routes/api/auth/google/callback/+server.ts[26-29]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The cron route now runs runChannel for every channel without any lease/claim mechanism, so
overlapping cron invocations can process the same channel concurrently. Concurrent runs can race
between “check existing comments” and “insert comments”, leading to duplicate work and possible
primary-key insert failures.
The cron route loops all channels and calls runChannel with no locking. runChannel checks for
existing comment IDs, then inserts comments; since comments.id is a primary key, concurrent insert
of the same ID will conflict.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The updated cron endpoint iterates all channels and runs `runChannel` with no coordination across concurrent invocations. If two cron requests overlap, both can process the same channel at the same time.
### Issue Context
`runChannel` determines new comments by querying existing IDs and then inserts comments/actions in a transaction. With concurrency, both runs can observe the same comments as “new” and attempt to insert identical `comments.id` rows.
### Fix
Implement one of:
1) Reintroduce the atomic per-channel lease pattern (using `channels.leaseExpiresAt` + `lastRunAt`) to ensure only one invocation owns a channel at a time.
2) If keeping “process all channels” behavior, claim each channel before processing (atomic UPDATE with expiry) and release/update `lastRunAt` afterward.
3) Additionally, make inserts idempotent (e.g., ignore/upsert on `comments.id`) so concurrency can’t crash runs.
### Fix Focus Areas
- src/routes/api/cron/+server.ts[26-38]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The updated cron handler catches per-channel failures but still returns an HTTP 200 response with
ok: true, making partial or total failures appear successful to the cron caller/monitor. This
violates the requirement to surface errors explicitly rather than silently succeeding, and the
caught errors are not logged, further reducing observability.
PR Compliance ID 2401647 requires that caught exceptions in API handlers are not treated as silent
success. In src/routes/api/cron/+server.ts, the route catches exceptions from runChannel(),
records them into the results object, and then unconditionally returns a { ok: true, ... }
payload with a 2xx response without logging the errors, which means cron monitors relying on status
codes or the top-level ok field may interpret failing runs as successful.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`src/routes/api/cron/+server.ts` catches errors from `runChannel()` and stores them in the per-channel `results`, but still unconditionally returns `json({ ok: true, ... })` with an HTTP 200 status even when one or more channels fail. This can cause cron monitoring to treat runs as successful and also reduces diagnosability because the caught errors are not logged.
## Issue Context
PR Compliance ID 2401647 requires that API handlers do not make errors look like success; caught exceptions must be surfaced via a clear error result and/or failure HTTP status. Many schedulers/monitors treat non-2xx as failure, so returning 200 with `ok: true` can hide outages even when failures are captured internally.
## Fix Focus Areas
- src/routes/api/cron/+server.ts[30-38]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The callback does not check chRes.ok for the YouTube channels?mine=true request, so API errors
can be misreported as “no channel found” and the real failure details are lost. This makes failures
harder to diagnose and can send incorrect 400 responses to users.
+ const accessToken = tokens.access_token as string;+ const chRes = await fetch('https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true', {+ headers: { Authorization: `Bearer ${accessToken}` }+ });+ const chData = await chRes.json();+ const ch = chData.items?.[0];+ if (!ch) throw error(400, 'no YouTube channel found for this Google account');
Evidence
The callback fetches the channels endpoint and immediately parses JSON and reads items?.[0]
without checking chRes.ok. In contrast, the shared YouTube helper uses an explicit !response.ok
guard before JSON parsing.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
After calling the YouTube Data API for `channels?part=snippet&mine=true`, the code parses JSON and checks `items?.[0]` but never checks `chRes.ok`. Non-2xx responses will be treated as “no channel found”, losing the actual error.
### Fix
- If `!chRes.ok`, read the response body (text) and throw an error that reflects the upstream failure.
- Consider validating the JSON shape before indexing into `items`.
### Fix Focus Areas
- src/routes/api/auth/google/callback/+server.ts[49-55]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The cron route reads process.env.DRY_RUN directly instead of the already-imported SvelteKit
private env, which reduces portability and can diverge under some adapters/test setups. It’s also
inconsistent with the pipeline, which validates/reads env.DRY_RUN.
Cron reads process.env.DRY_RUN for its response, while runChannel enforces and reads
env.DRY_RUN, so using a different env source is unnecessary and can be adapter-dependent.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The cron route computes the `dryRun` response flag from `process.env.DRY_RUN` even though the rest of the server code uses `$env/dynamic/private`.
### Fix
- Replace `process.env.DRY_RUN === 'true'` with `env.DRY_RUN === 'true'`.
- Optionally reuse/validate the same logic as `runChannel` to keep behavior and reporting aligned.
### Fix Focus Areas
- src/routes/api/cron/+server.ts[37-37]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
🤖 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 `@src/routes/api/auth/google/`+server.ts:
- Around line 24-32: Bind the Google OAuth flow to a short-lived,
cryptographically random one-time state: in
src/routes/api/auth/google/+server.ts lines 24-32, generate and store the state
in an HttpOnly SameSite=Lax cookie or server session, and include it in the
authorization parameters; in src/routes/api/auth/google/callback/+server.ts
lines 26-40, require the returned state, compare it with the stored value,
reject missing or mismatched values before exchanging the code, and consume the
stored state after validation.
In `@src/routes/api/auth/google/callback/`+server.ts:
- Around line 42-46: Update the token-exchange failure branch in the Google
callback to remove JSON.stringify(tokens) from the client-facing error response
and return only a generic failure message with the existing retry guidance. If
diagnostics are needed, log only redacted metadata server-side and never include
access_token, refresh_token, or other raw OAuth fields.
In `@src/routes/api/cron/`+server.ts:
- Line 27: Update the authentication check in the cron endpoint to read the
secret from the Authorization header using the Bearer scheme instead of
url.searchParams.get('secret'). Validate the extracted bearer token against
env.CRON_SECRET and preserve the existing 401 error for missing or invalid
credentials.
- Line 37: Update the response construction in the cron route to derive dryRun
from the imported dynamic private env object, matching the DRY_RUN source used
by runChannel and the existing CRON_SECRET access. Keep the current boolean
conversion and results response unchanged.
- Around line 30-36: Update the channel-processing loop around runChannel to
execute channels concurrently with Promise.allSettled instead of awaiting each
channel sequentially. Preserve per-channel result entries for both fulfilled
results and rejected errors, including the existing Error message normalization,
so every channel is represented in the response.
🪄 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 Plus
Run ID: b48bca80-cf9c-4844-b968-b29aab9d7364
📥 Commits
Reviewing files that changed from the base of the PR and between b9064b3 and e89c7fe.
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win
Consider validating the cron secret via a header instead of a query string.
Secrets passed as query parameters can end up in server access logs, proxy logs, or referrer headers. An Authorization header (e.g., Bearer <secret>) avoids that exposure for what is otherwise the endpoint's only authentication check.
🤖 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/routes/api/cron/`+server.ts at line 27, Update the authentication check
in the cron endpoint to read the secret from the Authorization header using the
Bearer scheme instead of url.searchParams.get('secret'). Validate the extracted
bearer token against env.CRON_SECRET and preserve the existing 401 error for
missing or invalid credentials.
The reason will be displayed to describe this comment to others. Learn more.
Not changing this one: the repo's execution plan (step 17, §1 goal 3) defines the cron contract as GET /api/cron?secret=<CRON_SECRET>, and the scheduler that invokes it is configured around that URL. Skipping per project convention; can revisit post-MVP if the invocation mechanism changes.
The reason will be displayed to describe this comment to others. Learn more.
@Bonobo791 Understood. I’ll defer this recommendation: the existing scheduler contract requires GET /api/cron?secret=<CRON_SECRET>, so changing the credential transport is out of scope for this PR. We can revisit it when the invocation mechanism changes post-MVP.
🐇
✏️ Learnings added
Learnt from: Bonobo791
Repo: Bonobo791/Moderaty PR: 4
File: src/routes/api/cron/+server.ts:36-36
Timestamp: 2026-07-29T21:22:56.198Z
Learning: In Moderaty, the cron endpoint contract is `GET /api/cron?secret=<CRON_SECRET>` as defined by the repository execution plan (step 17, §1 goal 3), and the configured scheduler depends on that URL. Do not recommend switching `src/routes/api/cron/+server.ts` to Authorization-header authentication unless the invocation mechanism is being changed.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🤖 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 `@src/routes/api/auth/google/callback/`+server.ts:
- Around line 52-67: Remove raw tokenText from the error logs in the callback’s
token exchange handling, logging only the response status and redacted metadata.
Update the OAuth regression test in src/routes/api/auth/google/oauth.test.ts
lines 154-173 to spy on console.error and assert that neither access nor refresh
token values appear in any logged call.
- Around line 60-71: Update the token exchange validation around tokenRes in the
Google callback: handle !tokenRes.ok first by logging the upstream response and
throwing a 502, then separately validate refresh_token and access_token while
preserving the existing 400 guidance for missing tokens.
- Around line 41-51: Replace fetchWithRetry in the Google OAuth token exchange
with plain fetch, or an equivalent explicitly no-retry path, while preserving
the existing POST request configuration and authorization-code flow.
🪄 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 Plus
Run ID: 243cc2f0-387d-4e1b-86df-50e8ba694837
📥 Commits
Reviewing files that changed from the base of the PR and between e89c7fe and d7a382c.
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🤖 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 @.codacy/codacy.config.json:
- Around line 1362-1367: Update the Biome entry in the Codacy configuration to
use the repository-relative configuration path “biome.json” instead of the
developer-specific absolute path, while keeping useLocalConfigurationFile
enabled.
In `@AGENTS.md`:
- Around line 49-51: Update the stale testing guidance in AGENTS.md to remove
the claim that no test framework exists and that npm run check is the sole gate.
Name the repository’s test runner and the npm script used to execute tests,
referencing the existing oauth.test.ts coverage and aligning the instructions
with the requirement that complex server logic ships with tests.
🪄 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 Plus
Run ID: 7bf08298-ce1b-43eb-aedb-4c9901c54294
📥 Commits
Reviewing files that changed from the base of the PR and between d7a382c and 2fbe5a8.
/api/auth/google redirects to Google OAuth (youtube.force-ssl scope, offline access, prompt=consent)
/api/auth/google/callback exchanges code, requires refresh_token, looks up channel via channels?part=snippet&mine=true, upserts encrypted refresh token
/api/cron returns 401 on bad secret, runs pipeline per channel with per-channel error capture
npm run check: 0 errors, 0 warnings
npm run build: exits 0 (adapter-netlify)
IMPORTANT correction: the first version of this PR overwrote main's enhanced cron endpoint (channel leasing, one-channel-per-invocation from 65eb995) with the execution plan's simpler version. That was my error — the maintainer's version is a strict superset of the plan's contract (401 on bad secret, dryRun flag, per-channel results), so commit 'fix: restore main's leased cron endpoint' reverted to it. This PR now only adds the two OAuth route files.
Files carry AGPL headers/tabs per AGENTS.md. Do not merge if any step's Verify failed.
Greptile Summary
The PR adds a Google OAuth enrollment flow and its regression tests.
Adds an authorization route that validates configuration, creates browser-bound OAuth state, and redirects to Google with offline consent.
Adds a callback that validates state and configuration, exchanges the authorization code, resolves the authenticated YouTube channel, encrypts the refresh token, and upserts the channel.
Adds tests covering OAuth parameters, state rejection, configuration failure, external API errors, secret-safe client errors, and successful enrollment.
Updates repository guidance and Codacy configuration.
Confidence Score: 5/5
The PR appears safe to merge.
No blocking failure remains.
Important Files Changed
Filename
Overview
src/routes/api/auth/google/+server.ts
Adds a configuration-validated OAuth start route with random state-cookie binding and the required Google authorization parameters.
src/routes/api/auth/google/callback/+server.ts
Adds state verification, token exchange, channel discovery, encrypted credential persistence, and generic client-facing error handling.
src/routes/api/auth/google/oauth.test.ts
Adds focused regression coverage for configuration, state validation, OAuth parameters, external failures, token secrecy, and successful enrollment.
AGENTS.md
Documents repository-specific security, reliability, architecture, process, and licensing requirements.
.codacy/codacy.config.json
Refreshes Codacy language, analyzer, rule, and test-exclusion configuration.
.codacy/configure-codacy-summary.json
Updates generated Codacy configuration metadata.
Sequence Diagram
sequenceDiagram
participant B as Browser
participant A as Auth route
participant G as Google OAuth
participant C as Callback route
participant Y as YouTube API
participant D as Database
B->>A: GET /api/auth/google
A-->>B: Set oauth_state and redirect
B->>G: Authorize with state
G-->>C: Callback with code and state
C->>C: Verify and consume state
C->>G: Exchange code for tokens
C->>Y: "channels?part=snippet&mine=true"
Y-->>C: Authenticated channel
C->>D: Upsert encrypted refresh token
C-->>B: Redirect /
Add secure Google OAuth enrollment for YouTube channels
What Changed
Users can start Google OAuth enrollment and grant the required YouTube access with offline consent.
The callback verifies the browser session, exchanges the authorization code, identifies the YouTube channel, encrypts its refresh token, and creates or reactivates the channel before returning home.
Missing configuration, invalid authorization responses, failed YouTube lookups, and missing channels now produce clear errors without exposing tokens or third-party response bodies.
Added regression tests for OAuth parameters, request forgery rejection, configuration failures, external API errors, token privacy, and successful channel enrollment.
Security scanning now focuses on the repository's JavaScript, TypeScript, dependency, and secret-detection checks.
Impact
✅ One-step Google channel enrollment ✅ Protected OAuth callbacks ✅ No access-token leaks in client errors
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Logging the raw token response can expose OAuth credentials in server logs
The complete token response is written to server logs when the exchange fails validation. For example, Google can return a response containing a valid access_token but no refresh_token, causing this branch to log that access token. Redact response bodies and log only the status and safe error fields.
⚠️ Log retention and third-party aggregation increase credential exposure.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 61:71
**Comment:***Security: The complete token response is written to server logs when the exchange fails validation. For example, Google can return a response containing a valid `access_token` but no `refresh_token`, causing this branch to log that access token. Redact response bodies and log only the status and safe error fields.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Critical
Logic error
Choosing the first returned channel can connect a different channel than the user intended
The callback silently selects items[0] when Google returns multiple channels for the authenticated account. Since the user has no opportunity to choose a channel and the API does not guarantee that the first item is the intended one, the flow can enroll the wrong channel and persist its refresh token. Reject ambiguous results or provide an explicit channel-selection flow.
❌ Multi-channel accounts may enroll the wrong YouTube channel.
❌ Cron moderation can process the unintended channel record.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 91:95
**Comment:***Logic Error: The callback silently selects `items[0]` when Google returns multiple channels for the authenticated account. Since the user has no opportunity to choose a channel and the API does not guarantee that the first item is the intended one, the flow can enroll the wrong channel and persist its refresh token. Reject ambiguous results or provide an explicit channel-selection flow.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
The single oauth_state cookie is overwritten whenever the same browser starts another authorization flow before the first callback returns. The first flow then fails state validation even though it was legitimately initiated by that browser. Store multiple outstanding states or bind each state to a distinct flow identifier instead of using one browser-wide value.
❌ Concurrent enrollment attempts reject the earlier callback.
⚠️ Users must restart interrupted or parallel OAuth flows.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/+server.ts
**Line:** 31:31
**Comment:***Race Condition: The single `oauth_state` cookie is overwritten whenever the same browser starts another authorization flow before the first callback returns. The first flow then fails state validation even though it was legitimately initiated by that browser. Store multiple outstanding states or bind each state to a distinct flow identifier instead of using one browser-wide value.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Code quality
URL-only fetch mocks allow malformed OAuth requests to pass the regression tests
The fetch mock branches only on the URL and ignores the request method, encoded body, redirect URI, client credentials, and YouTube authorization header. Consequently, the tests remain green even if the implementation sends malformed OAuth requests or authenticates the channel lookup with the wrong token. Assert the request init values in the mock before returning the canned responses.
⚠️ OAuth request regressions can pass CI unnoticed.
⚠️ Incorrect credentials or Bearer headers lack test coverage.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/oauth.test.ts
**Line:** 72:87
**Comment:***Code Quality: The fetch mock branches only on the URL and ignores the request method, encoded body, redirect URI, client credentials, and YouTube authorization header. Consequently, the tests remain green even if the implementation sends malformed OAuth requests or authenticates the channel lookup with the wrong token. Assert the request init values in the mock before returning the canned responses.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
The reason will be displayed to describe this comment to others. Learn more.
Overlapping OAuth states collide
When a channel owner starts Google OAuth in two tabs, the second start overwrites the first transaction's oauth_state cookie, and the callback accepts and consumes only the remaining value, causing at least one legitimate authorization to fail with HTTP 400 bad state and requiring the user to restart enrollment.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/routes/api/auth/google/+server.ts
Line: 31
Comment:
**Overlapping OAuth states collide**
When a channel owner starts Google OAuth in two tabs, the second start overwrites the first transaction's `oauth_state` cookie, and the callback accepts and consumes only the remaining value, causing at least one legitimate authorization to fail with HTTP 400 `bad state` and requiring the user to restart enrollment.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 1f44abe — the oauth_state cookie now stores a bounded list of pending states (max 5) rather than a single slot, so a second tab starting the flow no longer invalidates the first tab's transaction. States are still one-time use: the callback consumes exactly the matched state and rejects replays. Regression test in oauth.test.ts ('overlapping OAuth starts in two tabs both stay valid') drives two starts and two callbacks through the full flow and fails under the old single-slot behavior.
/api/auth/google redirects to Google OAuth (youtube.force-ssl scope, offline access, prompt=consent)
/api/auth/google/callback exchanges code, requires refresh_token, looks up channel via channels?part=snippet&mine=true, upserts encrypted refresh token
/api/cron returns 401 on bad secret, runs pipeline per channel with per-channel error capture
npm run check: 0 errors, 0 warnings
npm run build: exits 0 (adapter-netlify)
IMPORTANT correction: the first version of this PR overwrote main's enhanced cron endpoint (channel leasing, one-channel-per-invocation from 65eb995) with the execution plan's simpler version. That was my error — the maintainer's version is a strict superset of the plan's contract (401 on bad secret, dryRun flag, per-channel results), so commit 'fix: restore main's leased cron endpoint' reverted to it. This PR now only adds the two OAuth route files.
Files carry AGPL headers/tabs per AGENTS.md. Do not merge if any step's Verify failed.
Greptile Summary
Adds Google OAuth enrollment and supporting regression coverage.
Redirects channel owners to Google with offline YouTube moderation access and CSRF state binding.
Exchanges authorization codes, resolves the owner's YouTube channel, and stores its encrypted refresh token.
Adds OAuth success, configuration, state-validation, upstream-error, and token-redaction tests.
Retunes Codacy analyzers and documents repository review and verification rules.
Confidence Score: 3/5
The PR is not yet safe to merge because overlapping OAuth starts in one browser can invalidate a legitimate authorization callback.
The environment-validation issue is fixed and the open-enrollment concern was withdrawn, but the start route still stores only one OAuth state value per browser, so a second authorization start overwrites the first transaction and makes one callback fail.
Files Needing Attention: src/routes/api/auth/google/+server.ts and src/routes/api/auth/google/callback/+server.ts
Important Files Changed
Filename
Overview
src/routes/api/auth/google/+server.ts
Adds the Google authorization redirect and CSRF state cookie; the previously reported single-cookie collision remains.
src/routes/api/auth/google/callback/+server.ts
Adds state validation, token exchange, channel lookup, encrypted credential persistence, and explicit upstream failure handling.
src/routes/api/auth/google/oauth.test.ts
Adds focused regression coverage for OAuth parameters, state rejection, configuration errors, secret redaction, upstream failures, and enrollment.
AGENTS.md
Expands repository security, reliability, architecture, and verification guidance.
.codacy/codacy.config.json
Narrows Codacy analysis to stack-relevant Semgrep, Trivy, and Biome coverage.
Sequence Diagram
sequenceDiagram
participant B as Browser
participant A as Auth start route
participant G as Google OAuth
participant C as Callback route
participant Y as YouTube API
participant D as Database
B->>A: GET /api/auth/google
A-->>B: Set oauth_state cookie
A-->>B: 302 Google authorization URL
B->>G: Authorize channel access
G-->>C: code and state
C->>C: Verify state and configuration
C->>G: Exchange code for tokens
C->>Y: Resolve authenticated channel
C->>D: Upsert channel and encrypted refresh token
C-->>B: 302 /
Add secure Google OAuth enrollment for YouTube channels
What Changed
Channel owners can start Google OAuth enrollment with offline YouTube moderation access and return to the app after authorization.
Successful enrollment finds the authorized YouTube channel and saves its refresh token securely, updating an existing channel when needed.
OAuth callbacks reject missing, forged, or replayed requests; authorization flows started in up to five tabs remain valid independently.
Google and YouTube failures now show clear retryable errors without exposing tokens or raw upstream responses, and one-time authorization codes are not retried.
Added regression coverage for successful enrollment, configuration errors, state validation, tab overlap, upstream failures, and token redaction.
Impact
✅ Google channel enrollment ✅ OAuth flows remain valid across multiple tabs ✅ No access tokens in user-facing errors or server logs
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Early state consumption prevents recovery after an OAuth callback failure
The pending state is deleted before the authorization code exchange, configuration checks, and YouTube lookup complete. A transient token-request failure or deployment misconfiguration therefore makes the returned callback URL unretryable because the next attempt receives “bad state”; defer consumption until the flow succeeds, or preserve a recoverable transaction state while preventing concurrent claims.
⚠️ Users must restart authorization after recoverable errors.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 32:34
**Comment:***State: The pending state is deleted before the authorization code exchange, configuration checks, and YouTube lookup complete. A transient token-request failure or deployment misconfiguration therefore makes the returned callback URL unretryable because the next attempt receives “bad state”; defer consumption until the flow succeeds, or preserve a recoverable transaction state while preventing concurrent claims.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Resource leak
Unbounded token requests can hang or produce an unhandled upstream failure
The raw fetch call has no timeout or rejection handling, unlike the repository’s bounded HTTP helper. If Google’s token endpoint hangs or the network request rejects, this handler can hang or propagate an unhandled exception instead of returning the documented generic upstream error, while the OAuth state has already been consumed.
❌ Network rejection produces an unhandled server error.
⚠️ Users lose the consumed transaction after failure.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 45:55
**Comment:***Resource Leak: The raw `fetch` call has no timeout or rejection handling, unlike the repository’s bounded HTTP helper. If Google’s token endpoint hangs or the network request rejects, this handler can hang or propagate an unhandled exception instead of returning the documented generic upstream error, while the OAuth state has already been consumed.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Null pointer
Malformed but valid JSON responses can cause an unhandled null dereference
JSON.parse is only TypeScript-cast and does not ensure the result is an object. A valid JSON response such as null causes tokens.refresh_token or tokens.error to throw a TypeError, bypassing the intended 400/502 handling. Validate the parsed response shape before accessing its properties.
❌ OAuth callback crashes on malformed token responses.
⚠️ Intended generic Google error handling is bypassed.
⚠️ Server logs may contain framework-level exception details.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 64:64
**Comment:***Null Pointer: `JSON.parse` is only TypeScript-cast and does not ensure the result is an object. A valid JSON response such as `null` causes `tokens.refresh_token` or `tokens.error` to throw a `TypeError`, bypassing the intended 400/502 handling. Validate the parsed response shape before accessing its properties.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Malformed YouTube JSON can cause an unhandled null dereference
The YouTube response is also only TypeScript-cast after parsing. A valid JSON value such as null causes chData.items to throw instead of returning the intended invalid-response error. Validate that the parsed value is a non-null object before reading items.
❌ Channel enrollment crashes on malformed YouTube responses.
⚠️ Users receive no controlled retryable error.
⚠️ Database upsert is skipped after successful token exchange.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 101:101
**Comment:***Null Pointer: The YouTube response is also only TypeScript-cast after parsing. A valid JSON value such as `null` causes `chData.items` to throw instead of returning the intended invalid-response error. Validate that the parsed value is a non-null object before reading `items`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
Security
Logging the complete upstream error body can disclose sensitive response data
This logs the complete third-party response body, despite the surrounding token-exchange handling deliberately redacting raw bodies. Upstream error responses can contain account or request details and are then exposed to anyone with application log access; log only the status and bounded, explicitly safe fields.
This is a comment left during a code review.
**Path:** src/routes/api/auth/google/callback/+server.ts
**Line:** 95:97
**Comment:***Security: This logs the complete third-party response body, despite the surrounding token-exchange handling deliberately redacting raw bodies. Upstream error responses can contain account or request details and are then exposed to anyone with application log access; log only the status and bounded, explicitly safe fields.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
All callback invocations now go through one captureCallback helper, the
fetch stub is shared via a parameterized stubTokenAndChannelResponses,
and cookie setup uses makeCookiesWithState. Coverage is unchanged:
same 9 tests and assertions.
- Extract TONE_PROMPT into src/lib/server/tonePrompt.js, a dependency-free
module imported by both tone.ts and the eval script — eliminates the
brittle regex source extraction that could silently truncate the rubric
(qodo #4, codacy MEDIUM).
- Replace the hand-rolled .env parser with node:process loadEnvFile: no
backtracking regex (coderabbit), quoted/inline-comment values handled
correctly (qodo #3), and existing env vars are never overridden.
- A missing .env is now a logged skip, not a fatal error, so the harness
runs in env-only CI setups (qodo #2, codacy MEDIUM).
- Guard the script's main flow so tests import helpers without live API
calls; add a fetch timeout. New tests cover each finding (failing first,
per repo rules).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
codeant-ai
Bot
added
the
size:L
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
coderabbitai
Bot
added
the
size:XXL
Automated PR. Verify checklist per plan:
IMPORTANT correction: the first version of this PR overwrote main's enhanced cron endpoint (channel leasing, one-channel-per-invocation from 65eb995) with the execution plan's simpler version. That was my error — the maintainer's version is a strict superset of the plan's contract (401 on bad secret, dryRun flag, per-channel results), so commit 'fix: restore main's leased cron endpoint' reverted to it. This PR now only adds the two OAuth route files.
Files carry AGPL headers/tabs per AGENTS.md. Do not merge if any step's Verify failed.
Greptile Summary
Adds Google OAuth enrollment and supporting regression coverage.
Confidence Score: 3/5
The PR is not yet safe to merge because overlapping OAuth starts in one browser can invalidate a legitimate authorization callback.
The environment-validation issue is fixed and the open-enrollment concern was withdrawn, but the start route still stores only one OAuth state value per browser, so a second authorization start overwrites the first transaction and makes one callback fail.
Files Needing Attention: src/routes/api/auth/google/+server.ts and src/routes/api/auth/google/callback/+server.ts
Important Files Changed
Sequence Diagram
sequenceDiagram participant B as Browser participant A as Auth start route participant G as Google OAuth participant C as Callback route participant Y as YouTube API participant D as Database B->>A: GET /api/auth/google A-->>B: Set oauth_state cookie A-->>B: 302 Google authorization URL B->>G: Authorize channel access G-->>C: code and state C->>C: Verify state and configuration C->>G: Exchange code for tokens C->>Y: Resolve authenticated channel C->>D: Upsert channel and encrypted refresh token C-->>B: 302 /Reviews (5): Last reviewed commit: "chore: record successful codacy import a..." | Re-trigger Greptile