DEVELOPMENT SCRIPTS

Section 6 — Pseudo Code, Algorithms & Internal Logic

Rent For Cents — Bike Rental System

MERN Stack | [Link] + [Link] | [Link] | MongoDB | JWT Auth

Section: 6 — Development Scripts

Report: Low Level Design (LDL) Report

Project: Rent For Cents — Bike Rental System

Modules: 8 — Registration, Auth, Profile, Bikes, Booking, Manager, Feedback

Team: 5 Members (R1–R5)

Development Scripts | Rent For Cents | LDL Report | 2025

 6 Development Scripts

This section presents the development scripts, algorithms, pseudo-code, and internal logic for each
functional module of the Rent For Cents Bike Rental System. The system is built on a MERN stack
architecture comprising MongoDB as the document-oriented database, [Link] for the REST API
server, [Link] for the client-side single-page application, and [Link] as the runtime environment.
Authentication is implemented using JSON Web Tokens (JWT) with bcrypt-based password hashing.
Each module below describes its purpose, algorithm, internal logic, and API/database interactions.

Module
Module Name Primary Technology API Route
No.

6.1 User Registration [Link] + MongoDB POST /signup

6.2 Login Authentication JWT + bcrypt POST /signin

6.3 User Profile Update React + Fetch API PUT /update/:id

6.4 Bike Management Express + MongoDB POST /addBike

6.5 Bike Viewing React useEffect GET /getBike

6.6 Booking System Express + MongoDB POST /bookBike/...

6.7 Manager Verification Express PATCH PATCH /confirm/:id

6.8 Feedback Module Express + MongoDB POST /contactUs

6.1 User Registration Module

Purpose: Registers a new customer

with KYC data into the system Collection: users API Route: POST /signup

Algorithm:

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 1

 ALGORITHM: UserRegistration
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : { name, email, password, mobile, DOB, gender,
address, bankDetails, documentDetails }
OUTPUT: { success: true, token: JWT, userId: Number }
BEGIN
STEP 1: Receive POST request at /signup
STEP 2: Extract request body fields
STEP 3: Validate required fields
IF any required field is empty THEN
RETURN 400 { error: "All fields required" }
END IF
STEP 4: Query users collection
IF email already exists in DB THEN
RETURN 409 { error: "Email already registered" }
END IF
STEP 5: Hash password
hashedPassword = [Link](password, 12)
STEP 6: Generate unique numeric userId
userId = generateUniqueId()
STEP 7: Build user document
userDoc = { ID: userId, userDetails: {...},
addressDetails: {...},
bankDetails: {...},
documentDetails: {...},
verified: false,
registeredOn: [Link]() }
STEP 8: Save document to users collection
await [Link]()
STEP 9: Generate JWT token
token = [Link]({ id: userId }, SECRET, { expiresIn: "10m" })
STEP 10: Store token in [Link] field
STEP 11: Set HTTP-only cookie with token
STEP 12: RETURN 201 { success: true, token, userId }
END

Internal Logic Explanation: The registration module executes as a 4-step wizard on the React
frontend. Each step validates its own fields before advancing. On Step 4 (document upload), images
are read via the browser's FileReader API and converted to base64 strings stored in React state.
The complete payload is dispatched as a single fetch() POST request on final submission. The
backend uses Mongoose with nested sub-schemas (userDetails, addressDetails, bankDetails,
documentDetails) to persist all KYC data.

DB Interaction: [Link]() — new State Mgmt: React useState for each Security: bcryptjs hash (salt=12), JWT
document creation form step (10min expiry)

[Insert Registration Backend Route Screenshot — [Link] / POST /signup]

[Insert Registration UI Screenshot — Multi-step KYC Form (Step 1–4)]

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 2

 6.2 Login Authentication Module

Purpose: Authenticate user/manager Collection: users / API Routes: POST /signin | POST
and issue a JWT session token managerCredentials /managerLogin

Algorithm:

