fix(csrf): resolve all 124 SonarQube CSRF security hotspots - #304
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 13 minutes and 25 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (39)
WalkthroughThis pull request systematically removes explicit HTTP Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
…handles preflight (S3752)
…ce complexity (S3776)
772a680 to
be37a85
Compare
|
❌ The last analysis has failed. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (21)
server/routes/ci_shared.py (1)
19-19: 🧹 Nitpick | 🔵 TrivialInconsistent OPTIONS cleanup — strip
"OPTIONS"from the GET route too.The PR's stated intent is to drop redundant
"OPTIONS"frommethods=so Flask + Flask-CORS handle preflight automatically, and the@require_permissiondecorator also short-circuitsOPTIONSviacreate_cors_response()as defense-in-depth. Line 25 follows this pattern forPUT, but line 19 still declares"OPTIONS"onGET /rca-settings. Since both handlers are registered on the same URL rule, this leaves preflight behavior wired through the GET handler for this path only, which is inconsistent with the rest of the 117-route cleanup done in this PR.♻️ Suggested consistency fix
- `@blueprint.route`("/rca-settings", methods=["GET", "OPTIONS"]) + `@blueprint.route`("/rca-settings", methods=["GET"]) `@require_permission`("connectors", "read") def get_rca_settings(user_id):Based on learnings: "Applies to server/connectors/**/*.py : Do not manually call get_user_id_from_request() or handle OPTIONS in connector routes decorated with require_permission" — the same principle is being applied across
server/routes/**in this PR.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/ci_shared.py` at line 19, The GET route decorated with `@blueprint.route`("/rca-settings", methods=["GET", "OPTIONS"]) is inconsistent with the rest of the refactor; remove "OPTIONS" from the methods list so it becomes methods=["GET"] (letting Flask/Flask-CORS and the require_permission/create_cors_response flow handle preflight), mirroring the PUT handler change and keeping preflight behavior consistent for the "/rca-settings" route.server/routes/azure/azure_routes.py (1)
77-81:⚠️ Potential issue | 🟠 MajorMissed OPTIONS cleanup contradicts the PR's stated objective.
Per the PR description, this is one of the three routes targeted for CSRF / preflight cleanup ("azure/fetch_data ... GET scoped to read"), yet
OPTIONSis still declared inmethods=and the handler still branches onrequest.method == 'OPTIONS'to callcreate_cors_response(). Flask‑CORS should handle preflight automatically, consistent with the treatment applied to the other 117 routes in this PR. Please drop both the method entry and the branch (and thencreate_cors_responsewill no longer be referenced from this function).🔧 Suggested fix
-@azure_bp.route("/azure/fetch_data", methods=["GET", "OPTIONS"]) +@azure_bp.route("/azure/fetch_data", methods=["GET"]) `@require_permission`("connectors", "read") def fetch_data(user_id): - if flask.request.method == 'OPTIONS': - return create_cors_response() try:Based on learnings: "Applies to server/connectors/**/*.py : Do not manually call get_user_id_from_request() or handle OPTIONS in connector routes decorated with require_permission" (the same pattern is the explicit goal of this PR for
server/routes/**).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/azure/azure_routes.py` around lines 77 - 81, The route handler azure_bp.route("/azure/fetch_data", methods=["GET", "OPTIONS"]) should be simplified to only handle GET: remove "OPTIONS" from the methods list and delete the branch that checks flask.request.method == 'OPTIONS' and calls create_cors_response() inside fetch_data; leave the require_permission("connectors", "read") decorator and the GET logic intact so Flask‑CORS handles preflight automatically and create_cors_response is no longer referenced from this function.server/routes/netdata/netdata_routes.py (1)
12-12:⚠️ Potential issue | 🟡 MinorRemove unused
create_cors_responseimport.
create_cors_responseis not referenced anywhere in the file afterOPTIONShandlers were removed. Remove this unused import to clean up the file.♻️ Proposed fix
-from utils.web.cors_utils import create_cors_response from utils.auth.token_management import get_token_data, store_tokens_in_db🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/netdata/netdata_routes.py` at line 12, Remove the unused import create_cors_response from the top-level imports (the import statement referencing utils.web.cors_utils and create_cors_response) in netdata_routes.py; simply delete that identifier from the import line (or remove the entire import if nothing else is imported from utils.web.cors_utils) so no unused symbols remain.server/routes/thousandeyes/thousandeyes_routes.py (1)
15-15:⚠️ Potential issue | 🟡 MinorRemove unused
create_cors_responseimport.The import at line 15 is not referenced anywhere in the file and should be dropped to clean up orphaned imports.
Proposed fix
-from utils.web.cors_utils import create_cors_response from utils.auth.rbac_decorators import require_permission🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/thousandeyes/thousandeyes_routes.py` at line 15, Remove the unused import create_cors_response from the top of the file: locate the import statement that references create_cors_response and delete it so there are no orphaned imports; ensure no other references to create_cors_response exist in the module (e.g., in route handlers or helper functions) before committing the change.server/routes/cloudbees/cloudbees_routes.py (1)
16-16:⚠️ Potential issue | 🟡 MinorRemove unused
create_cors_responseimport.The
create_cors_responsefunction is imported at line 16 but is not referenced anywhere in this file. Since the PR removed similar orphaned imports from other route files, this one should be removed for consistency.Proposed fix
-from utils.web.cors_utils import create_cors_response from utils.web.webhook_signature import SIGNATURE_HEADER, verify_webhook_signature🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/cloudbees/cloudbees_routes.py` at line 16, The import create_cors_response is unused in this module; remove the offending import statement that references create_cors_response to eliminate the orphaned import and keep imports consistent with other route files—search for the symbol create_cors_response in this file and delete its import line (from utils.web.cors_utils import create_cors_response).server/routes/opsgenie/opsgenie_routes.py (1)
14-14: 🧹 Nitpick | 🔵 TrivialRemove unused
create_cors_responseimport.After the
OPTIONSbranches were removed,create_cors_responseis no longer referenced. Drop it to clean up orphaned imports.♻️ Proposed fix
-from utils.web.cors_utils import create_cors_response from utils.auth.token_management import get_token_data, store_tokens_in_db🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/opsgenie/opsgenie_routes.py` at line 14, The import create_cors_response in opsgenie_routes.py is no longer used; remove it from the top-level import statement (delete the create_cors_response symbol or the entire import line if it only contained that symbol) so the file no longer has an orphaned import; ensure there are no other references to create_cors_response in functions or route handlers before committing.server/routes/github/github.py (1)
499-511: 🧹 Nitpick | 🔵 TrivialAd-hoc CORS headers in
download_github_repoviolate coding guidelines.While outside this diff, this hand-rolled CORS block is inconsistent with the PR theme and still advertises
Access-Control-Allow-Methods: 'GET, POST, OPTIONS'even though the route decorator is now POST-only after your change on line 444. Consider removing these manual headers and letting Flask-CORS populate them — or at minimum update theAllow-Methodsvalue to reflect that onlyPOSTis supported.As per coding guidelines: "Use centralized CORS utility for CORS handling (never add ad-hoc Access-Control-* headers in route files)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/github/github.py` around lines 499 - 511, The download_github_repo route currently sets ad-hoc CORS headers on response_data (Access-Control-Allow-Origin/Headers/Methods/Credentials) which violates the centralized CORS policy; remove this manual CORS block from download_github_repo and let the centralized Flask-CORS utility manage CORS, or if you must keep local headers temporarily, at minimum change the Access-Control-Allow-Methods value to only include POST and ensure Origin handling uses the centralized allowed origins list rather than inline os.getenv; reference the download_github_repo function and the response_data variable to locate and remove/update the header-setting code.server/routes/coroot/coroot_routes.py (1)
16-16: 🧹 Nitpick | 🔵 TrivialOrphaned
create_cors_responseimport.After the OPTIONS removals in
/connectand/disconnect,create_cors_responseis no longer referenced anywhere in this file. Per the PR summary ("Removed three now-orphaned create_cors_response imports"), this file appears to have been missed — please remove the import for consistency.♻️ Proposed cleanup
-from utils.web.cors_utils import create_cors_response🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/coroot/coroot_routes.py` at line 16, Remove the now-orphaned import "create_cors_response" from the top of the file (the line reading "from utils.web.cors_utils import create_cors_response") because OPTIONS handling for "/connect" and "/disconnect" was removed and this symbol is no longer referenced; simply delete that import to keep imports consistent and avoid unused-import warnings.server/routes/jenkins/jenkins_routes.py (1)
11-11:⚠️ Potential issue | 🟡 MinorRemove orphaned
create_cors_responseimport.The import on line 11 is unused and should be removed.
Diff
-from utils.web.cors_utils import create_cors_response🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/jenkins/jenkins_routes.py` at line 11, Remove the unused import create_cors_response from utils.web.cors_utils in the jenkins_routes module; locate the import statement "from utils.web.cors_utils import create_cors_response" and delete it so the file no longer contains the orphaned symbol and linter warnings are resolved.server/routes/grafana/grafana_routes.py (1)
10-10:⚠️ Potential issue | 🟡 MinorRemove orphaned
create_cors_responseimport.The import at line 10 is no longer used anywhere in this file. After removing the OPTIONS branches from handlers, this dependency should be dropped.
♻️ Proposed cleanup
-from utils.web.cors_utils import create_cors_response🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/grafana/grafana_routes.py` at line 10, Remove the now-unused import create_cors_response from the top of the module to eliminate the orphaned dependency; locate the import statement that reads "from utils.web.cors_utils import create_cors_response" and delete it so the module no longer imports create_cors_response (verify no other references to create_cors_response remain in functions or handlers such as any OPTIONS branches you removed).server/routes/cloudflare/cloudflare_routes.py (1)
123-123:⚠️ Potential issue | 🟡 MinorGET routes still list
"OPTIONS"— inconsistent with the rest of the file.
POST /cloudflare/connect,POST /cloudflare/zones, andPOST /cloudflare/disconnectwere narrowed correctly, butGET /cloudflare/zones(Line 123) andGET /cloudflare/status(Line 210) still havemethods=['GET', 'OPTIONS']. Per the PR objective, these should be trimmed too so Flask‑CORS handles preflight uniformly.-@cloudflare_bp.route('/cloudflare/zones', methods=['GET', 'OPTIONS']) +@cloudflare_bp.route('/cloudflare/zones', methods=['GET']) ... -@cloudflare_bp.route('/cloudflare/status', methods=['GET', 'OPTIONS']) +@cloudflare_bp.route('/cloudflare/status', methods=['GET'])Also applies to: 210-210
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/cloudflare/cloudflare_routes.py` at line 123, The GET routes still include 'OPTIONS' in their route decorators; update the cloudflare_bp.route declarations for the GET endpoints (specifically the '/cloudflare/zones' and '/cloudflare/status' route decorators) to remove 'OPTIONS' so their methods lists are just ['GET'], allowing Flask-CORS to handle preflight uniformly like the POST routes were updated.server/routes/confluence/confluence_routes.py (1)
25-25:⚠️ Potential issue | 🟡 Minor
/statusstill has the"OPTIONS"method +create_cors_response()branch.
/connect,/disconnect,/fetch, and/parsewere correctly cleaned, butstatus(Lines 272‑277) still declaresmethods=["GET", "OPTIONS"]and retains theif request.method == "OPTIONS": return create_cors_response()early return. This is the only remaining reasoncreate_cors_responseis imported on Line 25. Either finish the cleanup here, or the file ends up in a mixed state inconsistent with the rest of the PR.-@confluence_bp.route("/status", methods=["GET", "OPTIONS"]) +@confluence_bp.route("/status", methods=["GET"]) `@require_permission`("connectors", "read") def status(user_id): """Check Confluence connection status.""" - if request.method == "OPTIONS": - return create_cors_response() - creds = _get_stored_confluence_credentials(user_id)Then drop the now‑unused
from utils.web.cors_utils import create_cors_responseon Line 25.Also applies to: 272-277
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/confluence/confluence_routes.py` at line 25, The /status route still handles "OPTIONS" and calls create_cors_response; update the route decorator for the status endpoint to only declare methods=["GET"] and remove the early branch that checks request.method == "OPTIONS" and returns create_cors_response(), and then delete the now-unused import create_cors_response from the top of the file; locate the status view (the function handling the "/status" route) and remove the OPTIONS handling and import to match the cleanup done for /connect, /disconnect, /fetch, and /parse.server/routes/notion/notion_routes.py (1)
206-206:⚠️ Potential issue | 🟡 MinorLeftover
"OPTIONS"on GET routes breaks the PR's consistency goal.
/connect,/oauth/callback, and/disconnectwere correctly narrowed, but/status(Line 206),/databases(Line 323), and/databases/<db_id>(Line 386) still declaremethods=["GET", "OPTIONS"]. Per the PR objective (stripOPTIONSfrom all ~117 routes so Flask‑CORS handles preflight), these should be updated as well — otherwise the file has a mixed pattern that future readers will find confusing.-@notion_bp.route("/status", methods=["GET", "OPTIONS"]) +@notion_bp.route("/status", methods=["GET"]) ... -@notion_bp.route("/databases", methods=["GET", "OPTIONS"]) +@notion_bp.route("/databases", methods=["GET"]) ... -@notion_bp.route("/databases/<db_id>", methods=["GET", "OPTIONS"]) +@notion_bp.route("/databases/<db_id>", methods=["GET"])Also applies to: 323-323, 386-386
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/notion/notion_routes.py` at line 206, Routes for `@notion_bp.route`("/status"), `@notion_bp.route`("/databases") and `@notion_bp.route`("/databases/<db_id>") still include "OPTIONS" in their methods list which contradicts the PR goal to let Flask‑CORS handle preflight; edit each route decorator to remove "OPTIONS" so the methods array only lists the actual HTTP verbs (e.g., "GET") used by the view functions (status, databases, databases/<db_id>), keeping the rest of the decorator and function body unchanged.server/routes/knowledge_base/routes.py (1)
68-73:⚠️ Potential issue | 🟡 MinorPartial OPTIONS cleanup: GET handlers still register and branch on
OPTIONS.The write-side endpoints (
PUT /memory,POST /upload,DELETE /documents/<doc_id>,POST /search) were correctly cleaned, but the read-side GETs (get_memory,list_documents,get_document) still declaremethods=["GET", "OPTIONS"]and retain the in-handlerif request.method == "OPTIONS": return create_cors_response()branch. This leaves the file in a mixed state that contradicts the PR's stated goal of letting Flask‑CORS handle preflight uniformly, and it's the only remaining reasoncreate_cors_responseis still imported on Line 19.🧹 Suggested diff
-@knowledge_base_bp.route("/memory", methods=["GET", "OPTIONS"]) +@knowledge_base_bp.route("/memory", methods=["GET"]) `@require_permission`("knowledge_base", "read") def get_memory(user_id): """Get the org's knowledge base memory content.""" - if request.method == "OPTIONS": - return create_cors_response() - org_id = get_org_id_from_request() @@ -@knowledge_base_bp.route("/documents", methods=["GET", "OPTIONS"]) +@knowledge_base_bp.route("/documents", methods=["GET"]) `@require_permission`("knowledge_base", "read") def list_documents(user_id): """List all documents for the user.""" - if request.method == "OPTIONS": - return create_cors_response() - org_id = get_org_id_from_request() @@ -@knowledge_base_bp.route("/documents/<doc_id>", methods=["GET", "OPTIONS"]) +@knowledge_base_bp.route("/documents/<doc_id>", methods=["GET"]) `@require_permission`("knowledge_base", "read") def get_document(user_id, doc_id: str): """Get a specific document's details.""" - if request.method == "OPTIONS": - return create_cors_response() - org_id = get_org_id_from_request()Then the
from utils.web.cors_utils import create_cors_responseimport on Line 19 can be removed.Also applies to: 165-170, 367-372
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/knowledge_base/routes.py` around lines 68 - 73, GET handlers get_memory, list_documents, and get_document still declare methods=["GET", "OPTIONS"] and contain in-handler branches returning create_cors_response; remove OPTIONS from the route decorators for these functions (e.g., `@knowledge_base_bp.route`("/memory", methods=["GET"]), `@knowledge_base_bp.route`("/documents", methods=["GET"]) and `@knowledge_base_bp.route`("/documents/<doc_id>", methods=["GET"]) as applicable), delete the in-handler checks "if request.method == 'OPTIONS': return create_cors_response()" from those functions, and then remove the now-unused import create_cors_response from the top of the file to finish the cleanup.server/routes/command_policies.py (1)
46-50:⚠️ Potential issue | 🟡 MinorTwo GET routes still register
"OPTIONS"and short-circuit with ad-hocjsonify({}), 200.
list_policies(Lines 46‑50) andlist_templates(Lines 286‑290) were missed by this PR: they still declaremethods=["GET", "OPTIONS"]and return an empty JSON body forOPTIONS. This both contradicts the PR objective of letting Flask‑CORS handle preflight, and it's an ad‑hoc response path that bypasses the project's centralized CORS utility.-@command_policies_bp.route("/command-policies", methods=["GET", "OPTIONS"]) +@command_policies_bp.route("/command-policies", methods=["GET"]) `@require_auth_only` def list_policies(user_id): - if request.method == "OPTIONS": - return jsonify({}), 200 - org_id = get_org_id_from_request() @@ -@command_policies_bp.route("/command-policy-templates", methods=["GET", "OPTIONS"]) +@command_policies_bp.route("/command-policy-templates", methods=["GET"]) `@require_auth_only` def list_templates(user_id): - if request.method == "OPTIONS": - return jsonify({}), 200 - templates = get_policy_templates()As per coding guidelines ("Use centralized CORS utility for CORS handling (never add ad-hoc Access-Control-* headers in route files)"), these ad‑hoc preflight responses should be removed so the CORS layer handles it.
Also applies to: 286-290
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/command_policies.py` around lines 46 - 50, Remove the ad-hoc preflight handling from the route definitions and let the centralized CORS utility handle OPTIONS: in the list_policies and list_templates route handlers remove "OPTIONS" from the methods=["GET", "OPTIONS"] declaration (make them GET-only) and delete the request.method == "OPTIONS" conditional and its jsonify({}), 200 return so the handler no longer short-circuits preflight responses.server/routes/bigpanda/bigpanda_routes.py (1)
16-16:⚠️ Potential issue | 🟡 MinorRemove unused import and complete OPTIONS cleanup for consistency.
The import
create_cors_response(line 16) is unused in this file and should be removed. Additionally, routes on lines 72 and 167 still declare"OPTIONS"in their methods, while the PR removes OPTIONS handling elsewhere to let Flask-CORS handle preflight automatically. Bring these two routes into alignment:
- Line 72: Change
methods=["GET", "OPTIONS"]tomethods=["GET"]- Line 167: Change
methods=["GET", "OPTIONS"]tomethods=["GET"]- Line 16: Remove the import statement
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/bigpanda/bigpanda_routes.py` at line 16, Remove the unused import create_cors_response from the top of the file and update the two route decorators that currently declare methods=["GET", "OPTIONS"] so they only declare methods=["GET"] (i.e., remove "OPTIONS" from those methods arrays) to let Flask-CORS handle preflight automatically; search for the import name create_cors_response to delete and for route decorators containing methods=["GET", "OPTIONS"] to change to methods=["GET"] so both locations are updated consistently.server/routes/spinnaker/spinnaker_routes.py (1)
17-17:⚠️ Potential issue | 🟡 MinorRemove orphaned
create_cors_responseimport and trimOPTIONSfrom GET routes for consistency.The POST/DELETE endpoints and
/webhook/<user_id>were correctly narrowed in this PR, but every GET route still declaresmethods=["GET", "OPTIONS"]despite none of them using the CORS utility. Remove the now-unused import on line 17 and trimOPTIONSfrom/status,/applications,/applications/<app>/pipelines,/applications/<app>/pipeline-configs,/applications/<app>/health,/webhook-url, and/deployments.Suggested diff
-from utils.web.cors_utils import create_cors_response @@ -@spinnaker_bp.route("/status", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/status", methods=["GET"]) @@ -@spinnaker_bp.route("/applications", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/applications", methods=["GET"]) @@ -@spinnaker_bp.route("/applications/<app>/pipelines", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/applications/<app>/pipelines", methods=["GET"]) @@ -@spinnaker_bp.route("/applications/<app>/pipeline-configs", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/applications/<app>/pipeline-configs", methods=["GET"]) @@ -@spinnaker_bp.route("/applications/<app>/health", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/applications/<app>/health", methods=["GET"]) @@ -@spinnaker_bp.route("/webhook-url", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/webhook-url", methods=["GET"]) @@ -@spinnaker_bp.route("/deployments", methods=["GET", "OPTIONS"]) +@spinnaker_bp.route("/deployments", methods=["GET"])🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/spinnaker/spinnaker_routes.py` at line 17, Remove the unused create_cors_response import (symbol: create_cors_response) and update the GET route decorators so they only specify "GET" (remove "OPTIONS") for the endpoints handling /status, /applications, /applications/<app>/pipelines, /applications/<app>/pipeline-configs, /applications/<app>/health, /webhook-url, and /deployments; keep POST/DELETE and the /webhook/<user_id> route as-is. Ensure no other code references create_cors_response before deleting the import and run tests/lint to confirm no unused-import warnings remain.server/routes/datadog/datadog_routes.py (1)
12-12:⚠️ Potential issue | 🟡 MinorRemove OPTIONS from GET routes and the orphaned
create_cors_responseimport.Connector routes decorated with
@require_permissionshould not manually handle OPTIONS. The five GET endpoints (/status,/events,/monitors,/events/ingested,/webhook-url) still declaremethods=["GET", "OPTIONS"], and thecreate_cors_responseimport on line 12 is no longer called anywhere in this file.Suggested diff
-from utils.web.cors_utils import create_cors_response @@ -@datadog_bp.route("/status", methods=["GET", "OPTIONS"]) +@datadog_bp.route("/status", methods=["GET"]) @@ -@datadog_bp.route("/events", methods=["GET", "OPTIONS"]) +@datadog_bp.route("/events", methods=["GET"]) @@ -@datadog_bp.route("/monitors", methods=["GET", "OPTIONS"]) +@datadog_bp.route("/monitors", methods=["GET"]) @@ -@datadog_bp.route("/events/ingested", methods=["GET", "OPTIONS"]) +@datadog_bp.route("/events/ingested", methods=["GET"]) @@ -@datadog_bp.route("/webhook-url", methods=["GET", "OPTIONS"]) +@datadog_bp.route("/webhook-url", methods=["GET"])🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/datadog/datadog_routes.py` at line 12, Remove the unused import create_cors_response and stop manually handling OPTIONS on GET connector endpoints: delete the from utils.web.cors_utils import create_cors_response line and change the route decorators for the five GET handlers (the functions handling /status, /events, /monitors, /events/ingested, /webhook-url) to only declare methods=["GET"] (remove "OPTIONS"); keep the existing `@require_permission` decorators unchanged so framework CORS/OPTIONS handling is used automatically.server/routes/org_routes.py (1)
244-244: 🧹 Nitpick | 🔵 TrivialInconsistent OPTIONS cleanup remaining on six sibling routes.
This file still registers
OPTIONSand keeps theif request.method == "OPTIONS": return jsonify({}), 200short-circuit on/current(244),/PATCH (298),/my-invitations(502),/stats(880),/activity(928), and/preferencesGET (1039). The PATCH on line 298 is a mutating route, so Sonar S3752/S4502 may still flag it. For the stated consistency goal of the PR, consider dropping"OPTIONS"from thesemethods=lists and removing the in-handler early return, matching the treatment applied to the other routes in this file.Also applies to: 298-298, 502-502, 880-880, 928-928, 1039-1039
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/org_routes.py` at line 244, Remove the explicit OPTIONS handling and the in-handler OPTIONS short-circuit from the six routes to match the rest of the file: update the decorators for the routes registered as `@org_bp.route`("/current", methods=["GET", "OPTIONS"]), the PATCH route at `@org_bp.route`("/", methods=["PATCH","OPTIONS"]) (and the sibling routes for "/my-invitations", "/stats", "/activity", and the GET "/preferences") to drop "OPTIONS" from their methods lists, and delete the corresponding if request.method == "OPTIONS": return jsonify({}), 200 early-return blocks inside those view functions so normal Flask/CORS handling will apply. Ensure you only remove the OPTIONS entries and short-circuit logic; leave the route names and other behavior unchanged.server/routes/aws/onboarding.py (1)
27-27: 🧹 Nitpick | 🔵 TrivialInconsistency: several GET routes in this file still carry explicit
OPTIONS+create_cors_response().The PR removes explicit preflight handling from the POST/DELETE routes here (
set_aws_role,workspace_cleanup,bulk_register_aws_accounts,delete_aws_account,reconnect_aws_account), relying on Flask + Flask-CORS to auto-handleOPTIONS. However, the surrounding GET routes in the same file (check_aws_environment,get_aws_onboarding_links,get_aws_onboarding_status,list_user_workspaces,list_aws_accounts,list_inactive_aws_accounts,get_cfn_template,get_cfn_quickcreate_link) still include'OPTIONS'in theirmethods=list and short-circuit withcreate_cors_response().Mixing both patterns within the same blueprint is surprising for future maintainers and means
create_cors_responsecannot yet be removed from the imports in this file. Consider applying the same cleanup to the remaining GET routes for consistency, or add a brief comment explaining why they are intentionally left as-is (e.g., out of SonarQube S3752 scope).Also applies to: 72-72, 230-230, 268-268, 374-374, 520-520, 610-610, 708-708
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/aws/onboarding.py` at line 27, Several GET routes in this blueprint still declare 'OPTIONS' and call create_cors_response(), which is inconsistent with the POST/DELETE routes that rely on Flask-CORS; update each GET route handler (check_aws_environment, get_aws_onboarding_links, get_aws_onboarding_status, list_user_workspaces, list_aws_accounts, list_inactive_aws_accounts, get_cfn_template, get_cfn_quickcreate_link) to remove 'OPTIONS' from the methods list and remove the early create_cors_response() short-circuit so they rely on Flask/Flask-CORS preflight handling; after that, remove create_cors_response import (or if there is an intentional exception, add a brief comment above the specific handler explaining why it must keep explicit OPTIONS handling).server/routes/aws/auth.py (1)
9-9:⚠️ Potential issue | 🟡 MinorRemove orphaned
create_cors_responseimport.The import on line 9 is unused. Both routes in this file use only POST methods with no OPTIONS handling, so
create_cors_responseis no longer needed.Proposed fix
-from utils.web.cors_utils import create_cors_response from utils.auth.rbac_decorators import require_permission🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/aws/auth.py` at line 9, Remove the unused import create_cors_response from the top of the module: locate the import statement "from utils.web.cors_utils import create_cors_response" and delete it so the module no longer imports an orphaned symbol; verify no other references to create_cors_response exist in this file (e.g., in any functions or route handlers) and run linters/tests to confirm the unused-import warning is resolved.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@server/routes/azure/azure_routes.py`:
- Around line 148-152: The GET handler azure_subscriptions_get still lists
"OPTIONS" in its route methods and contains an explicit OPTIONS branch, which
duplicates preflight handling and bypasses the S3752 hardening; update the route
decorator for azure_subscriptions_get to remove "OPTIONS" from methods and
delete the if request.method == "OPTIONS": return create_cors_response() branch
so that CORS preflight is handled centrally (as done for other routes) rather
than inside this handler.
- Around line 172-182: The POST handler azure_subscriptions_post currently only
logs the incoming projects and returns success without persisting or using the
injected user_id, causing silent data loss; either persist the selection by
calling the existing persistence helper (e.g., store_tokens_in_db(user_id,
{"projects": projects}, "azure") or a similar store_user_preference(...)
function) and validate the payload before storing, or add a clear comment that
selections are UI-only and will not be saved; also change the logging call to a
parameterized form (e.g., logging.info("Azure subscription selection update
received (count=%d)", len(projects))) to avoid f-strings and avoid logging raw
client payloads, and remove the unused user_id warning by using it when
persisting.
In `@server/routes/gcp/projects.py`:
- Around line 170-208: The route sa_project_access_get currently declares
methods=["GET", "OPTIONS"] and contains an in-function OPTIONS branch returning
create_cors_response(), which is redundant with global Flask-CORS and the
require_permission decorator behavior; update the `@gcp_projects_bp.route`
decorator on sa_project_access_get to remove "OPTIONS" so it only registers GET,
and delete the in-function check that returns create_cors_response() (the lines
handling request.method == "OPTIONS"), leaving the rest of sa_project_access_get
intact.
---
Outside diff comments:
In `@server/routes/aws/auth.py`:
- Line 9: Remove the unused import create_cors_response from the top of the
module: locate the import statement "from utils.web.cors_utils import
create_cors_response" and delete it so the module no longer imports an orphaned
symbol; verify no other references to create_cors_response exist in this file
(e.g., in any functions or route handlers) and run linters/tests to confirm the
unused-import warning is resolved.
In `@server/routes/aws/onboarding.py`:
- Line 27: Several GET routes in this blueprint still declare 'OPTIONS' and call
create_cors_response(), which is inconsistent with the POST/DELETE routes that
rely on Flask-CORS; update each GET route handler (check_aws_environment,
get_aws_onboarding_links, get_aws_onboarding_status, list_user_workspaces,
list_aws_accounts, list_inactive_aws_accounts, get_cfn_template,
get_cfn_quickcreate_link) to remove 'OPTIONS' from the methods list and remove
the early create_cors_response() short-circuit so they rely on Flask/Flask-CORS
preflight handling; after that, remove create_cors_response import (or if there
is an intentional exception, add a brief comment above the specific handler
explaining why it must keep explicit OPTIONS handling).
In `@server/routes/azure/azure_routes.py`:
- Around line 77-81: The route handler azure_bp.route("/azure/fetch_data",
methods=["GET", "OPTIONS"]) should be simplified to only handle GET: remove
"OPTIONS" from the methods list and delete the branch that checks
flask.request.method == 'OPTIONS' and calls create_cors_response() inside
fetch_data; leave the require_permission("connectors", "read") decorator and the
GET logic intact so Flask‑CORS handles preflight automatically and
create_cors_response is no longer referenced from this function.
In `@server/routes/bigpanda/bigpanda_routes.py`:
- Line 16: Remove the unused import create_cors_response from the top of the
file and update the two route decorators that currently declare methods=["GET",
"OPTIONS"] so they only declare methods=["GET"] (i.e., remove "OPTIONS" from
those methods arrays) to let Flask-CORS handle preflight automatically; search
for the import name create_cors_response to delete and for route decorators
containing methods=["GET", "OPTIONS"] to change to methods=["GET"] so both
locations are updated consistently.
In `@server/routes/ci_shared.py`:
- Line 19: The GET route decorated with `@blueprint.route`("/rca-settings",
methods=["GET", "OPTIONS"]) is inconsistent with the rest of the refactor;
remove "OPTIONS" from the methods list so it becomes methods=["GET"] (letting
Flask/Flask-CORS and the require_permission/create_cors_response flow handle
preflight), mirroring the PUT handler change and keeping preflight behavior
consistent for the "/rca-settings" route.
In `@server/routes/cloudbees/cloudbees_routes.py`:
- Line 16: The import create_cors_response is unused in this module; remove the
offending import statement that references create_cors_response to eliminate the
orphaned import and keep imports consistent with other route files—search for
the symbol create_cors_response in this file and delete its import line (from
utils.web.cors_utils import create_cors_response).
In `@server/routes/cloudflare/cloudflare_routes.py`:
- Line 123: The GET routes still include 'OPTIONS' in their route decorators;
update the cloudflare_bp.route declarations for the GET endpoints (specifically
the '/cloudflare/zones' and '/cloudflare/status' route decorators) to remove
'OPTIONS' so their methods lists are just ['GET'], allowing Flask-CORS to handle
preflight uniformly like the POST routes were updated.
In `@server/routes/command_policies.py`:
- Around line 46-50: Remove the ad-hoc preflight handling from the route
definitions and let the centralized CORS utility handle OPTIONS: in the
list_policies and list_templates route handlers remove "OPTIONS" from the
methods=["GET", "OPTIONS"] declaration (make them GET-only) and delete the
request.method == "OPTIONS" conditional and its jsonify({}), 200 return so the
handler no longer short-circuits preflight responses.
In `@server/routes/confluence/confluence_routes.py`:
- Line 25: The /status route still handles "OPTIONS" and calls
create_cors_response; update the route decorator for the status endpoint to only
declare methods=["GET"] and remove the early branch that checks request.method
== "OPTIONS" and returns create_cors_response(), and then delete the now-unused
import create_cors_response from the top of the file; locate the status view
(the function handling the "/status" route) and remove the OPTIONS handling and
import to match the cleanup done for /connect, /disconnect, /fetch, and /parse.
In `@server/routes/coroot/coroot_routes.py`:
- Line 16: Remove the now-orphaned import "create_cors_response" from the top of
the file (the line reading "from utils.web.cors_utils import
create_cors_response") because OPTIONS handling for "/connect" and "/disconnect"
was removed and this symbol is no longer referenced; simply delete that import
to keep imports consistent and avoid unused-import warnings.
In `@server/routes/datadog/datadog_routes.py`:
- Line 12: Remove the unused import create_cors_response and stop manually
handling OPTIONS on GET connector endpoints: delete the from
utils.web.cors_utils import create_cors_response line and change the route
decorators for the five GET handlers (the functions handling /status, /events,
/monitors, /events/ingested, /webhook-url) to only declare methods=["GET"]
(remove "OPTIONS"); keep the existing `@require_permission` decorators unchanged
so framework CORS/OPTIONS handling is used automatically.
In `@server/routes/github/github.py`:
- Around line 499-511: The download_github_repo route currently sets ad-hoc CORS
headers on response_data
(Access-Control-Allow-Origin/Headers/Methods/Credentials) which violates the
centralized CORS policy; remove this manual CORS block from download_github_repo
and let the centralized Flask-CORS utility manage CORS, or if you must keep
local headers temporarily, at minimum change the Access-Control-Allow-Methods
value to only include POST and ensure Origin handling uses the centralized
allowed origins list rather than inline os.getenv; reference the
download_github_repo function and the response_data variable to locate and
remove/update the header-setting code.
In `@server/routes/grafana/grafana_routes.py`:
- Line 10: Remove the now-unused import create_cors_response from the top of the
module to eliminate the orphaned dependency; locate the import statement that
reads "from utils.web.cors_utils import create_cors_response" and delete it so
the module no longer imports create_cors_response (verify no other references to
create_cors_response remain in functions or handlers such as any OPTIONS
branches you removed).
In `@server/routes/jenkins/jenkins_routes.py`:
- Line 11: Remove the unused import create_cors_response from
utils.web.cors_utils in the jenkins_routes module; locate the import statement
"from utils.web.cors_utils import create_cors_response" and delete it so the
file no longer contains the orphaned symbol and linter warnings are resolved.
In `@server/routes/knowledge_base/routes.py`:
- Around line 68-73: GET handlers get_memory, list_documents, and get_document
still declare methods=["GET", "OPTIONS"] and contain in-handler branches
returning create_cors_response; remove OPTIONS from the route decorators for
these functions (e.g., `@knowledge_base_bp.route`("/memory", methods=["GET"]),
`@knowledge_base_bp.route`("/documents", methods=["GET"]) and
`@knowledge_base_bp.route`("/documents/<doc_id>", methods=["GET"]) as applicable),
delete the in-handler checks "if request.method == 'OPTIONS': return
create_cors_response()" from those functions, and then remove the now-unused
import create_cors_response from the top of the file to finish the cleanup.
In `@server/routes/netdata/netdata_routes.py`:
- Line 12: Remove the unused import create_cors_response from the top-level
imports (the import statement referencing utils.web.cors_utils and
create_cors_response) in netdata_routes.py; simply delete that identifier from
the import line (or remove the entire import if nothing else is imported from
utils.web.cors_utils) so no unused symbols remain.
In `@server/routes/notion/notion_routes.py`:
- Line 206: Routes for `@notion_bp.route`("/status"),
`@notion_bp.route`("/databases") and `@notion_bp.route`("/databases/<db_id>") still
include "OPTIONS" in their methods list which contradicts the PR goal to let
Flask‑CORS handle preflight; edit each route decorator to remove "OPTIONS" so
the methods array only lists the actual HTTP verbs (e.g., "GET") used by the
view functions (status, databases, databases/<db_id>), keeping the rest of the
decorator and function body unchanged.
In `@server/routes/opsgenie/opsgenie_routes.py`:
- Line 14: The import create_cors_response in opsgenie_routes.py is no longer
used; remove it from the top-level import statement (delete the
create_cors_response symbol or the entire import line if it only contained that
symbol) so the file no longer has an orphaned import; ensure there are no other
references to create_cors_response in functions or route handlers before
committing.
In `@server/routes/org_routes.py`:
- Line 244: Remove the explicit OPTIONS handling and the in-handler OPTIONS
short-circuit from the six routes to match the rest of the file: update the
decorators for the routes registered as `@org_bp.route`("/current",
methods=["GET", "OPTIONS"]), the PATCH route at `@org_bp.route`("/",
methods=["PATCH","OPTIONS"]) (and the sibling routes for "/my-invitations",
"/stats", "/activity", and the GET "/preferences") to drop "OPTIONS" from their
methods lists, and delete the corresponding if request.method == "OPTIONS":
return jsonify({}), 200 early-return blocks inside those view functions so
normal Flask/CORS handling will apply. Ensure you only remove the OPTIONS
entries and short-circuit logic; leave the route names and other behavior
unchanged.
In `@server/routes/spinnaker/spinnaker_routes.py`:
- Line 17: Remove the unused create_cors_response import (symbol:
create_cors_response) and update the GET route decorators so they only specify
"GET" (remove "OPTIONS") for the endpoints handling /status, /applications,
/applications/<app>/pipelines, /applications/<app>/pipeline-configs,
/applications/<app>/health, /webhook-url, and /deployments; keep POST/DELETE and
the /webhook/<user_id> route as-is. Ensure no other code references
create_cors_response before deleting the import and run tests/lint to confirm no
unused-import warnings remain.
In `@server/routes/thousandeyes/thousandeyes_routes.py`:
- Line 15: Remove the unused import create_cors_response from the top of the
file: locate the import statement that references create_cors_response and
delete it so there are no orphaned imports; ensure no other references to
create_cors_response exist in the module (e.g., in route handlers or helper
functions) before committing the change.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 380fb5bc-5181-45d5-8e79-2714f8b7ac74
📒 Files selected for processing (37)
server/routes/atlassian/atlassian_routes.pyserver/routes/auth_routes.pyserver/routes/aws/auth.pyserver/routes/aws/onboarding.pyserver/routes/azure/azure_routes.pyserver/routes/bigpanda/bigpanda_routes.pyserver/routes/bitbucket/bitbucket.pyserver/routes/bitbucket/bitbucket_selection.pyserver/routes/ci_shared.pyserver/routes/cloudbees/cloudbees_routes.pyserver/routes/cloudflare/cloudflare_routes.pyserver/routes/command_policies.pyserver/routes/confluence/confluence_routes.pyserver/routes/coroot/coroot_routes.pyserver/routes/datadog/datadog_routes.pyserver/routes/dynatrace/dynatrace_routes.pyserver/routes/gcp/auth.pyserver/routes/gcp/projects.pyserver/routes/github/github.pyserver/routes/grafana/grafana_routes.pyserver/routes/jenkins/jenkins_routes.pyserver/routes/jira/jira_routes.pyserver/routes/knowledge_base/routes.pyserver/routes/netdata/netdata_routes.pyserver/routes/newrelic/newrelic_routes.pyserver/routes/notion/notion_routes.pyserver/routes/opsgenie/opsgenie_routes.pyserver/routes/org_routes.pyserver/routes/ovh/oauth2_auth_code_flow.pyserver/routes/ovh/ovh_api_routes.pyserver/routes/pagerduty/pagerduty_routes.pyserver/routes/scaleway/scaleway_routes.pyserver/routes/sharepoint/sharepoint_routes.pyserver/routes/spinnaker/spinnaker_routes.pyserver/routes/splunk/search_routes.pyserver/routes/splunk/splunk_routes.pyserver/routes/thousandeyes/thousandeyes_routes.py
…es for consistency
|
2 participants
Summary
main_compute.py, 3 OAuth callbacks ingcp/auth.py,github/github.py,slack/slack_routes.py).readfor GET,writefor POST) —azure/fetch_data,azure/api/azure-subscriptions,gcp/api/gcp/sa-project-access., "OPTIONS"stripped frommethods=so Flask + Flask-CORS auto-handles preflight (industry standard).sa_project_access_get/_post: re-fetchtoken_dataafterrefresh_token_if_neededto avoid using stale tokens.bitbucket_selection,dynatrace,jira,newrelic,sharepoint,splunk) stripped of OPTIONS to match the rest of each file. 3 newly-orphanedcreate_cors_responseimports removed.Why
Aurora is a stateless JSON API authenticated by
X-Internal-Secret+X-User-IDheaders injected server-side by the Next.js proxy. Browsers never directly call Flask, so the OPTIONS-in-methods=+ decorator short-circuit pattern was dead defensive code. Stripping OPTIONS lets Flask auto-respond to preflight, which is the canonical Flask + Flask-CORS pattern.Test plan
OPTIONS /api/auth/register→ 200 (Flask auto-handler),POST /api/auth/register→ 201,POST /api/auth/login→ 200.ast.parse.Summary by CodeRabbit
Chores
OPTIONSmethod support from numerous API endpoints across integration connectors (including Atlassian, AWS, Azure, BigPanda, Bitbucket, Cloudflare, Datadog, GitHub, Jenkins, Jira, and many others), streamlining request handling.