Admin panel and account routes have no authentication at all
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- python
调研方向
Start with the listed handlers in backend/routes/user.py, then inspect the existing authentication and role-check helpers to understand how system-level admin access is represented. The issue also points to fetch calls in pages/admin/* and pages/editAccount/index.js; review those after the backend checks. Done means the listed routes reject unauthenticated or non-admin access and the frontend sends credentials; linked PR #378 is already open.
由索引模型根据 Issue 内容生成。
描述
The admin panel (pages/admin/*) and the account-edit page (pages/editAccount/index.js) call several backend routes that have no authentication check at all — not require_authenticated(), not any role check. Confirmed by reading each route directly:
get_all_courses,get_all_instructors,get_all_students(backend/routes/user.py) — return every course/instructor/student in the system to anyone who calls them, logged in or not.create_user,delete_user,admin_update_account(backend/routes/user.py) — let anyone create, delete, or edit any user account, no auth required.get_user_by_id,update_account(backend/routes/user.py) — let anyone read or modify any user's account details given their ID.get_instructor_by_eid,get_courses_by_instructor— similar unauthenticated lookups.
On the frontend, none of the corresponding fetch() calls in pages/admin/* or pages/editAccount/index.js send credentials: "include" either, but that's secondary — even with credentials, these routes don't check who (if anyone) is calling them, let alone whether they're an admin.
This is a real security gap: right now, anyone who knows (or guesses) a user ID can read or edit any account, and the entire admin panel's data is publicly readable with no login. Fixing it means adding an admin-role auth check (presumably a new check, since require_course_role is course-scoped and this is account/system-level) to each of these routes, then fixing the frontend fetches to send credentials once there's an auth check for them to matter against.
Found during a deep-dive audit of frontend/src fetch calls after Cecilia's review of PR #355, while checking for other instances of the missing-credentials pattern she found. Not currently causing a user-visible bug (no auth check to fail against yet), but a real, separate finding worth its own tracking given the security implications, especially before this platform goes live.
- 主要语言
- Python
- 星标
- 13
- 派生
- 0
- 平均合并
- 2 小时 4 分钟
- 30 天内合并 PR
- 1
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
kiat/codeAssist 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
kiat/codeAssist#391 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
kiat/codeAssist#364 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 42/100
kiat/codeAssist#393 ·
-
难度 3/5 1-2 天 新手友好度 63/100
kiat/codeAssist#392 ·
-
难度 4/5 3-5 天 新手友好度 52/100
kiat/codeAssist#390 ·
相似的 Issue
-
python triage
难度 2/5 1-3 小时 新手友好度 72/100
microsoft/semantic-kernel#14615 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
shackett/shackett-utils#19 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
UKGovernmentBEIS/control-arena#917 ·
维护者通常 1 天内回复