ALGORITHM: LoginAuthentication
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : { email: String, password: String }
OUTPUT: { success: true, userData: Object, token: JWT }
BEGIN
STEP 1: Receive POST /signin request
STEP 2: Extract { email, password } from request body
STEP 3: Search users collection
user = await [Link]({ "[Link]": email })
IF user NOT FOUND THEN
RETURN 404 { error: "User not found" }
END IF
STEP 4: Compare passwords
match = await [Link](password, [Link])
IF match == false THEN
RETURN 401 { error: "Invalid credentials" }
END IF
STEP 5: Generate JWT token
token = [Link]({ id: [Link] }, JWT_SECRET,
{ expiresIn: "10m" })
STEP 6: Store token
[Link] = token
await [Link]()
STEP 7: Set HTTP-only cookie
[Link]("loginToken", token, { httpOnly: true })
STEP 8: Store user data in localStorage (client-side)
[Link]("name", [Link])
[Link]("id", [Link])
[Link]("verified", [Link])
STEP 9: Redirect to /user-dashboard
STEP 10: RETURN 200 { success: true, userData, token }
END
MANAGER LOGIN VARIANT:
Route: POST /managerLogin
Collection: managerCredentials
Note: Password compared as plain text (v1 known issue)
On success: redirect to /manager-dashboard

Internal Logic Explanation: The login form uses a CSS-animated flip panel in React — the front
face is Sign In, the reverse is Sign Up. On form submission, a fetch() POST call is made to the
backend. The [Link] middleware reads the JWT from the cookie header and validates it
using [Link]() before allowing access to any manager-protected route. User session data (name,
id, verified status) is stored in localStorage and read on each dashboard render.

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 3

 JWT Expiry: 10 minutes — stored as Middleware: [Link] validates Logout Logic: [Link]() +
HTTP-only cookie token on each protected route cookie deletion on Log Out click

[Insert Login API Screenshot — [Link] POST /signin response]

[Insert Login Screen Screenshot — Animated Flip Panel (Sign In / Sign Up)]

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 4

 6.3 User Profile Update Module

Purpose: Allow users to view and edit API Route: GET /userData/:id | PUT
all profile sub-sections Component: [Link] (React Modal) /update/:id

Algorithm:

ALGORITHM: UserProfileUpdate
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : userId (from localStorage), updatedFields
OUTPUT: { success: true, updatedUser: Object }
BEGIN
// FETCH PHASE
STEP 1: On modal open, read userId from localStorage
STEP 2: Call GET /userData/:id
response = await fetch("/userData/" + userId)
STEP 3: Populate React state with returned sub-schemas
setUserDetails([Link])
setAddressDetails([Link])
setBankDetails([Link])
setDocumentDetails([Link])
// EDIT PHASE
STEP 4: Render form fields pre-filled with state values
STEP 5: User modifies desired fields
onChange handler updates corresponding state key
// IMAGE UPLOAD PHASE
STEP 6: User selects image file (ID / DL / photo / passbook)
IF [Link] > 2MB THEN
ALERT "File too large — max 2MB"
RETURN (abort upload)
END IF
STEP 7: Create FileReader instance
reader = new FileReader()
[Link](file)
[Link] = (e) => setImageState([Link])
// base64 string stored in React state array
// SAVE PHASE
STEP 8: User clicks Save
STEP 9: Build updated payload from all state objects
STEP 10: Call PUT /update/:id with payload
response = await fetch("/update/" + userId, {
method: "PUT",
body: [Link](updatedPayload)
})
STEP 11: Backend validates userId from JWT middleware
STEP 12: Update fields using Mongoose $set operator
await [Link]({ ID: userId },
{ $set: payload })
STEP 13: RETURN 200 { success: true, updatedUser }
STEP 14: Re-fetch profile data and re-render modal
END

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 5

 Internal Logic Explanation: The Profile modal is rendered using ReactModal overlaying the User
Dashboard. Four tabbed sections (Personal, Address, Bank, Documents) correspond to the four
MongoDB sub-schemas. Image fields use a dedicated imageArray state variable that holds up to
four base64 strings simultaneously. The [Link]() method converts binary file
data into base64 strings without server involvement. The PUT endpoint uses Mongoose's
findOneAndUpdate() with { new: true } to return the updated document.

DB Operation:
State Hooks: useState for each [Link]({ ID }, { $set: Validation: FileReader onload — size
sub-schema + imageArray for uploads payload }) check before base64 conversion

[Insert [Link] Screenshot — React State Declarations & PUT fetch call]

[Insert Profile UI Screenshot — Edit Mode with Image Upload fields]

6.4 Bike Management Module (Manager Side)

Purpose: Manager adds new bikes to Component: [Link] (Manager API Routes: POST /addBike | GET
inventory with image and pricing Panel) /getBike | DELETE /deleteBike/:vn

