1 of 56

BMIT3173 Integrative Programming

ASSIGNMENT 202505

Student Name : WO JIA QIAN

Student ID : 23WMR14023

Programme : RSWY2S3

Tutorial Group : G2

System Title : Movie Ticket Booking System

Modules : Ticket Booking & Reservation Module

Declaration
● I confirm that I have read and complied with all the terms and conditions
of Tunku Abdul Rahman University of Management and technology’s
plagiarism policy.

● I declare that this assignment is free from all forms of plagiarism and for
all intents and purposes is my own properly derived work.
 2 of 56

Plagiarism Statement Form

I, Wo Jia Qian, 2314023, RSW Y2S3 G2 confirm that the submitted work are all my own

work and is in my own words.

I, Wo Jia Qian, acknowledge the use of AI generative technology.

Signature: ________________

Date: 5/7/2025
 3 of 56

Table of Contents

1. Introduction to the System​ 4

2. Module Description​ 5
Figure 1: Buy Tickets button at the bottom right of Movie Details Page​ 6
Figure 2: Buy Tickets button at the bottom of the Movie Card Components at Home Page​
7
Figure 3: Logging in Required before able to Create Bookings​ 7
Figure 4: Choosing Desired Dates and Showtime​ 8
Figure 5: Step 1 – Selecting Seats​ 8
Figure 6: Step 2 – Checking Out​ 9
Figure 7: Step 3 – Success Message if Booking Success​ 9
Figure 8: Seat Layout before Schedule selected (part 1)​ 9
Figure 9: Seat Layout before Schedule selected (part 2)​ 10
Figure 10: Seat Layout after Schedule selected (part 1)​ 10
Figure 11: Seat Layout after Schedule selected (part 2)​ 11
Figure 12: Select Seats page after Selected Seats​ 12
Figure 13: Modal Box for Seats Tickets Confirmation​ 13
Figure 14: User attempts to decrease the number of tickets for seats​ 14
Figure 15: Error Message shows when User Clicks on “Go to Checkout”​ 15
Figure 16: User attempts to edit Seats Selected by clicking on Edit Seats button​ 16
Figure 17: User update the seats selected and clicks on the Book Seat(s) button​ 17
Figure 18: The Modal box is updated with the selected seats, user selects 1 adult, 1 child
and 1 oku​ 18
Figure 19: Order Details Confirmation Page (Part 1)​ 18
Figure 20: Order Details Confirmation Page (Part 2)​ 19
Figure 21: User attempts to Edit Seat by Clicking Edit Seats button​ 20
Figure 22: Step 3 – Confirms Booking Success​ 20
Figure 23: User clicks on the My Bookings button​ 21
Figure 24: User is redirected to My Bookings page​ 21
Figure 25: Each Booking Record item in My Bookings page​ 22
Figure 26: Receipt page of a Specific Selected Booking​ 22
Figure 27: QR code generated upon successful booking at view ticket page​ 23
Figure 28: QR code scanned via phone​ 23
Figure 29: QR code scanned via phone matching the code stored in database​ 24
Figure 30: Admin Manage Bookings Page (Part 1)​ 24
Figure 31: Admin Manage Bookings Page (Part 2)​ 25
Figure 32: Default Sorting Order Admin View Bookings​ 25
Figure 33: Sorting Booking Order by Total Price Admin View Bookings​ 26
Figure 34: Filtering Bookings based on Minimum and Maximum Price Admin View
Bookings​ 26
 4 of 56

Figure 35: Filtering Bookings without setting Maximum Price​ 27

Figure 36: Filtering Bookings without setting Minimum Price​ 27
Figure 37: Filtering Bookings by Movie Selection​ 28
3. Entity Classes​ 29
Figure 38: CCCWH Movie Ticket Booking System Analysis Class Diagram​ 29
4. Design Pattern​ 29
4.1 Description of Design Pattern​ 29
4.2 Implementation of Design Pattern​ 31
Figure 39: Implementation of Facade design pattern in Ticket Booking module​ 32
Figure 40: AdminBookingController as client of the Facade (BookingFacade)​ 33
Figure 41: BookingController as client of the Facade (BookingFacade)​ 33
Figure 42: Example of using the Facade by BookingController​ 34
5. Software Security​ 35
5.1 Potential Threat/Attack​ 35
5.1.1 Data Tampering​ 35
5.1.2 Denial of Service (DoS)​ 36
5.2 Secure Coding Practice​ 37
5.2.1 Data Protection - Least Privilege Principle (Threat 1)​ 37
Figure 43: Implementing Least Privilege Principle on IsThisMovieBookedByUser()
method in Booking Facade​ 38
Figure 44: Implementing Least Privilege Principle on finalizeBooking() method in
LiveWire/[Link]​ 38
5.2.2 Error Handling & Logging - Logging All Events & Exceptions (Threat 2)​ 39
Figure 45: Logging implemented at fetchSeats() at Livewire BookingMultiStep
Component (part 1)​ 40
Figure 46: Logging implemented at fetchSeats() at Livewire BookingMultiStep
Component (part 2)​ 40
Figure 47: Expected Log results if success calling fetchSeats() at Livewire
BookingMultiStep Component​ 41
Figure 48: Logging implemented at finalizeBooking() at Livewire BookingMultiStep
Component (part 1)​ 41
Figure 49: Logging implemented at finalizeBooking() at Livewire BookingMultiStep
Component (part 2)​ 42
Figure 50: Logging implemented at finalizeBooking() at Facade
[Link] (part 1)​ 42
Figure 51: Logging implemented at finalizeBooking() at Facade
[Link] (part 2)​ 43
Figure 52: Logging implemented at finalizeBooking() at Facade
[Link] (part 3)​ 44
Figure 53: Expected Log results if success calling finalizeBooking() at Livewire
BookingMultiStep Component​ 44
6. Web Services​ 44
6.1 Overview​ 44
6.2 Exposed Web Services​ 45
 5 of 56

