Add web UI for false-positive-check script

[roberto-luzardo-sonarsource]

Summary

• Adds a small Flask web UI (false-positive-check/webui/) that wraps the existing sonarqube_false_positives.py module
• Lets users enter a SonarQube URL/token in a browser, run the same project- and rule-based false-positive analysis as the CLI, and view results in sortable tables
• Both CSV reports remain downloadable from the results page
• README updated with setup/run instructions for the UI

Test plan

• Verified the Flask app imports cleanly and registers expected routes
• Verified GET / renders and POST /analyze redirects with a flash message when the URL is missing
• Verified /download/<file> rejects path-traversal attempts (returns 404)
• Manual run against a live SonarQube instance (needs a reachable server + token)

[roberto-luzardo-sonarsource]

@gitar-bot review

[gitar-bot]

@gitar-bot review

On it — running a full code review now.

[roberto-luzardo-sonarsource]

gitar auto-apply:on

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Integrates a Flask web UI for the false-positive check script, resolving security risks regarding persistent secrets, restricted file permissions, and automated cleanup of generated CSV reports.

✅ 3 resolved

✅ Bug: Random per-process secret key breaks flash across workers/restarts

📄 false-positive-check/webui/app.py:34-35
app.secret_key = os.environ.get("FLASK_SECRET_KEY", os.urandom(24)) falls back to a fresh random key generated at process start. Flash messages rely on the signed session cookie, so any restart invalidates existing sessions, and if the app is ever run with more than one worker process (e.g. gunicorn with multiple workers) each worker has a different key, causing flash/session cookies to fail to validate intermittently. This is fine for the single-process app.run dev setup documented here, but worth guarding: log a warning or require FLASK_SECRET_KEY when not in debug/dev mode.

✅ Security: Reports written to shared world-accessible temp dir

📄 false-positive-check/webui/app.py:37-38 📄 false-positive-check/webui/app.py:85-92
REPORTS_DIR = os.path.join(tempfile.gettempdir(), "sonarqube_fp_reports") places generated reports in a predictable, shared location under /tmp, and os.makedirs(..., exist_ok=True) creates it with default permissions (subject only to umask). On a multi-user host, other local users may be able to list/read the CSV reports, and the run_id filenames are the only access control on the download route. Since the reports contain analysis data about the target SonarQube instance, consider using tempfile.mkdtemp() (which creates a 0700 directory) or explicitly setting restrictive permissions on REPORTS_DIR.

✅ Quality: Generated CSV reports are never cleaned up

📄 false-positive-check/webui/app.py:62-66
In analyze(), every run writes two CSV files ({run_id}_projects.csv, {run_id}_rules.csv) into REPORTS_DIR (<tmp>/sonarqube_fp_reports), but nothing ever deletes them. Over time this directory grows unbounded, leaking disk space and leaving stale analysis output (project names, issue counts) on disk indefinitely. Consider periodically pruning old files (e.g. by mtime) on each request, or writing to a per-session temp dir that is cleaned up, or documenting a retention policy.

Options ✅ Auto-apply

✅ Auto-apply is on → Gitar will commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

✅ Auto-apply	Compact
gitar auto-apply:off	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}