Present Attendance System
Rationale for AI-Assisted Rewrite

What Present does

Present allows faculty to record attendance against Pharos360 class lists, view history, send email summaries, and export rosters. It runs as a separate instance per client and is used by a small number of Pharos360 clients.

Why the current version is a liability

• No maintainability path. Java and GWT are outside the current team's skill set entirely. GWT was deprecated by Google in 2013. Any bug, security issue, or feature request requires a contractor or goes unaddressed.
• No upgrade path. The Java runtime and GWT version in production are not being patched against current security standards. Unlike Pharos360 (RailsLTS) or Timefree (same), Present has no equivalent coverage. Vulnerabilities cannot be addressed by the team.
• Operational fragility. Because nobody on the team can read or modify the code, any failure — however minor — becomes a crisis. There is no ability to diagnose, patch, or adapt the application to changes in Pharos360's API or database schema.

Present is not a standalone application. It has direct access to sensitive student data through two channels:

1. Pharos360 authentication and session validation

Every request to Present is authenticated by validating the user's Pharos360 session cookie against Pharos360's internal cookie_checker.php endpoint. Present never stores credentials — it delegates entirely to Pharos360's authentication system. This pattern is preserved correctly in the rewrite.

If a vulnerability exists in the Java session handling layer and cannot be patched, an attacker could potentially bypass authentication. The team has no ability to assess or address this.

2. Direct database access to student records

Present connects directly to the Pharos360 PostgreSQL database and reads student names, IDs, preferred names, class lists, enrollment data, attendance records, and schedule information. This is read-mostly access, but it represents direct exposure to student PII.

3. Student photo proxy

Present proxies student photo requests to Pharos360, forwarding the authenticated session cookie. The rewrite includes explicit input validation on usernames (alphanumeric only) before any photo request is forwarded, preventing path traversal.

4. Email

Present sends attendance summary emails to faculty. Credentials are held in environment variables per deployment.

Security posture of the Laravel rewrite

The AI-assisted pilot produced a working Laravel/PHP rewrite of Present in approximately 15–20 hours of active development. As of June 2026, the rewrite handles:

• Authentication via Pharos360 SSO session validation — identical pattern to the Java version, correctly implemented in Laravel middleware
• Class lists pulled from Pharos360's PostgreSQL database with full student details
• Attendance recording with real-time status cycling and keyboard navigation
• Student photos via a secure proxy with input validation and session forwarding
• Email summaries to faculty with attendance data
• Roster export in standard formats
• WCAG accessibility improvements not present in the Java version — keyboard navigation, screen reader roles, focus management, contrast fixes

The rewrite runs today, connected to live Pharos360 data in a local development environment. It is functionally complete; what remains is production hardening.

The risk of inaction exceeds the risk of the rewrite

The status quo is not a stable position. Present will continue to accumulate unaddressed technical debt and unpatched vulnerabilities in a codebase nobody can touch. The question is not whether to rewrite it but when, and whether to do so proactively or in response to a crisis.

The technology match is ideal for AI-assisted development

AI-assisted development performs best on greenfield rewrites with clear specifications, modern frameworks with well-documented patterns, and bounded scope. The pilot demonstrated all three: a working application was produced in a fraction of the time a traditional rewrite would require.

The team can own and maintain the output

PHP/Laravel is within the current team's skill set. Once the rewrite is in production, any Pharos360 developer can read, modify, debug, and extend it — directly solving the core problem.

The proof of concept already exists

The rewrite is not a proposal — it is a working application. The pilot eliminated the largest risk in any rewrite project: the question of whether it can be done. What remains is hardening and deployment.

Estimated effort: 4–6 weeks for one developer with PHP/Laravel familiarity, given the working codebase as a starting point.

Proposed model: One Docker container per client, running on existing AWS EC2 infrastructure. Each client gets:

• A dedicated Present container (shared image, per-client environment variables)
• A dedicated PostgreSQL database pointing to the client's Pharos360 data
• A subdomain — e.g. present-clientname.pharosresources.com
• IP restriction via EC2 security groups if appropriate

This mirrors the current per-instance model, maintains client data isolation, and allows individual instances to be deployed, updated, or decommissioned independently.

HTTPS: TLS termination via Nginx reverse proxy with Let's Encrypt certificates. No additional AWS services required.

The combination of clear risk from inaction, a working rewrite already in hand, a technology stack the team can own, and a bounded scope makes this the strongest candidate for an initial AI-assisted production project.