Algorithm:

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 6

 ALGORITHM: AddBikeManagement
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : { brandName, modelNumber, vehicleNumber, rate,
vehicleType, vehicleImage (File) }
OUTPUT: { success: true, bike: BikeDocument }
BEGIN
STEP 1: Manager navigates to "Add Bike" in sidebar
STEP 2: [Link] component mounts
State: setBrandName, setModelNumber, setVehicleNumber,
setRate, setVehicleType, setVehicleImage
STEP 3: Manager fills form fields
STEP 4: Manager selects bike image
IF [Link] > 2MB OR format NOT in [png, jpg, jpeg]
ALERT "Invalid file"
RETURN
END IF
reader = new FileReader()
[Link](imageFile)
[Link] = (e) => setVehicleImage([Link])
STEP 5: Manager clicks "Add Bike"
STEP 6: Frontend validates
IF vehicleNumber already in DB THEN
RETURN 409 { error: "Vehicle number exists" }
END IF
STEP 7: POST /addBike with payload
bikePayload = { brandName, modelNumber, vehicleNumber,
rate, vehicleType, vehicleImage,
available: true }
STEP 8: Backend receives request
Validate manager JWT from cookie (managerAuth middleware)
STEP 9: Create new Bike document
newBike = new Bike(bikePayload)
await [Link]()
STEP 10: RETURN 201 { success: true, bike: newBike }
STEP 11: Manager dashboard re-fetches bike list
available count updates on Dashboard card
END

Internal Logic Explanation: The Bike schema in [Link] defines a Mongoose model with fields:
brandName, modelNumber, vehicleNumber (unique), rate, vehicleType, vehicleImage (base64
String), and available (Boolean, default true). The Manager Dashboard sidebar renders [Link]
as a selected panel. The component is protected by the managerAuth middleware on all routes,
preventing unauthorised access. The available field is set to true on creation and toggled to false
when a booking request is submitted against that vehicle.

Schema File: [Link] — Mongoose Auth Guard: managerAuth Availability: available=true on add;
model "bikeDetails" middleware — validates JWT cookie toggled false on booking

[Insert AddBike Component Screenshot — Form + Image Preview]

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 7

 [Insert Bike Schema Screenshot — [Link] Mongoose Schema definition]

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 8

 6.5 Bike Viewing Module

Purpose: Fetch and display available Component: [Link] (inside

bikes dynamically on User Dashboard UserDashboard) API Route: GET /getBike

Algorithm:

ALGORITHM: BikeViewingModule
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : — (authenticated user session)
OUTPUT: Rendered bike cards with Book button
BEGIN
STEP 1: [Link] component mounts
STEP 2: useEffect hook triggers on mount
useEffect(() => { fetchBikes() }, [])
STEP 3: fetchBikes() executes
response = await fetch("/getBike")
bikeList = await [Link]()
STEP 4: Filter available bikes
availableBikes = [Link](b => [Link] === true)
STEP 5: Store in state
setBikes(availableBikes)
STEP 6: React renders bike card grid
FOR EACH bike IN bikes DO
Render <BikeCard>
Display: brandName, modelNumber, vehicleNumber
Display: rate per day
Display: vehicleImage (base64 decoded)
Show: "BOOK" button (only if [Link] == true)
END <BikeCard>
END FOR
STEP 7: User clicks "BOOK" on a bike
Open booking modal
Pre-fill: vehicleNumber, brandName, modelNumber, rate
STEP 8: Auto-refresh every 10 seconds
setInterval(() => fetchBikes(), 10000)
END
BACKEND HANDLER: GET /getBike
bikes = await [Link]().sort({ _id: -1 })
RETURN 200 { success: true, bikes }

Internal Logic Explanation: The useEffect() hook with an empty dependency array triggers the
fetch exactly once on component mount. An auto-refresh interval is set using setInterval to re-fetch
bike availability every 10 seconds, ensuring users always see the latest inventory state. The bike
image is stored as a base64 string in MongoDB and rendered directly via an <img
src={[Link]}/> tag without any additional decoding step. The Book button is
conditionally rendered based on [Link]("verified") === "true", preventing unverified
users from booking.

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 9

 React Hooks: useEffect (fetch on
mount + interval), useState (bikes DB Query: [Link]().sort({ _id: -1 }) Access Control: Book button hidden if
array) — newest first [Link] == false

[Insert View Bike Screenshot — Bike Card Grid with Availability Status]

6.6 Booking System Module

Purpose: Allow verified users to book Collection: bikeBookings + API Route: POST
an available bike bikeDetails /bookBike/vehicleNumber/:vn/id/:id

