UniFind

Project Overview

Problem Statement

On a large university campus, the process of recovering lost personal items is often stressful, inefficient, and reliant on luck. There is typically no centralized system for reporting lost items or handing in found ones. This leads to a high volume of unclaimed property and creates a sense of inconvenience and insecurity among the campus community.

Project Objective

UniFind aims to solve this problem by providing a centralized, efficient, and user-friendly Lost and Found Management System for the Northern University of Business and Technology Khulna. The goal is to create a single online platform that simplifies the process of reuniting lost items with their rightful owners, fostering a more secure and supportive campus environment.

Key Features

For General Users:

  • Secure Accounts: Users can register, log in, and manage their profiles.
  • Item Reporting: Submit detailed reports for both lost and found items, including descriptions, locations, dates, and images.
  • Advanced Search: A powerful search engine to filter items by category, department, date, and keywords.
  • Automatic Matching: The system intelligently suggests potential matches for newly reported items.
  • Report Management: Users can view and manage the status of their reported items.

For Administrators:

  • Central Dashboard: An overview of system statistics (total users, items, matches).
  • Full CRUD Control: Admins can Create, Read, Update, and Delete users, items, categories, and departments.
  • Match Verification: Admins can review, confirm, or reject potential matches flagged by users.
  • User Management: Ability to edit user details and grant or revoke admin privileges.

Technology Stack

The project is a classic web application built on a LAMP-like stack.

  • Backend: PHP is used for all server-side logic, including database interaction, user authentication, and business logic.
  • Database: MySQL stores all persistent data, such as user profiles, item reports, and system settings. The schema is defined in unifind_db.sql.
  • Frontend: The user interface is built with standard HTML, styled with CSS (including the Bootstrap framework for responsiveness), and made interactive with JavaScript and jQuery.

System Architecture & Design

Directory & File Structure

The project is organized into a modular structure that separates concerns, making it easier to maintain and understand.

  • / (Root): Contains user-facing pages like index.php, login.php, and search.php.
  • /includes/: The core of the application's backend logic.
    • db.php: Handles the MySQL database connection.
    • auth.php: Manages user authentication (registration, login, sessions, access control).
    • functions.php: A library of reusable functions for tasks like image uploads, searching, and matching.
  • /admin/: A protected directory containing the entire administrative panel for site management.
  • /assets/: Stores static files like CSS stylesheets and JavaScript files.
  • /uploads/: The destination directory for all user-uploaded images of items.

Database Schema

The database is the backbone of the system, designed to store all information in a structured way. The key tables are:

Table Name Purpose Key Columns
users Stores user account information. id, username, password (hashed), email, role ('user' or 'admin')
lost_items Contains details of all reported lost items. id, user_id, category_id, title, description, location, lost_date, status
found_items Contains details of all reported found items. id, user_id, category_id, title, description, location, found_date, status
matches Links a lost item to a found item when a claim is made. id, lost_item_id, found_item_id, claimer_id, status ('pending', 'confirmed', 'rejected')
categories A lookup table for item categories (e.g., 'Electronics', 'ID Card'). id, name
departments A lookup table for university departments. id, name

Deep Dive: Core Logic & Security

User Authentication Flow

Authentication is handled by includes/auth.php and is crucial for securing the system.

  1. Registration: A new user signs up via signup.php. The registerUser() function in auth.php is called. It first checks if the username or email already exists. Crucially, it hashes the password using PHP's native password_hash() function before inserting the new user into the database. This ensures plain-text passwords are never stored.
  2. Login: A user logs in via login.php. The loginUser() function retrieves the user record by username. It then uses password_verify() to compare the submitted password against the stored hash. This is a secure way to check passwords without ever decrypting the stored hash.
  3. Session Management: Upon successful login, a PHP session is started (session_start()). Key information like user_id, username, and role is stored in the $_SESSION superglobal.
  4. Access Control: On protected pages (e.g., profile.php or any admin page), the script first checks isLoggedIn(). For the admin panel, it also checks isAdmin(). These functions simply check the values in the $_SESSION variable to grant or deny access, redirecting unauthorized users to the login page.

The Automatic Matching Algorithm

This is one of the project's core "intelligent" features, handled by findPotentialMatches() in functions.php. When a user reports a lost item, the system automatically searches for potential matches in the found items table based on three criteria:

  • Same Category: It only looks for items in the same category (e.g., if a 'Phone' is lost, it only searches for found 'Phones').
  • Similar Location: It performs a simple text match on the location field.
  • Close Date: It looks for found items reported on the same day as the lost item was reported lost.

Here is a simplified view of the SQL query logic inside the function:


-- This is a conceptual representation of the query
SELECT * FROM found_items
WHERE 
    status = 'active' AND
    category_id = ? AND -- (1) Match the category of the lost item
    location LIKE ? AND -- (2) Match the location
    DATE(found_date) = ?; -- (3) Match the date

This proactive suggestion helps users quickly identify if their item has already been found, significantly speeding up the recovery process.

Security Measures

Security is a critical non-functional requirement. Here’s how it's implemented:

  • Password Hashing: As mentioned, password_hash() and password_verify() are used, which is the industry standard for password management. It protects against rainbow table attacks.
  • SQL Injection Prevention: The application uses Prepared Statements with parameter binding for all database queries. Instead of inserting variables directly into SQL strings, placeholders (?) are used. This separates the SQL command from the data, making it impossible for an attacker to inject malicious SQL code through input fields.
  • Cross-Site Scripting (XSS) Prevention: When displaying user-generated content (like item descriptions), the application should use functions like htmlspecialchars(). This converts special HTML characters (e.g., <, >) into their HTML entities, preventing them from being rendered as HTML and executing malicious scripts.
  • Role-Based Access Control (RBAC): The system strictly separates user and admin privileges. The isAdmin() check on every admin page ensures that regular users cannot access administrative functions, even if they know the direct URL.
  • File Upload Security: The uploadImage() function in functions.php includes checks to validate file type and size. This prevents users from uploading malicious files (e.g., a PHP shell) disguised as images. It also generates a unique filename to avoid path traversal issues.