fix: add session ownership check before deleteCase and copyCase (#48)

[tejassinghbhati]

Summary

/deleteCase and /copyCase previously performed destructive filesystem operations (shutil.rmtree, shutil.copytree) using a case name taken directly from user-supplied JSON, with no verification that the requesting client owned that case. The session was only checked after deletion to decide which status code to return — not before to guard the operation.

This PR adds an ownership guard to both routes before any filesystem action is taken.

---

Changes

API/Routes/Case/CaseRoute.py

Both /deleteCase and /copyCase now:

• Check that an active session exists — return 403 if none
• Verify that the requested casename matches session['osycase'] — return 403 if not

# Added at the top of both routes, before any filesystem call
active_case = session.get('osycase')
if not active_case:
    return jsonify({'message': 'No active session.', 'status_code': 'error'}), 403

if case != active_case:
    return jsonify({'message': 'Unauthorised: case does not match active session.', 'status_code': 'error'}), 403

Additionally, deleteCase is simplified — the redundant if/else checking session after deletion is replaced with a single session['osycase'] = None, since ownership is now guaranteed by the guard above.

---

Verification

Manually verified the guard logic:

BLOCKED: Ownership mismatch -> 403 Unauthorised   ← mismatched casename rejected
ALLOWED: model_A matches session -> delete proceeds ← authorised request passes

Authorised requests behave identically to before — no regression in normal usage.

Related

Closes #48

[SeaCelo]

Thanks for this PR, @tejassinghbhati.

I want to integrate #50 and #55 together on a branch sec-case-guard so we keep both:

• security ownership checks from [Bug] /deleteCase and /copyCase perform destructive filesystem operations without validating session ownership #48, and
• missing-case recovery from [Bug] Application enters broken state when case directory is removed externally (requires cookie reset) #53.

Please retarget this PR to sec-case-guard. I’d like this PR to merge first, but it needs to edits to avoid a conflict.

Behavior to keep from this PR:

• copyCase and deleteCase require active session case match.
• mismatch or no active session returns 403 with clear JSON message.

[tejassinghbhati]

Hi @SeaCelo, done — I've retargeted this PR to sec-case-guard and rebased cleanly on top of it. No conflicts.

On the 403 behaviour you flagged: both routes return distinct JSON messages — "No active session." when there's no osycase in session, and "Unauthorised: case does not match active session." on a mismatch — so the frontend can distinguish between the two cases. Let me know if you'd prefer a different message format or a single unified 403 body.

Ready for review whenever you are — happy to adjust anything before #55 lands on top.

[tejassinghbhati]

Also raised #75 — /setSession can bypass the ownership guards we added here.