6.2.1 Get All Bookings For Current User​ 45

6.2.2 Is this Movie Booked By User​ 47
Figure 54 isThisMovieBookedbyUser code​ 48
6.3 Consumed Web Services​ 48
6.3.1 Get a specific movie details based on ID​ 48
Figure 54: Implementation of Api call Getting Movie Details at Facade
[Link]​ 49
6.3.2 Get Seats by Schedule​ 50
Figure 55: Implementation of Api call Getting Seats and Schedules at Livewire
Booking Multi Step [Link]​ 51
7. Index​ 52
LIST OF FIGURES​ 52
 6 of 56

1. Introduction to the System

The Movie Ticket Booking System is a web-based application commissioned by CCCWH
Cinema Organisation to revolutionise its ticketing operations and improve customer
satisfaction, ultimately driving profitability. This system offers a seamless and accessible
platform that allows customers to browse movies, check showtimes, select seats, book tickets,
and make secure online payments from the comfort of their homes or mobile devices. By
digitising the traditional ticketing process, the system eliminates long queues at ticket
counters, reduces manual workload for staff, minimises operational errors, and prevents
financial losses due to inefficiencies.

CCCWH Cinema Organisation, a prominent cinema operator, seeks to modernise its

operations to stay competitive in the evolving cinema industry. The system directly addresses
CCCWH’s need for a scalable and efficient solution capable of handling high booking
volumes while streamlining movie schedule management and improving the accuracy of seat
allocation. Key features of the system include an intuitive movie browsing interface with
multiple selection options for genre, date, and time; a real-time, interactive seat selection map
to prevent overbooking; and integrated customer review functionality to help users make
informed viewing decisions based on real user feedback.

The system's purpose is to enhance operational efficiency by automating ticketing processes,

reducing errors, and providing data-driven insights into customer preferences and booking
trends, which CCCWH can leverage to optimise showtimes, pricing, and marketing strategies.
This can result in increased ticket sales, reduced operational costs, and the ability to upsell
premium seats or concessions, ultimately contributing to higher profits.

Furthermore, the system’s availability ensures that customers can book at any time,
anywhere, thereby boosting accessibility and convenience. For CCCWH, the system is
implemented through a robust web platform built with modern technologies, ensuring
reliability during peak booking periods. By modernising ticketing, reducing wait times, and
offering personalised experiences, the system positions CCCWH as a leader in the cinema
 7 of 56
industry, delivering value to both customers and the organisation while driving sustainable
business growth.

2. Module Description

In a nutshell, the booking module is a complete, end-to-end e-commerce solution for selling
movie tickets online. It's designed to manage the entire process, from helping a user find a
show to collecting payments and generating a confirmation. Its core functions are:

●​ Display: It shows movie information, showtimes, and an interactive seat map.

●​ Selection: It allows users to pick a date, a time, and a specific seat (or multiple seats)
on the seating chart.
●​ Calculation: It calculates the total cost based on the number and type of tickets
selected.
●​ Validation: It ensures that a user's selections are valid and that they can't book a seat
that's already taken.
●​ Finalization: It sends the final booking details to a secure system to finalize the
purchase and confirm the transaction.
●​ Documentation: It creates a record of the booking for the user to view later, including
all the details like seats, prices, and ticket types.
 8 of 56

Functionalities:

1.​ Creating a New Booking

The movie ticket booking process at CCCWH theatres starts from the click of the “Buy
Tickets” button. The buttons which are located at the movie details page where the user
attempts to know more about the details of a specific movie or directly on the homepage on
each shown “now-showing” movie card components. Once clicked, the user will be redirected
to the first step of booking — selecting the date and showtimes.

Figure 1: Buy Tickets button at the bottom right of Movie Details Page
 9 of 56

Figure 2: Buy Tickets button at the bottom of the Movie Card Components at Home Page

2.​ Validation before Start Booking Tickets

Important authentication of user identity is done before the user can start creating new
bookings, so that only authenticated logged in users are allowed to carry out actions related to
booking.

Figure 3: Logging in Required before able to Create Bookings

3.​ Choosing Desired Movie Date and Time

