OCS Admin & Security Team
The systems that protect Open Coding Society as it scales: identity verification and password enforcement across the frontend and both backends, isolated execution for student code, automated database maintenance, and a role-based mentor system.
Capstone
We secure sign-in, manage mentor access, and keep student code isolated on the Open Coding Society platform.
9team members
3sectors
3codebases
We are the OCS Admin & Security team. Our goal is that any school can stand up its own Open Coding Society, under its own name, without editing our code. Security and backend are the two things a kit must already have right, so that the platform is safe by default and its accounts are easy for staff to run.
Sector 1 · our missionOCS in a Kit
Package OCS so another school can ship it under its own name.
Sector 2SecurityWhat keeps every kit safe: sign-in and student code.
Sector 3BackendWhat lets a school's staff run it: accounts, mentors, and data.
BeyondVision and team flowWhere we are headed and how we split the work.
OCS in a Kit Kanban Board
Open on GitHub
OCS in a Kit
Everything that makes OCS ours becomes a setting, so another school can make it theirs.
Why this comes first: our security and backend work only reaches another school if it ships in a form that school can set up. So every feature we build keeps its school-specific values in the kit, not in the code.
Owned byThe whole team, alongside every feature
Built withFlask Spring Jekyll Data files
In review 1
- One data file for Flask. School domains, account types, and policy values live in one file, not in code (Flask #84).
Next 4
- Pages reads the kit. The frontend takes the same school settings from data, not from hard-coded values.
- Spring student-email check. Spring decides who is a student from the kit's domains, not a fixed list.
- New branding. A school ships the platform under its own name and look.
- Go-live checklist. The deployment steps below, written up so a new school can follow them.
What a school changes
School domains
Which email addresses count as students and staff.
Which email addresses count as students and staff.
Account types
Which roles exist and how each one is activated.
Which roles exist and how each one is activated.
Policy values
Rules such as how often accounts are re-verified.
Rules such as how often accounts are re-verified.
How a release goes live
1
Run the database migration
Run the database migration
2
Set
Set
GOOGLE_CLIENT_ID3
Deploy pages, then Flask
Deploy pages, then Flask
4
Sign up one real student and confirm activation
Sign up one real student and confirm activation
OCS Security Kanban Board
Open on GitHub
Security
Every kit ships safe: only verified people get in, and student code never touches the platform.
Owned byZhengji L, Harrish A, Jacob C, Lucas M
Built withSpring Boot Flask Docker JWT Google OAuth2
Shipped 5
✓Password rules at every layer. Checked in the frontend, Spring, and Flask, so skipping the website still yields no account.
✓Signup check. Blocks signups whose GitHub and student ID don't match.
✓Verified password reset. Needs Google and GitHub ID verification, is rate-limited, and signs out old tokens.
✓Safe password sync. Plaintext sync to Flask is refused over insecure links.
✓Isolated Flask runner. Python runs in its own Docker container, never in the main app.
In progress 1
- Login cookies. Harrish is working on the cookies that keep a user signed in, so a session stays secure from login to logout.
Next 7
- Simpler password policy. Spring's password-complexity check is causing support issues, so it comes out first.
- Forced password reset. Anyone on a weak or default password must change it at login.
- Yearly re-verification. Students confirm who they are at login once a year.
- Isolated Spring runner. Java gets its own container. The API wiring is in progress.
- Runner hardening. Settings move to
.env, plus resource limits, timeouts, non-root execution, and restricted network and filesystem. - Spring access control. Permissions on every endpoint.
- Audit log. A record of important security events.
How submitted code is run
1
Student submits code
Student submits code
2
Spring or Flask receives it
Spring or Flask receives it
3
Runs in a separate container
Runs in a separate container
4
Only the result comes back
Only the result comes back
How a password reset works
1
Reset requested
Reset requested
2
Google and GitHub ID verified
Google and GitHub ID verified
3
Ticket issued, rate-limited
Ticket issued, rate-limited
4
Password changed
Password changed
5
Active tokens invalidated
Active tokens invalidated
OCS Admin Kanban Board
Open on GitHub
Mentor Kanban Board
Open on GitHub
Backend
Every kit ships runnable: each account has a known state, and staff can see and change it.
Owned byHarrish A, Arnav P, Darshan S, Shayan B, Rudra J, Dhyan S, Lucas M
Built withFlask Spring Security Google OAuth2 Database migrations Docker
Shipped 6
✓Account activation. Every account carries an active flag and a last-verified date (Flask #82, pages #1768).
✓Student activation. Students are activated by signing in with their school Google account.
✓Mentor verification. Signup can identify a mentor, and mentors start inactive until staff verify them.
✓Mentor role.
ROLE_MENTOR sits between teacher and admin, with its own view of the site.✓Support pages rework. A dropdown groups the support tabs, with guides for new students.
✓Docker cleanup. Redundant images and containers removed.
In review 3
- Guest accounts. Keep them working under the new activation rules.
- Backup restore. Restoring a backup keeps each account's activation state.
- Pending status. A user who is waiting on verification can see their own status.
In progress 1
- Mentor dashboard. We are building a dashboard where each mentor tracks only their own groups' progress and notes, building on the mentor role and verification already shipped. Darshan leads it, with Harrish building alongside.
Next 5
- Account Administration screen. Teachers and admins see all accounts, filter by role and active status, and activate or deactivate. A prototype runs locally. Still open is whether a teacher may deactivate an admin.
- Status column. Shows each account's state with a deactivate action. It waits on the kit's data file.
- Production vs. testing config. Separate Spring settings, so test settings never reach production.
- Spring database migration. Move the Spring data to the new setup, with upgrades applied automatically.
- AI review with mentor design. Mentor-guided review of student work.
How an account becomes active
1
Person signs up as student or mentor
Person signs up as student or mentor
2
Student: school Google sign-in activates
Student: school Google sign-in activates
3
Mentor: inactive until staff verify
Mentor: inactive until staff verify
4
Active flag and verified date saved
Active flag and verified date saved
Deferred: the Observer role, which needs authorization from a student and then from staff, and domain or test accounts, which stay out until their requirements are clearer.
Our vision
An Open Coding Society any school can adopt in its own name, with no account, code, or data left exposed.
✓A new school changes a data file, not our code.
✓Every account is verified, and staff can see its status.
✓Student code always runs contained.
✓New roles get the right access, and nothing more.
Roadmap
| Work | Sector | Status |
|---|---|---|
| OCS as a reusable kit | OCS in a Kit | Flask in review |
| Sign-up, activation, and verification | Backend | Merged |
| Activation follow-ups: guests, backup restore, pending status | Backend | In peer review |
| Mentor dashboard | Backend | In progress |
| Account Administration screen | Backend | Prototype |
| Login workflow: forced reset and yearly re-verification | Security | Not started |
| Observer role and domain or test accounts | Backend | Deferred |
| Deployment | OCS in a Kit | After the PRs land |
How we work
Three sectors, three reps
One rep each for security, mentor, and kit work speaks for that area.
One rep each for security, mentor, and kit work speaks for that area.
Daily meetings
Decide the work and keep the board honest.
Decide the work and keep the board honest.
One owner, cap of two
Each task has one owner, and the least-loaded member claims first.
Each task has one owner, and the least-loaded member claims first.
Reviewed and reported
Review before done, and a weekly update every Thursday.
Review before done, and a weekly update every Thursday.
Our team flow
This mindmap shows how we split the work. Everyone branches off the CSA Admin hub, and the colored dots show which workstreams each person is on: OCS in a Kit (pink), Mentor Dashboard (orange), Database (green), and Security (blue).
How the work flows
Arnav drives OCS in a Kit
Arnav works only on the kit, and Harrish, Dhyan, and Shayan report through Arnav. That keeps every branch building toward something another school can set up.
Arnav works only on the kit, and Harrish, Dhyan, and Shayan report through Arnav. That keeps every branch building toward something another school can set up.
Darshan and Harrish build the mentor dashboard
Darshan leads the dashboard and Harrish builds alongside, so mentors can track their own groups. Harrish also works on login cookies, tying the dashboard to secure sign-in.
Darshan leads the dashboard and Harrish builds alongside, so mentors can track their own groups. Harrish also works on login cookies, tying the dashboard to secure sign-in.
Zhengji anchors security
Zhengji works with security, alongside Harrish's login cookies and Shayan's login lockout, so sign-in stays protected as the kit grows.
Zhengji works with security, alongside Harrish's login cookies and Shayan's login lockout, so sign-in stays protected as the kit grows.
The database track runs in parallel
Lucas and Jacob (the green boxes) work on SQL. Dhyan pairs with Lucas, and Rudra works in the database while handling OCS communications for the team.
Lucas and Jacob (the green boxes) work on SQL. Dhyan pairs with Lucas, and Rudra works in the database while handling OCS communications for the team.
Every task feeds the kit
Nearly every member carries the pink dot: whatever they build keeps its school-specific values in the kit. Dashed lines mark work that crosses branches, such as Shayan's login lockout, which ties into the accounts Darshan's dashboard shows.
Nearly every member carries the pink dot: whatever they build keeps its school-specific values in the kit. Dashed lines mark work that crosses branches, such as Shayan's login lockout, which ties into the accounts Darshan's dashboard shows.