Algorithm:

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 10

 ALGORITHM: BikeBookingSystem
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : { vehicleNumber, bookingDuration, userId,
brandName, modelNumber, rate, name }
OUTPUT: { success: true, bookingId: String, price: Number }
BEGIN
// CLIENT SIDE
STEP 1: User clicks "BOOK" on bike card
STEP 2: Booking modal opens (ReactModal)
Pre-filled: vehicleNumber, brand, model, rate
STEP 3: User enters bookingDuration (number of days)
STEP 4: Auto-calculate total price
totalPrice = rate * bookingDuration
Display price preview to user (read-only field)
STEP 5: User clicks "Confirm Booking"
STEP 6: Validate
IF bookingDuration <= 0 THEN
ALERT "Duration must be at least 1 day"
RETURN
END IF
// SERVER SIDE — POST /bookBike/:vn/id/:id
STEP 7: Extract vehicleNumber (vn) and userId (id) from URL params
STEP 8: Check bike availability
bike = await [Link]({ vehicleNumber: vn })
IF [Link] == false THEN
RETURN 409 { error: "Bike not available" }
END IF
STEP 9: Generate unique bookingId
bookingId = [Link](10000 + [Link]() * 90000).toString()
STEP 10: Calculate price on server
price = [Link] * bookingDuration
STEP 11: Create booking document
booking = new Booking({
bookingId, userID: userId, name,
vehicleNumber, brandName, modelNumber,
bookingDuration, rate: [Link], price,
requestedAt: new Date().toLocaleString(),
confirm: false, return: false
})
await [Link]()
STEP 12: Mark bike as unavailable
await [Link]({ vehicleNumber: vn },
{ $set: { available: false } })
STEP 13: RETURN 201 { success: true, bookingId, price }
STEP 14: Show confirmation popup
"Booking ID: XXXXX — Request Initiated"
STEP 15: Status = PENDING until manager confirms
END

Internal Logic Explanation: The booking system maintains a strict two-phase workflow: the user
submits a request (confirm=false), and the system marks the bike unavailable immediately to prevent
double-booking. The manager must then explicitly confirm the request, which sets confirm=true and
records a bookedAt timestamp. The booking ID is a randomly generated 5-digit numeric string stored

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 11

 as a String type in MongoDB. The price field is computed server-side using the stored bike rate to
prevent client-side manipulation. The status lifecycle is: Pending → Confirmed → Engaged →
Returned.

Price Formula: price = [Link] (from Status Flags: confirm: false → true (by Bike Update: [Link] set
DB) x bookingDuration manager), return: false → true to false on booking creation

[Insert Booking API Screenshot — POST /bookBike route logic]

[Insert Booking Confirmation Popup Screenshot — "Request Initiated" modal]

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 12

 6.7 Manager Verification Module

Purpose: Manager confirms pending Component: [Link] (Manager API Routes: GET /application/0 |
booking requests from users Dashboard panel) PATCH /confirm/:bookingId

Algorithm:

ALGORITHM: ManagerVerificationModule
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : bookingId (from manager action)
OUTPUT: { success: true, confirmedBooking: Object }
BEGIN
// FETCH PENDING BOOKINGS
STEP 1: [Link] mounts in Manager Dashboard
STEP 2: useEffect fetches pending applications
response = await fetch("/application/0")
STEP 3: Backend query
pendingBookings = await [Link]({
confirm: false, return: false
}).sort({ _id: -1 })
RETURN 200 { bookings: pendingBookings }
STEP 4: Render pending bookings table
Columns: BookingID | CustomerID | Name |
VehicleNo | Brand | Duration | Price | Action
// CONFIRM BOOKING
STEP 5: Manager reviews booking details
STEP 6: Manager clicks "Confirm" button
STEP 7: Frontend calls PATCH /confirm/:bookingId
payload = { bookedAt: new Date().toLocaleString() }
STEP 8: Backend middleware validates manager JWT
IF token invalid THEN
RETURN 401 { error: "Unauthorised" }
END IF
STEP 9: Find and update booking
booking = await [Link](
{ bookingId: [Link] },
{ $set: { confirm: true,
bookedAt: [Link] } },
{ new: true }
)
STEP 10: IF booking NOT found THEN
RETURN 404 { error: "Booking not found" }
END IF
STEP 11: RETURN 200 { success: true, booking }
STEP 12: Booking moves from Confirmation panel → Engaged Vehicles
STEP 13: Dashboard stats update — pending count decreases
// USER KYC VERIFICATION (separate flow)
STEP 14: Manager navigates to View Users panel
STEP 15: Clicks "Verify" on a user — PATCH /verifyUser/:id
Updates [Link] = true
END

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 13

 Internal Logic Explanation: The Verification panel is protected exclusively behind the