The authenticated user can start creating movie tickets by choosing their desired date and time
as the first step of creating a new booking of the specific movie. The user can choose from the
available line of options of dates displayed and their desired showtimes available based on the
selected day they want to watch the movie at our theatres.
 10 of 56

Figure 4: Choosing Desired Dates and Showtime

4.​ Selecting Showtime to Display Seats

Once the user selects their desired date and showtime, the user is redirected to a multi-step
form which signifies the beginning of creating a booking. It provides a guided, step-by-step
user experience for booking a movie ticket. This process handles the entire flow, from initial
selection to final confirmation. The entire process is a single page involves going from the
first step to the second step and finally the third step is booking is successfully created.

Figure 5: Step 1 – Selecting Seats

 11 of 56

Figure 6: Step 2 – Checking Out

Figure 7: Step 3 – Success Message if Booking Success

5.​ Display Seats Based on Selected Showtime without Refreshing

By default, the seats are not displayed if the user didn’t select any showtimes. Only if the user
selects a showtime, the seat layout dynamically changes based on which hall did that schedule
link to. Depending on which schedule the user selects, the seat layout related to the selected
schedule will be displayed under the schedule, below the screen image.

Figure 8: Seat Layout before Schedule selected (part 1)

 12 of 56

Figure 9: Seat Layout before Schedule selected (part 2)

Figure 10: Seat Layout after Schedule selected (part 1)

 13 of 56

Figure 11: Seat Layout after Schedule selected (part 2)

As shown in Figure 8-11, comparing Figure 9 and Figure 11, by default, the number of seats
selected is not displayed nor updated, as no seats are yet to be selected by the user. The seats
shaded dark grey signifies that these seats are already booked by other users on this date and
showtime.

6.​ Select Desired Seats Based on Selected Showtime

Once the user selects the showtime, the user can start selecting the seats desired based on the
seat layout displayed. The number of seats will be updated, and a button will be displayed
from below the screen displaying the selected seat names and the button to confirm the
selection of seats. By default the book now button is not visible until the user has selected any
seats that is available.
 14 of 56

Figure 12: Select Seats page after Selected Seats

7.​ Display Modal upon Seat Selection

Once the user decides the seats, when the user clicks on the “book seat(s)” button below, a
modal box will show up, displaying the seats selected by the user again for confirmation, and
the price of each seats depending on the type of seat.
 15 of 56

Figure 13: Modal Box for Seats Tickets Confirmation

As shown in the modal box, the selected movie title, selected date, selected showtime,
selected seats are displayed. Here, the user can select which type the tickets belong to, which
varies in terms of prices, choosing from Adult, Child and Oku.

8.​ Validation when Selecting Ticket Types

Validation is done in which regardless of what type of tickets that the user selects, the number
of ticket types must match to the number of seats selected. For example, I have selected 2
seats, which by default, the system assumes the two seats belong to 2 adults. The validation
check works in a way as shown below:
 16 of 56

Figure 14: User attempts to decrease the

number of tickets for seats
 17 of 56

Figure 15: Error Message shows when

User Clicks on “Go to Checkout”

9.​ Error if Number of Tickets did not match Number of Selected Seats

As shown in Figure 14-15, if the user tries to decrease the number of tickets while having the
number of tickets not matching the number of seats selected, an error message shows, not
allowing the user to proceed to checkout unless the number of tickets matches the number of
seats selected.

10.​ User attempts to redecide which seats to select

If the user desires to reconsider the seats, the user is allowed to click on “edit seats” which
will close the modal box, and allow the user to update the seats, which will update the selected
 18 of 56
seats and number of tickets in the modal box when the user clicks on “book seat(s)” again.

Figure 16: User attempts to edit Seats Selected by

clicking on Edit Seats button
 19 of 56

Figure 17: User update the seats selected and clicks on

the Book Seat(s) button
 20 of 56

Figure 18: The Modal box is updated with the

selected seats, user selects 1 adult, 1 child and 1
oku

11.​Proceed To Checkout

After the user has selected the seats and ready to move on to the next step, the user clicks on
the “Proceed to Checkout” button which will redirect the user to step 2 —- Order
Confirmation. This page will display the hall name that belongs to the schedule, the selected
date, the selected seats, and the price of the tickets.

Figure 19: Order Details Confirmation Page (Part 1)

 21 of 56

Figure 20: Order Details Confirmation Page (Part 2)

12.​ User Attempts to Reselect Seat at Order Details page

If the user attempts to redecide which seats to select at the Order Details Confirmation page,
the user can click on the “Edit Seats” button which will redirect the user back to the first step
which is selecting seats and update the ticket types again.
 22 of 56

Figure 21: User attempts to Edit Seat by Clicking Edit Seats button

13.​ User confirms Order Details and Checkout

Once the user confirms the order details and is ready to confirm the booking, the user can
press the “Checkout” button and proceed to finalize the booking process.

Figure 22: Step 3 – Confirms Booking Success

14.​ User redirected to View Bookings Page

At the Order Success page, there is a button of “My Bookings” coloured in red which will link
to the My Bookings page.
 23 of 56

