Integrated Project: Dynamic PHP and Python Web Application

Integrated Project: Dynamic PHP and Python Web Application

This lesson brings together every skill you have built in this course. You will design, build, test, and document a multi-page web application that uses PHP for front-end server logic, a Python script for back-end data processing or automation, and a MySQL or MariaDB database — all held together by secure coding practices.

Planning Before You Code

Rushing into code without a plan is the single most common reason student projects fail. Before writing one line of PHP or Python, produce a written project brief that contains three things.

Data dictionary. List every database table you plan to create. For each table, record the column name, data type (for example, `INT`, `VARCHAR(100)`, `DATE`), whether the column can be NULL, and any key constraints (primary key, foreign key, unique). A clear data dictionary prevents column-name typos and type mismatches that are painful to fix later.

Site map. Sketch at least four PHP pages and the links between them. Common pages include a login page, a dashboard or home page, a data-entry form page, and an admin or report page. The site map helps you see the user's path through the application before you build it.

Python component description. Write one paragraph explaining exactly what your Python script will do, what data it reads (from the database, a file, or an API), what it produces, and when or how it is triggered. Your instructor must approve the brief before you begin the build phase.

Build Phase: PHP, Python, and the Database

PHP pages. Each PHP page should follow a consistent structure: include a shared header file, check session state where required, validate and sanitize all user input, run parameterized queries against the database, and render output safely. Never interpolate raw user input into a SQL string — use PDO or MySQLi prepared statements with bound parameters. This is the primary defense against SQL injection.

For session management, call `session_start()` at the top of every page that needs it, store only a user ID in the session (not the password), and regenerate the session ID after a successful login with `session_regenerate_id(true)` to prevent session fixation attacks.

For output, always encode user-supplied data before printing it to the browser. In PHP, `htmlspecialchars($value, ENT_QUOTES, 'UTF-8')` converts special characters to HTML entities, blocking cross-site scripting (XSS) attacks.

CRUD operations. Your application must support Create, Read, Update, and Delete operations against at least one database table. Wrap multi-step operations in database transactions so partial failures do not leave corrupt data.

The Python script. Python handles the back-end work — for example, reading records from the database and generating a CSV report, sending a summary email, or running a data cleanup routine. Use the `mysql-connector-python` or `PyMySQL` library to connect to the same database your PHP pages use. Always close the connection when the script finishes. Never hard-code credentials in the script; read them from a configuration file that is excluded from version control via `.gitignore`.

Git discipline. Commit your code to a local Git repository at the end of every lab session with a meaningful commit message (for example, `Add input validation to registration form`). You need at least eight commits by the end of the project. A well-maintained Git log is evidence of your workflow and protects you if a file is accidentally deleted.

Secure Coding Practices Throughout

OWASP (Open Worldwide Application Security Project) publishes the OWASP Top Ten, a widely used reference list of the most critical web application security risks. For this project, focus on the following risks:

• Injection (SQL injection): Prevented by parameterized queries.
• Broken authentication: Prevented by hashing passwords with `password_hash()` / `password_verify()` in PHP and by regenerating session IDs after login.
• XSS: Prevented by encoding output with `htmlspecialchars()`.
• Security misconfiguration: Avoid displaying detailed error messages to end users; log errors to a file instead.

Store no plaintext passwords — ever. If your project requires user accounts, hash the password at registration and verify the hash at login.

Testing and Documentation Phase

A written test plan with at least ten test cases is required. Each test case must state: an ID, the feature being tested, the input you will enter, the expected result, the actual result, and pass or fail. Cover three categories:

• Normal conditions: typical valid inputs that should succeed.
• Boundary conditions: values at the edge of valid ranges (empty strings, maximum field lengths, zero quantities).
• Error conditions: invalid inputs, wrong passwords, duplicate records — anything the application should reject gracefully.

Record every bug you find and the fix you applied. This bug log is part of your submitted documentation.

Finish with a README file (plain text or Markdown) that explains how to set up the database, configure credentials, install PHP and Python dependencies, and run the application. A reader who has never seen your project should be able to get it running by following your README alone.

Passing Criteria

All of the following must be true to earn a passing grade: all ten test cases pass; instructor review finds no SQL injection or XSS vulnerabilities; the Python script runs without errors and produces correct output; the README is complete and accurate; and the Git log shows at least eight commits. Every criterion must be met — there is no partial credit on this integrated project.