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
3focus areas
3codebases
The idea: every role gets enough access to do its job, and no more. Every check has to hold even when someone skips the website and calls the API directly.
Secure
Only verified people get in, and student code never touches the platform.
Owned byJacob C, Lucas M, Zhengji L
Built withSpring Boot Flask Docker JWT Google OAuth2
Shipped 5
✓Password rules everywhere. Enforced 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.
Next 4
- 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
Manage
Keep the platform lean, and make changes to its data safe.
Owned byRudra J, Dhyan S, Lucas M
Built withSpring Boot Docker Database migrations
Shipped 1
✓Docker cleanup. Redundant images and containers removed.
Next 3
- Production vs. testing config. Separate Spring settings, so test settings never reach production.
- Spring database migration. Move the Spring data to the new setup.
- Automatic upgrades. Apply database upgrades without manual steps.
How a database change ships
1
Migration is written
Migration is written
2
Migration is reviewed
Migration is reviewed
3
Applied to the database
Applied to the database
4
Upgrades run automatically
Upgrades run automatically
Expand
New roles get the right access, and nothing more.
Owned byHarrish A, Arnav P, Darshan S, Shayan B, Rudra J
Built withSpring Security Google OAuth2 JWT GitHub API Jekyll
Shipped 3
✓Mentor role.
ROLE_MENTOR sits between teacher and admin, and a GitHub student ID is checked before it activates.✓Mentor login. Google sign-in with no separate password. PUSD emails get instant access, and other emails wait for admin review.
✓Support pages rework. A dropdown groups the support tabs, with guides for new students.
Next 4
- Mentor dashboard. Mentors track only their own groups' progress and notes.
- Guest role. Read-only access to public content, with no full account.
- Approval tickets. Admins approve Google sign-ins from non-Poway emails.
- AI review with mentor design. Mentor-guided review of student work.
How a mentor gets access
1
Mentor signs in with Google
Mentor signs in with Google
2
Other emails: admin review
Other emails: admin review
3
Pending role becomes mentor
Pending role becomes mentor
4
Mentor opens the dashboard
Mentor opens the dashboard
Our vision
An OCS anyone can safely join and grow in, with no account, code, or data left exposed.
✓Every account is verified at every layer.
✓Student code always runs contained.
✓The platform stays easy to maintain.
✓New roles get the right access, and nothing more.
How we work
Focused sub-teams
Security, admin and database, and mentors. Each owns its area.
Security, admin and database, and mentors. Each owns its 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.