Figure 23: User clicks on the My Bookings button

Figure 24: User is redirected to My Bookings page

15.​ View All Past Bookings

At the My Bookings page, users are able to view all past and present bookings, with the basic
details of each booking being displayed including the movie booked, the cinema hall name,
the date and showtime, the selected seats and the price.
 24 of 56

Figure 25: Each Booking Record item in My Bookings page

16.​ View Receipt of A Successful Booking

At the My Bookings page, users can click the “View Receipt” button to check the receipt of
the booking, which will contain the selected movie, the prices of each tickets, selected seats,
and a unique qr code which contain a unique code that links to the code that is stored in the
database.

Figure 26: Receipt page of a Specific Selected Booking

 25 of 56

17.​ Receipt QR code for Authenticity Validation

The generated qr code is actually a unique code stored within the qr code that is the same as
the code stored to the database record to that booking. This can be useful for the theatre
counter staff to use the code scanned for ticket authenticity checking.

Figure 27: QR code generated upon successful booking at

view ticket page

Figure 28: QR code scanned via phone

 26 of 56

Figure 29: QR code scanned via phone matching the code

stored in database

18.​ View Booking Transactions for Admin

The admin view booking page provides a one page dashboard showing the overall CCCWH
theatre revenue and total bookings made in the system.

Figure 30: Admin Manage Bookings Page (Part 1)

 27 of 56

Figure 31: Admin Manage Bookings Page (Part 2)

19.​ Sorting Bookings for Admin

The view bookings page for admin allows them to sort and filter displayed bookings records
of all users based on their needs. By default, the booking records are not filtered, but it is
sorted by the latest booking date by default.

Figure 32: Default Sorting Order Admin View Bookings

 28 of 56

Figure 33: Sorting Booking Order by Total Price Admin View Bookings

20.​ Filtering Bookings based on Price for Admin

This allows the admin to filter the displayed booking transactions based on price by setting the
minimum price and maximum price. The result will be displaying booking transactions that
result in total amount within the set minimum and maximum price.

Figure 34: Filtering Bookings based on Minimum and Maximum Price Admin View
Bookings
 29 of 56

Figure 35: Filtering Bookings without setting Maximum Price

Figure 36: Filtering Bookings without setting Minimum Price

21.​ Filtering Bookings based on Movie for Admin

This allows the admin to filter the displayed booking transactions based on movies available
in the system. This can be helpful for admin to see trends in the popularity of a particular
movie and how well a particular movie is accepted by the public, which is useful for decision
making for developing marketing strategies based on trends in bookings of movies.
 30 of 56

Figure 37: Filtering Bookings by Movie Selection

 31 of 56

3. Entity Classes

Figure 38: CCCWH Movie Ticket Booking System Analysis Class Diagram

4. Design Pattern

4.1 Description of Design Pattern

The Facade design pattern is a structural pattern that provides a simplified, higher-level
interface to a complex subsystem. Its primary goal is to hide the complexity of that
subsystem from the client code. Instead of the client having to interact with many
different classes and objects to perform a single task, it interacts with one, unified Facade
class.

In your movie ticket booking module, the BookingController acts as the client, and the
various models and database transactions (Booking, BookingSeat, Schedule, DB) make
up the complex subsystem. Your BookingFacade acts as the intermediary.

The technical flow of Facade design pattern works like this:

 32 of 56
1.​ Client Request: The user triggers an action that leads to the BookingController's
method (e.g., a POST request to cancel).

2.​ Simplified Call: The controller doesn't contain any database logic. It makes a single,
clean method call: $this→bookingFacade→cancelBooking($booking). The controller
is now free from the "how" and is only concerned with the "what."

3.​ Facade Orchestration: The BookingFacade method receives this request. It then
orchestrates all the necessary lower-level actions to complete the task. This includes:
a.​ Accessing the Booking model.
b.​ Iterating through the bookingSeats collection.
c.​ Calling the updateExistingPivot method on the schedule relationship.
d.​ Enclosing all of this in a database transaction to ensure atomicity.

4.​ Result Return: The facade returns a simple, final result (true or false) to the
controller, which then uses this to determine the next step (e.g., redirecting to a
success page or showing an error).

Using the Facade pattern to the CCCWH Movie Ticket Booking system provides significant
benefits that make the code more robust, scalable, and maintainable. Without a facade, the
BookingController would be bloated with logic for every step. It would have
DB::beginTransaction(), looping through the seats, pivot table updates, and error handling
with DB::rollBack() [Link] is difficult to read and manage. With the use of Facade pattern,
the controller's code is clean and adheres to the Single Responsibility Principle. It only
handles the HTTP request and response flow, leaving the business logic to the facade. This
makes the controller's purpose immediately clear to any developer.

The Facade encapsulates all the complex business logic in one central place. All code related
to canceling a booking (transaction management, seat updates, status changes) is in a single
method. This makes the CCCWH Movie Ticket Booking system more reliable because you
have a single source of truth for how a cancellation should occur. If a bug is found, you know
exactly where to fix it.
 33 of 56

