CS 499 Milestone Two
Enhancement One: Software Design and Engineering
Travlr Getaways is a full-stack travel application that I created in CS 465: Full Stack Development I, with the completed course artifact dating to January 2026. It uses MongoDB, Express, Angular, and Node.js. The Express application serves the public travel site and REST API, while the Angular application provides an administrative interface for managing trip information. The original project also included user registration, login, Passport authentication, and signed JSON Web Tokens (JWTs).
The application was already one of my more complete course projects because it connected a database, server-side routes, an API, and a separate client interface. Its main security limitation was that it treated authentication as if it were also authorization. A valid login proved who a user was, but every authenticated user effectively received the same access to administrative trip operations. That gap became the focus of Enhancement One.
Why I Selected This Artifact
I selected Travlr because it brings together several parts of software development that are often evaluated separately in other assignments. The project includes frontend state and navigation, backend middleware and routing, database models, authentication, and communication between the Angular client and Express API. It gave me a useful way to show that I can follow a request across those layers and make a focused change without replacing the application around it.
The artifact was also a good ePortfolio choice because the original version worked, but its design could be improved in a meaningful way. Existing applications are often maintained and strengthened rather than rewritten. Adding authorization required me to understand the earlier design, preserve the parts that were still appropriate, and change only the places involved in the permission decision. That work better represents how my approach has developed since CS 465 than simply presenting the original project unchanged.
Enhancement and Improvement
The enhancement added a constrained role field to the user model. The permitted values are user and admin, and the safe default is user. Public registration ignores a client-supplied administrator role, so someone cannot request elevated access by adding a different value to the registration payload. For development and testing, I used a small promote-admin script to update a known local account. This helper made it possible to test both roles without weakening the public registration path, but it is not a user-management feature.
After authentication, the saved role is included in the signed JWT. This gives the server trusted role information after it verifies the token signature. I then added reusable authentication and authorization middleware instead of repeating permission checks in individual controllers. The middleware separates three results that the original application did not distinguish clearly: a missing or invalid login is unauthorized, an authenticated standard user is forbidden from an administrator operation, and an administrator may continue. Centralizing those decisions makes the routes easier to read and reduces the chance that one protected operation will use different logic from another.
The server applies the administrator requirement to the existing POST and PUT trip routes. This is the actual security boundary. The Angular application also became aware of the authenticated user's role, hides Add Trip and Edit Trip controls from standard users, and uses an administrator route guard to redirect direct navigation attempts. Those client-side checks make the interface clearer, but they do not replace server enforcement because a user can send an API request without using the Angular interface.
I added focused backend tests for the authorization middleware. The cases cover an allowed administrator, an authenticated standard user who is forbidden, missing authentication, an invalid token, and an expired token. These are intentionally focused tests rather than comprehensive application-wide automation. They verify both the expected success path and the negative cases that define the security behavior. During interface verification, I also found that asynchronous updates did not always repaint immediately. A narrow markForCheck() correction resolved that display issue without changing the enhancement's scope.
Verification Evidence
The enhanced project was verified against both the allowed and the denied paths. The full screenshots are in the enhanced/evidence folder of the artifact download.
Registration supplying "admin" saved and issued role stayed "user"
POST /api/trips, regular user 403 Insufficient permissions
POST /api/trips, administrator 201 Created
PUT /api/trips/CAP499, admin 200 OK
Middleware authorization tests 5 of 5 passed
Angular tests 10 of 10 passedCourse Outcome Coverage
The planned Module One outcome coverage was met, and I did not make a major change to that plan. I originally connected this artifact to Outcomes 1, 2, 4, and 5. The final implementation stayed centered on the same authorization problem, although the route work was refined to match the POST and PUT operations that actually existed in the project. Outcomes 2, 4, and 5 remain the strongest areas of coverage.
Outcome 1 concerns collaborative environments and diverse audiences. This artifact supports that outcome in a limited but relevant way because Travlr serves different audiences: customers or standard users should not receive the same controls as administrative staff. Keeping those responsibilities clear in the interface, server rules, code review, and written explanation helps other developers and reviewers understand why each audience receives different access. I do not view this enhancement alone as complete evidence of every part of the collaboration outcome, but it follows the audience distinction identified in my original plan.
Outcome 2 is addressed through the code review, narrative, setup documentation, test evidence, and explanation of the design decisions. I had to describe the security gap and the completed work accurately for both technical reviewers and readers who may not know the original CS 465 project. Outcome 4 is supported by using established tools and practices - Mongoose validation, signed JWT claims, reusable Express middleware, Angular guards, and focused automated tests - to solve a specific design problem without adding unnecessary complexity.
Outcome 5 is the clearest technical connection. The enhancement anticipates privilege escalation through registration, uses a safe default role, verifies tokens before trusting claims, and enforces authorization on the server. Testing missing, invalid, expired, and insufficient access was important because a security control is defined partly by the requests it refuses. The completed work does not claim to be a broad role-based access-control system, but it closes the permission gap identified in Module One.
Reflection on the Enhancement Process
The most important lesson from this enhancement was that authentication and authorization solve different problems. The original login flow could verify a user's identity, but that did not answer whether the user should be allowed to modify trip data. Separating those questions changed how I evaluated the request path. I had to consider where role information originated, when it became trustworthy, and which layer had the final responsibility for denying access.
One challenge was keeping the Angular interface and Express server consistent without confusing usability with security. Hiding a button is helpful because users should not be offered actions they cannot perform, but it is not protection by itself. The route guard handles direct navigation inside Angular, while the server middleware still evaluates every protected API request. Working through both layers reinforced why the backend must remain authoritative even when the client provides role-aware feedback.
Writing the negative tests was another useful part of the process. It was straightforward to show that an administrator request could succeed, but the standard-user, missing-token, invalid-token, and expired-token cases gave better evidence that the boundary behaved correctly. The small rendering problem also reminded me that verification can uncover supporting issues outside the main logic. Fixing it with markForCheck() was appropriate because it allowed the enhanced interface to display the verified state correctly, but I kept it separate from the main authorization claim.
Overall, I learned that improving an existing system often depends on controlling scope. There were larger features I could have proposed, such as refresh tokens, user-management screens, or a more flexible permissions model, but they were not necessary to address the identified weakness. A constrained role, trusted token claim, centralized middleware, matching client behavior, and focused tests formed a complete enhancement. Keeping that boundary made the result easier to explain and verify.
Conclusion
Travlr Getaways belongs in my ePortfolio because it shows growth from building a working full-stack application to evaluating and improving one. Enhancement One corrected a specific authorization weakness while preserving the original structure and limiting changes to the approved scope. The result reflects stronger judgment about access control, layered application behavior, testing, and technical communication, while still remaining an honest continuation of the project I completed in CS 465.