Personal Catalogue: React, Express & MongoDB — Chapter 9, Exercise 3
=====================================================================

TASK
Create the least-privileged catalogue_app MongoDB user, update
MONGODB_URI to use it, confirm the app still works normally, then
confirm directly (e.g. attempting db.dropDatabase() while authenticated
as catalogue_app) that the restricted user genuinely cannot perform an
admin-only operation.

SOLUTION

Connected as an existing admin user:

  use catalogue
  db.createUser({
    user: "catalogue_app",
    pwd: "a-real-generated-password",
    roles: [{ role: "readWrite", db: "catalogue" }],
  })

Update the .env used by server.js:

  MONGODB_URI=mongodb://catalogue_app:a-real-generated-password@localhost:27017/catalogue

Restart the server and confirm normal operation:

  npx nodemon server.js
  curl http://localhost:4000/api/items
  curl -X POST http://localhost:4000/api/items \
    -H "Content-Type: application/json" \
    -d '{"itemType":"Cd","title":"Test Album","artist":"Test Artist"}'

Output: both requests succeed normally -- readWrite is exactly the
permission level create/read/update/delete on documents actually
needs, so nothing about the app's own behavior changes.

Now confirm the restriction genuinely holds. Connect to mongosh
authenticating specifically as catalogue_app against the catalogue
database, then attempt an admin-only operation:

  mongosh "mongodb://catalogue_app:a-real-generated-password@localhost:27017/catalogue"
  > db.dropDatabase()

Output: a real, explicit authorization error, e.g.:

  MongoServerError: not authorized on catalogue to execute command
  { dropDatabase: 1, ... }

The operation is genuinely refused -- not because dropDatabase() failed
for some unrelated reason, but because the readWrite role this user was
granted does not include permission to drop a database at all. The
same real test against an admin-level connection would have succeeded
immediately.

WHY THIS WORKS AS AN ANSWER
----------------------------
It creates the real least-privilege user exactly as the chapter
specifies, confirms the application's own everyday operations still
work under the new, restricted credentials, and then actually attempts
the operation the restriction is supposed to prevent -- getting a real,
explicit authorization error back -- rather than just assuming the
role definition is correct without ever testing it against a real
admin-only command.