4.2 Implementation of Design Pattern

 34 of 56
Figure 39: Implementation of Facade design pattern in Ticket Booking module

The UML diagram clearly shows that both of the clients (BookingController and
AdminBookingController) are completely decoupled from the underlying complexity of
your system. They only interact with the BookingFacade, which acts as a powerful, central
orchestrator.

The facade, in turn, manages all the different subsystems, including your Eloquent models
(Booking, Schedule, Movie, etc.) and Laravel's own facades for database transactions (DB),
logging (Log), and HTTP requests (Request).

By putting all the complex logic inside the BookingFacade, you have created a system that is:

●​ Highly Reusable: The same facade methods are used for two different purposes
(user-facing booking and admin reporting). This is true because as seen in the class
diagram, there are two clients to the facade, demonstrating that the facade's
functionality is not tied to a single user context. It provides a consistent, logical API
for booking-related operations across the entire application. For example: for the filter
and sorting bookings, The facade abstracts away a remarkable amount of complexity,
while also including subsystems like Laravel’s DB facade, as the
filterAndSortingBookings method relies heavily on its low-level query builder to
construct a complex subquery.

●​ Easy to Maintain: All booking-related logic is in one place. If you need to change
how you store or retrieve a booking, you only have to modify the facade. The
controller remains completely untouched, saving developers a tremendous amount of
refactoring effort. Also, the Facade encapsulates all the complex business logic in one
central place. All code related to finalizing a booking (transaction management, seat
updates, status changes) is in a single method. This makes your system more reliable
because we have a single source of truth for how a booking creation should occur. If a
 35 of 56
bug is found, we know exactly where to fix it

●​ Clean and Readable: The Facade design pattern makes your code more readable by
perfectly aligning with the Single Responsibility Principle. Your Controller now has a
single, clear responsibility: handling the HTTP request-response cycle. All the
complex, behind-the-scenes booking logic is delegated to the Facade, which has its
own single responsibility. This separation of concerns makes your code incredibly
easy to read, debug, and maintain.

Figure 40: AdminBookingController as client of the Facade (BookingFacade)

Figure 41: BookingController as client of the Facade (BookingFacade)

 36 of 56

Figure 42: Example of using the Facade by BookingController

 37 of 56

5. Software Security

5.1 Potential Threat/Attack

5.1.1 Data Tampering

In general terms, Data Tampering is the unauthorized, intentional modification of data.

It's about an attacker changing data in a system to their advantage. Data Tampering often
correlates with the term “Privilege Escalation” which means when an attacker gains a higher
level of access to a system than they are authorized for.

The two terms often go hand-in-hand. An attacker might tamper with data to trick the
system into granting them privileges they shouldn't have. In the CCCWH movie booking
system, this threat could happen at the point where a user confirms their booking. The
step-to-step breakdown of a possible attack on Tampering Data:

1)​ A Legitimate User “Alice” Starts a booking, logs in and selects two seats for a movie.
Her browser, and the front-end code, correctly identifies her account_id (e.g., 123).

2)​ An attacker, "Mellow," is watching the network traffic. When Alice's browser sends the
POST request to our reserve tickets API endpoint to finalize the booking, Mallory
intercepts the request payload.

3)​ The payload contains all the booking details, including the account_id. The attacker
tampers with this data, changing the account_id from Alice's (123) to a different account
ID they want to exploit, perhaps a higher-privileged account.

4)​ The System is Fooled: If your system's finalizeBooking method blindly trusts the
account_id sent in the request, it will create the new booking record and associate it with
the account the hacker tampered with and modified.
 38 of 56
As a result, the booking record is now incorrectly associated with another account, corrupting
your data, meaning data is tampered with. Plus, the target injected account (the attacker's
target) now has an unauthorized booking in their name. Since CCCWH theatres provide
features (like a digital ticket, a QR code) based on bookings, the attacker has successfully
gained access to these services without having paid for them or performed the action
themselves. This is a classic example of an Injection Attack where malicious data
(account_id) is "injected" into a legitimate request to bypass security controls.

​ ​

5.1.2 Denial of Service (DoS)

A Denial of Service (DoS) attack is a significant threat to any web application, and it's
especially dangerous for a booking system where the availability of resources (like movie
seats) is critical.

A DoS attack is an attempt to make a machine or network resource unavailable to its intended
users. This is typically done by temporarily or indefinitely disrupting the services of a host
connected to the [Link] most common way to do this is to overwhelm the target machine
with a flood of traffic, forcing it to consume all its resources (CPU, memory, database
connections) trying to handle the flood, leaving no resources for legitimate users.

In the context of the CCCWH booking system, an attacker doesn't necessarily need to be a
skilled hacker; they just need a simple script. Here's how a DoS attack could unfold using the
finalizeBooking endpoint:

1)​ Exploiting Race Conditions: Booking Module is designed to handle legitimate

concurrent requests, so it uses lockForUpdate to prevent two users from booking the
same seat at the same time which is considered a good security practice. However, an
attacker can intentionally exploit this mechanism.
 39 of 56

