fix: Enforce Authentication on CTF Sidecar Widget Endpoint

[prince-shakyaa]

fix: Enforce Authentication on CTF Sidecar Widget Endpoint

Fixes #511

Summary

The GET /api/v1/sidecar endpoint was using get_session_context (which allows
anonymous/temporary sessions) instead of get_authenticated_session_context (which
enforces a bound-email session). This meant any unauthenticated visitor could call this
endpoint and receive an HTTP 200 instead of HTTP 401.

This PR fixes the dependency with a 2-line code change and adds a dedicated unit test
file to prevent regressions.

---

Changes

1. Code Fix : finbot/apps/ctf/routes/sidecar.py

What: Swap the FastAPI dependency on get_sidecar_data from the weaker
get_session_context to the authenticated get_authenticated_session_context.

-from finbot.core.auth.middleware import get_session_context
+from finbot.core.auth.middleware import get_authenticated_session_context

 @router.get("/sidecar")
 async def get_sidecar_data(
-    session_context: SessionContext = Depends(get_session_context),
+    session_context: SessionContext = Depends(get_authenticated_session_context),
     db: Session = Depends(get_db),
 ):

Why: get_authenticated_session_context raises HTTP 401 Unauthorized when
session_context.is_temporary is True (i.e., the caller has not bound their email).
This matches the auth guard used by every other personal-data endpoint in the CTF app
(/api/v1/profile, PUT /api/v1/profile, PUT /api/v1/profile/featured-badges).

Lines changed: 2
Risk: Very low - no change in behavior for authenticated users.

---

2. New Test File : tests/unit/apps/ctf/test_sidecar_auth.py

A new unit test file modelled on the existing test_share_card_cache_key.py pattern.

Tests included:

Test ID	Test Name	What It Verifies
BUG-511-001	test_temporary_session_is_rejected	A session where is_temporary=True raises HTTP 401
BUG-511-002	test_authenticated_session_is_accepted	A session where is_temporary=False does NOT raise 401
BUG-511-003	test_auth_guard_uses_correct_dependency	The get_sidecar_data function depends on get_authenticated_session_context and NOT get_session_context
BUG-511-004	test_unauthenticated_request_returns_401	End-to-end: calling /api/v1/sidecar with no session cookie returns HTTP 401

Approach: Following the same style as test_share_card_cache_key.py:

• Pure unit tests with @pytest.mark.unit
• No database required - temporary sessions are mocked with a simple stub
• Uses fastapi.testclient.TestClient for the end-to-end route test

Test file location: tests/unit/apps/ctf/test_sidecar_auth.py

---

Files Changed

File	Type	Lines Changed
finbot/apps/ctf/routes/sidecar.py	Modified	2
tests/unit/apps/ctf/test_sidecar_auth.py	New	~120

Total: 2 files, ~122 lines

---

Before vs After

Scenario	Before (Buggy)	After (Fixed)
Unauthenticated / temporary session calls GET /api/v1/sidecar	HTTP 200 ✅ (incorrectly)	HTTP 401 ✅ (correctly)
Authenticated session calls GET /api/v1/sidecar	HTTP 200 ✅	HTTP 200 ✅ (no change)

---

How to Test

# Run only the new unit tests
pytest tests/unit/apps/ctf/test_sidecar_auth.py -v

# Run the full CTF unit test suite
pytest tests/unit/apps/ctf/ -v

---

Checklist

• Code fix applied in sidecar.py (2 lines)
• New test file test_sidecar_auth.py created
• All 4 new tests pass locally
• No existing tests broken
• PR references Closes #511

[prince-shakyaa]

Hiii @saikishu , @e2hln
This PR fixes a missing authentication check on the CTF sidecar widget endpoint by switching the dependency to get_authenticated_session_context. This ensures that anonymous/temporary sessions are correctly blocked with an HTTP 401, preventing unauthorized queries and bringing this route in line with the rest of the app. I've also added full unit tests to prevent future regressions.
Let me know if you need me to make any changes.
Thank You.

[joshlochner]

Would this break an unauthenticated users ability to fully explore the app without sharing an email? The ability to do so is attractive to some people first viewing the app.

[prince-shakyaa]

@joshlochner
Great question - I want to be precise about what "unauthenticated" means in this
app's session model, because it's easy to conflate two different states.

The app has two session tiers:

1. Temporary session (is_temporary = True) : auto-created for every visitor
   by SessionMiddleware on the first request, no email required. This is what
   unauthenticated users hold.

2. Persistent session (is_temporary = False) : created when a user binds an
   email address. This is what get_authenticated_session_context enforces.

What an unauthenticated (temporary session) user can still do — unchanged by this PR:

Endpoint	Accessible without email?
GET /api/v1/challenges	✅ Yes - browse all challenges
GET /api/v1/challenges/{id}	✅ Yes - view challenge detail
GET /api/v1/badges	✅ Yes (get_session_context)
GET /api/v1/stats	✅ Yes (get_session_context)
GET /api/v1/toolkit/*	✅ Yes (get_session_context)
GET /profile/u/{username}	✅ Yes (no auth at all)
All web page routes	✅ Yes (get_session_context)

What this PR restricts — only the sidecar widget:

Endpoint	Before	After
GET /api/v1/sidecar	✅ 200 (leaked personal progress data)	🔒 401 Unauthorized

The sidecar widget is specifically a personalised dashboard -it returns your
completed challenges, your earned badges, your recent activity events, and your
active in-progress challenges. There is no meaningful data to show for a temporary
session that has no progress at all. For a brand-new visitor with no email, the
widget would have returned: 0 points, 0 badges, 0 activity, 0 active challenges —
essentially empty data.

The fix gates the one endpoint that was leaking a personal data view to sessions
that have no identity to show data for, while every read/browse endpoint used for
exploring the app remains fully accessible without sharing an email.

[joshlochner]

I was under the impression that GET /api/v1/challenges/{id} was going to be impacted by this, if not, sounds good

[prince-shakyaa]

I was under the impression that GET /api/v1/challenges/{id} was going to be impacted by this, if not, sounds good

Yes, that's intentional! I wanted to leave the challenge details accessible to unauthenticated/temporary sessions so people can preview them. Only the sidecar needed to be locked down.