1. Introduction
1.1. Abstract
"Good morning everyone. Today, we're going to delve into the architecture of a web application I've built called InkWell. InkWell is a multi-user blogging platform, created from the ground up using PHP and MySQL. The goal of this project wasn't just to build another blog, but to create a practical case study that demonstrates a secure, modular, and robust web application. We'll be looking at how it uses the three-tier architectural pattern, how it manages user sessions, and most importantly, how it implements foundational web security principles. Through this presentation, I'll show you how all these different pieces come together to create a complete and functional system."
1.2. Design Philosophy and Rationale
"The entire development process was guided by three core principles. First, a 'Security-First' mindset. This means that from the very beginning, we thought about potential vulnerabilities and built defenses into every part of the application that handles user input. Second, a modular code structure. Instead of one giant, unmanageable file, the application is broken down into smaller, single-responsibility files. This makes the code cleaner, easier to understand, and much simpler to maintain. And finally, user-centric functionality. We focused on the essential features that make a blog work: letting users sign up, create content, and interact with each other."
1.3. Technology Rationale
"The choice of technology was very deliberate. We chose PHP for the backend because it's a powerful and widely-used server-side language. Its procedural style, which we've used here, makes it easy to follow the logic from request to response, which is perfect for a project like this. For the database, we used MySQL, a reliable and structured database system that’s ideal for managing the relationships between our users, their posts, and their comments. And for the frontend, we stuck to the universal standards of HTML5 and CSS3. This allowed us to build a clean and responsive interface without adding the complexity of a large frontend framework, keeping our focus squarely on the backend architecture."
2. System Architecture
2.1. The Three-Tier Architectural Model
"Now, let's talk about the high-level design. InkWell is built using a three-tier architecture. This is a standard and very effective design pattern that separates the application into three distinct layers: the Presentation Tier, the Logic Tier, and the Data Tier. This separation is key to making the application organized and scalable. I'll now click on each tier to explain its role."
Presentation Tier
Logic Tier
Data Tier
Select a tier to see its detailed analysis.
2.2. Logic Tier: File-by-File Analysis
"The Logic Tier, or the backend, is the engine of our application. It’s made up of several PHP scripts, each with a specific job. Let's go through them group by group to understand how they work together. I'll select each group from the list to show you its role."
Select a file/group to see its analysis.
3. Data Architecture
3.1. Relational Schema Design
"Let's move to the foundation of our application: the data architecture. The InkWell database uses a relational schema with three tables. This design is crucial because it ensures our data is consistent, prevents duplication, and makes it easy to retrieve information. We use primary keys to give each record a unique ID, and foreign keys to link the tables together. I'll now click on each table to show you its structure and explain the purpose of each column."
Select a table to view its detailed structural analysis.
3.2. Data Integrity and Relationships
"A key feature in our database design is how we maintain data integrity using foreign key constraints, specifically with the `ON DELETE CASCADE` rule. This is an incredibly useful feature. Let me explain what it does: If a user decides to delete their account, the database automatically deletes all the posts written by that user. And when those posts are deleted, the database then automatically deletes all the comments associated with those posts. This cascading effect prevents us from having 'orphaned' data, like posts without an author or comments without a post. It's a powerful way to ensure our database remains clean and consistent over time."
4. Functional Analysis: User and System Flows
"Now that we've seen the architecture and the database, let's look at how it all works in practice by analyzing the main functional flows of the application. We'll trace the journey from a user's action in the browser, to the processing on the server, and the interaction with the database."
4.1. User Authentication and Session Management
"First, the authentication flow. This is how users securely sign up and log in. It starts with registration, where we create a new user record, and ends with login, where we verify their credentials and start a session, which is like a temporary ID card that keeps them logged in as they navigate the site."
4.2. Content Management (CRUD) Lifecycle
"Next is the core functionality of the blog: the content management lifecycle, also known as CRUD—Create, Read, Update, and Delete. This flow is only available to logged-in users, and critically, it includes checks to ensure that authors can only edit or delete their own posts."
4.3. User Interaction: The Commenting Process
"Finally, let's look at the commenting system. This is an interesting process because the form to submit a comment is on the same page that displays the comments. To handle this cleanly and prevent users from accidentally posting the same comment twice if they refresh the page, we use a common web development pattern called Post-Redirect-Get, or PRG."
5. Security Framework Analysis
"Finally, and most importantly, let's discuss the security framework of InkWell. A web application is only as good as its defenses, and we've integrated measures against the most common and critical web vulnerabilities. I'll now break down each of these defenses."
5.1. Mitigation of Injection Flaws (SQL Injection)
"The number one threat to database-driven websites is SQL Injection. This is where an attacker tries to manipulate a database query by inserting their own SQL code into an input field. We completely neutralize this threat by using what are called 'Prepared Statements.' This technique separates the structure of the SQL query from the user's data. The database processes the query structure first, and then safely inserts the user data as parameters. This ensures that user input is always treated as simple text and never as executable code, making SQL injection impossible."
5.2. Mitigation of Cross-Site Scripting (XSS)
"The next major vulnerability is Cross-Site Scripting, or XSS. This happens when an attacker injects malicious JavaScript into a webpage, which then runs in the browsers of other users. We prevent this by strictly sanitizing all user-generated content before it's displayed on a page. We use PHP's `htmlspecialchars` function, which converts characters like angle brackets into harmless HTML entities. As you can see in the example, a user's attempt to inject a script tag is rendered as plain text and is never actually executed by the browser."
5.3. Secure Credential Management
"Of course, we must protect user passwords. In InkWell, we never store passwords in a recoverable format. We use the modern `password_hash` function in PHP. This creates a strong, one-way cryptographic hash of the password. It also automatically adds a unique 'salt' to each password before hashing, which means that even if two users have the same password, their stored hashes will be completely different. This protects against attacks like rainbow tables. To log a user in, we use `password_verify` to compare their submitted password against the stored hash, without ever needing to see or store the original password."
5.4. Access Control through Session Management
"Finally, we need to make sure that only authorized users can perform sensitive actions, like editing or deleting a post. We achieve this through session management. When a user logs in, the server creates a session for them. On critical pages like `edit_post.php`, the very first thing the script does is check if a valid user session exists. If it doesn't, the script stops immediately and redirects the user to the login page. This acts as a gateway, protecting these functions from unauthorized access."