2)​ The Attack: An attacker could write a simple script that sends thousands of simultaneous
API requests to finalizeBooking, all attempting to reserve the same set of seats that they
know are already taken or invalid.

3)​ The Overload: Each of these requests will trigger a DB::beginTransaction() and an
attempt to lock the seats. Since the seats are unavailable, each transaction will fail, and
your catch block will be executed, triggering a DB::rollBack()

4)​ The Result: The server is now spending all its resources (CPU cycles, memory, and
database connections) on starting and immediately rolling back thousands of database
transactions. This becomes an extremely resource-intensive process. Legitimate users who
try to book a ticket will find the system slow or completely unresponsive because the
server is too busy processing the malicious, failed transactions. The service is effectively
denied to paying customers.​

5.2 Secure Coding Practice

5.2.1 Data Protection - Least Privilege Principle (Threat 1)

​
The principle of least privilege directly addresses the threat of data tampering by attackers
upon booking requests by the user, in which an attacker could attempt to manipulate the API
request to book a movie ticket under another user's account by changing the account_id in the
request payload. To prevent this, Booking Module has implemented Data Protection by
implementing Least Privilege Principle by ensuring that only the current authenticated user
using the system can have booking success. By restricting the finalizeBooking process to only
operate on data for the authenticated user, we prevent one user from creating a booking for
another account id.
 40 of 56

Figure 43: Implementing Least Privilege Principle on

IsThisMovieBookedByUser() method in Booking Facade

The isThisMovieBookedByUser() method in BookingFacade directly demonstrates the

principle of least privilege. It is done by explicitly using →where('account_id', $account_id)
in its query. This means that even if a malicious user tries to pass in a different account_id in
their API request, the facade will only search for a booking that matches the user ID provided.
It will not return a result for any other user's booking. This is a crucial application of least
privilege: the query's scope is restricted to the specific user's data, preventing unauthorized
access.

Figure 44: Implementing Least Privilege Principle on finalizeBooking() method

in LiveWire/[Link]
 41 of 56

5.2.2 Error Handling & Logging - Logging All Events & Exceptions (Threat 2)

An attacker could program a script to rapidly send a large number of booking requests with
invalid or already-taken seat IDs. This could cause the booking system to repeatedly start and
then roll back database transactions, consuming significant server resources and potentially
leading to a resource bottleneck or a system crash. The Booking Facade’s finalizeBooking
facade method explicitly logs an error when a transaction is rolled back due to an exception
(e.g., "One or more selected seats are no longer available"). An administrator monitoring the
logs would quickly see a high volume of these specific error messages originating from a
single IP address, providing the necessary data to identify and block the malicious user before
the system is overwhelmed. Without this logging, the failed attacks would be invisible,
making the system vulnerable.

Think of it as a smoke detector. It doesn't put out the fire, but it alerts you to the danger so you
can take action.

1)​ Early Detection: The detailed error logging for the Booking module is a powerful
monitoring tool. The Log::error calls inside your try...catch blocks will record a clear,
consistent error message for every failed booking attempt.
2)​ Pattern Recognition: An administrator monitoring the logs would see an unusually
high volume of specific error messages, such as "One or more selected seats are no
longer available." or "Database transaction rolled back." This pattern—many
identical errors in a short period—is a strong indicator of a malicious attack, not just a
normal user error.
3)​ Rapid Response: Once the pattern is identified, the administrator can quickly find the
source of the attack by checking the IP addresses associated with the logged requests.
They can then implement a firewall rule to block the malicious IP, effectively stopping
the attack.

Without robust logging, the system would simply become slow and unresponsive, and we
wouldn't know why. We would be blind to the attack until it was too late.
 42 of 56

Figure 45: Logging implemented at fetchSeats() at Livewire

BookingMultiStep Component (part 1)

Figure 46: Logging implemented at fetchSeats() at Livewire

BookingMultiStep Component (part 2)
 43 of 56

Figure 47: Expected Log results if success calling fetchSeats() at

Livewire BookingMultiStep Component

Figure 48: Logging implemented at finalizeBooking() at

Livewire BookingMultiStep Component (part 1)
 44 of 56

Figure 49: Logging implemented at finalizeBooking() at

Livewire BookingMultiStep Component (part 2)

Figure 50: Logging implemented at finalizeBooking() at Facade

[Link] (part 1)
 45 of 56

Figure 51: Logging implemented at finalizeBooking() at Facade

[Link] (part 2)
 46 of 56
Figure 52: Logging implemented at finalizeBooking() at Facade
[Link] (part 3)

Figure 53: Expected Log results if success calling

finalizeBooking() at Livewire BookingMultiStep Component

6. Web Services

6.1 Overview

The choice to use a RESTful API for the Booking Module is highly beneficial, as it adheres to
the Interface Agreement (IFA) standards and offers several advantages, which includes
statelessness, in which each API request from the Booking Module to the Review Module or
other modules is self-contained. The RESTful architecture ensures that the Booking Module
is not tightly tied to the internal implementation of other modules. If the Movie or Schedule
Management Modules change their database schemas, as long as their API endpoints remain
the same, the Booking Module will continue to function correctly. This is the very definition
of a modular and scalable system.
 47 of 56