[Link] middleware, which reads the JWT from the request cookie and verifies it using
[Link](). The dashboard statistics card for "Pending Confirmations" is computed by the GET
/dashboard route counting documents where confirm=false AND return=false. After confirmation,
the booking automatically appears in the Engaged Vehicles panel (confirm=true, return=false) and
disappears from the Confirmation queue. When the manager marks a bike as returned, return=true
is set, and [Link] is restored to true.

Pending Query: [Link]({ Confirm Update: findOneAndUpdate Return Flow: return:true +

confirm:false, return:false }) — confirm:true + bookedAt timestamp [Link] restored to true

[Insert Verification Logic Screenshot — PATCH /confirm route handler]

[Insert Manager Dashboard Screenshot — Confirmation Panel with Pending Bookings]

6.8 Feedback / Contact Module

Purpose: Users submit

queries/feedback; manager reviews Component: [Link] (User) + API Routes: POST /contactUs | GET
from dashboard [Link] (Manager panel) /getContact

Algorithm:

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 14

 ALGORITHM: FeedbackContactModule
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
INPUT : { name, email, phone, message }
OUTPUT: { success: true, feedbackId: ObjectId }
BEGIN
// USER SIDE — [Link]
STEP 1: User navigates to "Contact" tab in navbar
STEP 2: [Link] renders form
State: setName, setEmail, setPhone, setMessage
STEP 3: User fills in all fields
STEP 4: Validate on submit
IF name == "" OR email == "" OR message == "" THEN
ALERT "Please fill required fields"
RETURN
END IF
IF email NOT matches email regex THEN
ALERT "Invalid email format"
RETURN
END IF
STEP 5: Call POST /contactUs
payload = { name, email, phone, message }
response = await fetch("/contactUs", {
method: "POST",
body: [Link](payload)
})
STEP 6: Backend handler executes
newContact = new Contact({ name, email, phone, message })
await [Link]()
RETURN 201 { success: true, contact: newContact }
STEP 7: Display success alert to user
"Thank you! Your message has been received."
STEP 8: Clear form fields (reset state)
// MANAGER SIDE — [Link]
STEP 9: Manager navigates to "Feedback & Query" panel
STEP 10: useEffect triggers GET /getContact
feedbacks = await [Link]().sort({ _id: -1 })
STEP 11: Render feedback table
Columns: Name | Email | Phone | Message
STEP 12: Dashboard stat card "Feedback Count"
Computed by GET /dashboard — [Link]()
END

Internal Logic Explanation: The Contact collection is defined in [Link] with a simple
Mongoose schema containing name, email, phone, and message fields. No authentication is required
to submit feedback — the POST /contactUs route is publicly accessible. However, the GET
/getContact route for the manager to read submissions is protected by the managerAuth
middleware. The feedback count is included in the GET /dashboard aggregation response, which the
Manager Dashboard refreshes every 10 seconds using setInterval(). The manager-side Feedback
panel renders all submissions sorted newest-first using .sort({ _id: -1 }).

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 15

 Schema File: [Link] — Public Route: POST /contactUs — no Protected Route: GET /getContact —
Mongoose model "contacts" auth required managerAuth middleware required

[Insert Feedback API Screenshot — POST /contactUs + GET /getContact routes]

[Insert Contact Page Screenshot — Feedback Form + Manager Feedback Panel]

Section 6 Summary: The development scripts above cover all eight functional modules of the Rent
For Cents system using implementation-level pseudo-code and algorithm notation. Each module
follows the standard MERN pattern: React state management on the client, Express REST endpoints
on the server, Mongoose document operations on MongoDB, and JWT-based access control across
protected routes. Together, these modules implement a complete online bike rental workflow from
user onboarding through booking lifecycle management to manager-side operations and feedback
handling.

Algorithm
Module DB Operations Auth Required
Steps

6.1 Registration 12 steps [Link]() No (Public)

6.2 Authentication 10 steps [Link]() + save() JWT issued

6.3 Profile Update 14 steps [Link]() JWT cookie

6.4 Bike Management 11 steps [Link]() managerAuth

6.5 Bike Viewing 8 steps [Link]().sort() User session

[Link]() +
6.6 Booking System 15 steps User session
[Link]()

6.7 Verification 15 steps [Link]() managerAuth

POST: Public GET:

6.8 Feedback 12 steps [Link]() + find()
managerAuth

Development Scripts (Section 6) | LDL Report | Rent For Cents | Software Engineering Lab | 2025

Development Scripts (Section 6) | Rent For Cents | LDL Report Page 16