6.2 Exposed Web Services

The Booking Module exposes several RESTful API endpoints to enable other modules to
interact with booking data. These endpoints are defined in your API routes and managed by
the BookingController. They are primarily consumed by the Review Module and other
internal services.

6.2.1 Get All Bookings For Current User

Webservice Mechanism

Item Description

Protocol RESTFUL

Function Retrieves a list of all bookings based on the given account_id

Description

Source Module Ticket Booking Module

Target Module User Management Module

URL [Link]

Function Name getBookingsByAccount

Web Services Request Parameter (provide)

Field Name Field Type Mandatory/ Description Format

Optional

id Integer Mandatory Unique ID of an Numeric

account
 48 of 56
Web Services Response Parameter (consume)

Field Name Field Type Mandatory/ Description Format

Optional

id Integer Mandatory Unique ID of the Numeric

booking

schedule_id Integer Mandatory ID of the Numeric

associated
schedule

booking_time String Mandatory Date and time of "2025-09-15T14:

creating booking 00:00.000000Z"

total_amount String Mandatory Total price of

bookings

qr_code String Mandatory Unique qr code

for each bookings

status String Mandatory Status of each

retrieved
bookings

created_at String Mandatory Date and time of "2025-09-15T14:

creating new 00:00.000000Z"
booking

updated_at String Mandatory Date and time for "2025-09-15T14:

updating 00:00.000000Z"
bookings

Code Snippets

In [Link]

Figure 6.2.2 getBookingsByAccount code

 49 of 56
6.2.2 Is this Movie Booked By User

Item Description

Protocol RESTFUL

Function Retrieves a boolean for validating if the current user has made bookings of a
Description specific movie

Source Module Ticket Booking Module

Target Module Review Module

URL [Link]

Function Name isBooked

Web Services Request Parameter (provide)

Field Name Field Type Mandatory/ Description Format

Optional

$movieId Integer Mandatory Unique ID for a Numeric

movie

$accountId Integer Mandatory Authenticated Numeric

User ID

Web Services Request Parameter (consume)

Field Name Field Type Mandatory/ Description Format

Optional

$response Boolean Mandatory Chcck results of Numeric

Code Snippets
 50 of 56

In [Link]

Figure 54 isThisMovieBookedbyUser code

6.3 Consumed Web Services

6.3.1 Get a specific movie details based on ID

Web Services Request Parameter (provide)

From the consumer (Ticket Booking Module) perspective, provide ID in the path

Field Name Field Type Mandatory/ Description Format

Optional

id Integer Mandatory Unique ID of the Numeric

movie

Web Services Response Parameter (consume)

Field Name Field Type Mandatory/ Description Format

Optional

id Integer Mandatory Movie ID Numeric

title String Mandatory Movie title Text

genre String Mandatory Movie genre Text

duration Integer Mandatory Movie duration Numeric (e.g.,

in minutes 120)
 51 of 56

language String Mandatory Movie language Text

image_path String Mandatory Path to movie Text

image

Webservice Mechanism

Item Description

Protocol RESTFUL

Function Retrieves a list of movie details, based on the movie id passed

Description

Source Module Movie Management Module

Target Module Ticket Booking Module

URL [Link]

Function Name -

Figure 54: Implementation of Api call Getting Movie Details at

Facade [Link]
 52 of 56

6.3.2 Get Seats by Schedule

Web Services Request Parameter (provide)

Field Name Field Type Mandatory/ Description Format

Optional

scheduleId Integer Mandatory ID of the Numeric

schedule

Web Services Response Parameter (consume)

The response is a JSON array of seat objects.

Field Name Field Type Mandatory/ Description Format

Optional

id Integer Mandatory Unique ID of the Numeric

seat

pivot_id Integer Mandatory Unique ID of the Numeric

schedule_seats
entry

status String Mandatory Availability "available"

status "booked"

row_char String Mandatory Row identifier Alphabetic

(e.g., "A")

seat_number Integer Mandatory Seat number in Numeric

the row

name String Mandatory Computed seat Alphanumeric

name (e.g., "A1")
 53 of 56

Figure 55: Implementation of Api call Getting Seats and

Schedules at Livewire Booking Multi Step [Link]
 54 of 56

7. Index

LIST OF FIGURES
No ​​ Tittle Page
1. Introduction to the System​ 4
2. Module Description​ 5
Figure 1: Buy Tickets button at the bottom right of Movie Details Page​ 6
Figure 2: Buy Tickets button at the bottom of the Movie Card Components at Home Page​
7
Figure 3: Logging in Required before able to Create Bookings​ 7
Figure 4: Choosing Desired Dates and Showtime​ 8
Figure 5: Step 1 – Selecting Seats​ 8
Figure 6: Step 2 – Checking Out​ 9
Figure 7: Step 3 – Success Message if Booking Success​ 9
Figure 8: Seat Layout before Schedule selected (part 1)​ 9
Figure 9: Seat Layout before Schedule selected (part 2)​ 10
Figure 10: Seat Layout after Schedule selected (part 1)​ 10
Figure 11: Seat Layout after Schedule selected (part 2)​ 11
Figure 12: Select Seats page after Selected Seats​ 12
Figure 13: Modal Box for Seats Tickets Confirmation​ 13
Figure 14: User attempts to decrease the number of tickets for seats​ 14
Figure 15: Error Message shows when User Clicks on “Go to Checkout”​ 15
Figure 16: User attempts to edit Seats Selected by clicking on Edit Seats button​ 16
Figure 17: User update the seats selected and clicks on the Book Seat(s) button​ 17
Figure 18: The Modal box is updated with the selected seats, user selects 1 adult, 1 child
and 1 oku​ 18
Figure 19: Order Details Confirmation Page (Part 1)​ 18
Figure 20: Order Details Confirmation Page (Part 2)​ 19
Figure 21: User attempts to Edit Seat by Clicking Edit Seats button​ 20
Figure 22: Step 3 – Confirms Booking Success​ 20
Figure 23: User clicks on the My Bookings button​ 21
Figure 24: User is redirected to My Bookings page​ 21
Figure 25: Each Booking Record item in My Bookings page​ 22
Figure 26: Receipt page of a Specific Selected Booking​ 22
Figure 27: QR code generated upon successful booking at view ticket page​ 23
Figure 28: QR code scanned via phone​ 23
Figure 29: QR code scanned via phone matching the code stored in database​ 24
Figure 30: Admin Manage Bookings Page (Part 1)​ 24
 55 of 56

Figure 31: Admin Manage Bookings Page (Part 2)​ 25

Figure 32: Default Sorting Order Admin View Bookings​ 25
Figure 33: Sorting Booking Order by Total Price Admin View Bookings​ 26
Figure 34: Filtering Bookings based on Minimum and Maximum Price Admin View
Bookings​ 26
Figure 35: Filtering Bookings without setting Maximum Price​ 27
Figure 36: Filtering Bookings without setting Minimum Price​ 27
Figure 37: Filtering Bookings by Movie Selection​ 28
3. Entity Classes​ 29
Figure 38: CCCWH Movie Ticket Booking System Analysis Class Diagram​ 29
4. Design Pattern​ 29
4.1 Description of Design Pattern​ 29
4.2 Implementation of Design Pattern​ 31
Figure 39: Implementation of Facade design pattern in Ticket Booking module​ 32
Figure 40: AdminBookingController as client of the Facade (BookingFacade)​ 33
Figure 41: BookingController as client of the Facade (BookingFacade)​ 33
Figure 42: Example of using the Facade by BookingController​ 34
5. Software Security​ 35
5.1 Potential Threat/Attack​ 35
5.1.1 Data Tampering​ 35
5.1.2 Denial of Service (DoS)​ 36
5.2 Secure Coding Practice​ 37
5.2.1 Data Protection - Least Privilege Principle (Threat 1)​ 37
Figure 43: Implementing Least Privilege Principle on IsThisMovieBookedByUser()
method in Booking Facade​ 38
Figure 44: Implementing Least Privilege Principle on finalizeBooking() method in
LiveWire/[Link]​ 38
5.2.2 Error Handling & Logging - Logging All Events & Exceptions (Threat 2)​ 39
Figure 45: Logging implemented at fetchSeats() at Livewire BookingMultiStep
Component (part 1)​ 40
Figure 46: Logging implemented at fetchSeats() at Livewire BookingMultiStep
Component (part 2)​ 40
Figure 47: Expected Log results if success calling fetchSeats() at Livewire
BookingMultiStep Component​ 41
Figure 48: Logging implemented at finalizeBooking() at Livewire BookingMultiStep
Component (part 1)​ 41
Figure 49: Logging implemented at finalizeBooking() at Livewire BookingMultiStep
Component (part 2)​ 42
Figure 50: Logging implemented at finalizeBooking() at Facade
[Link] (part 1)​ 42
Figure 51: Logging implemented at finalizeBooking() at Facade
[Link] (part 2)​ 43
Figure 52: Logging implemented at finalizeBooking() at Facade
[Link] (part 3)​ 44
 56 of 56

Figure 53: Expected Log results if success calling finalizeBooking() at Livewire

BookingMultiStep Component​ 44
6. Web Services​ 44
6.1 Overview​ 44
6.2 Exposed Web Services​ 45
6.2.1 Get All Bookings For Current User​ 45
6.2.2 Is this Movie Booked By User​ 47
Figure 54 isThisMovieBookedbyUser code​ 48
6.3 Consumed Web Services​ 48
6.3.1 Get a specific movie details based on ID​ 48
Figure 54: Implementation of Api call Getting Movie Details at Facade
[Link]​ 49
6.3.2 Get Seats by Schedule​ 50
Figure 55: Implementation of Api call Getting Seats and Schedules at Livewire
Booking Multi Step [Link]​ 51
7. Index​ 51
LIST OF FIGURES​ 51