| 1 | # Use-case 0002 Implementation - Log in
|
|---|
| 2 |
|
|---|
| 3 | **Initiating actor:** Visitor
|
|---|
| 4 |
|
|---|
| 5 | **Other actors:** —
|
|---|
| 6 |
|
|---|
| 7 | A registered user authenticates with a username and password so that the system
|
|---|
| 8 | treats all following actions as actions of that Trader. The system looks the user up
|
|---|
| 9 | by username and compares the stored password hash with the SHA-256 hash of the
|
|---|
| 10 | entered password. An unknown username and a wrong password give the same answer,
|
|---|
| 11 | `Invalid credentials.`, so the system does not reveal which usernames exist. After a
|
|---|
| 12 | successful login the user's id and username are kept in the in-process session and
|
|---|
| 13 | the authenticated (Trader) menu is shown, from which all other Trader use-cases
|
|---|
| 14 | start.
|
|---|
| 15 |
|
|---|
| 16 | Original use-case description (P3): [UseCase0002](../P3-UseCaseModel/UseCase0002.md).
|
|---|
| 17 | Implementation: [`server/auth.go`](../../server/auth.go), functions `Login` and
|
|---|
| 18 | `authenticate` (password hash by `hashPassword`).
|
|---|
| 19 |
|
|---|
| 20 | ## Scenario
|
|---|
| 21 |
|
|---|
| 22 | 1. **Visitor** chooses `[2] Login` in the anonymous menu (types `2`).
|
|---|
| 23 | 2. **System** prints `-- Login --` and asks for `Username:` and then `Password:`.
|
|---|
| 24 |
|
|---|
| 25 | The screenshot shows steps 1–2: option `2` is chosen and the `Username:` prompt
|
|---|
| 26 | is waiting for input.
|
|---|
| 27 |
|
|---|
| 28 | 
|
|---|
| 29 |
|
|---|
| 30 | 3. **Visitor** enters the username and the password. (If either is empty, the
|
|---|
| 31 | system prints `Username and password are required.` without accessing the
|
|---|
| 32 | database.)
|
|---|
| 33 | 4. **System** looks up the user (`$1` = entered username):
|
|---|
| 34 |
|
|---|
| 35 | ```sql
|
|---|
| 36 | SELECT id, password_hash FROM users WHERE username = $1
|
|---|
| 37 | ```
|
|---|
| 38 |
|
|---|
| 39 | 5. If no row is returned (`sql.ErrNoRows` in Go), the **System** responds
|
|---|
| 40 | `Invalid credentials.` and the scenario ends.
|
|---|
| 41 | 6. If a row is returned, the **System** compares the returned `password_hash` with
|
|---|
| 42 | `hashPassword(entered password)` (hex-encoded SHA-256, computed in Go). On a
|
|---|
| 43 | mismatch it responds `Invalid credentials.` and the scenario ends.
|
|---|
| 44 |
|
|---|
| 45 | The screenshot shows this failure path with an existing user and a wrong
|
|---|
| 46 | password: `alice` / `wrongpass`. The query from step 4 finds alice's row, the
|
|---|
| 47 | hash comparison of step 6 fails, and the system prints `Invalid credentials.` and
|
|---|
| 48 | returns to the anonymous menu. (An unknown username — step 5 — prints exactly the
|
|---|
| 49 | same message.)
|
|---|
| 50 |
|
|---|
| 51 | 
|
|---|
| 52 |
|
|---|
| 53 | 7. On a match, the **System** stores the returned `id` and the username in the
|
|---|
| 54 | session (`s.UserID`, `s.Username`), prints `Login successful.` and displays the
|
|---|
| 55 | authenticated menu headed `--- Logged in as alice ---`.
|
|---|
| 56 |
|
|---|
| 57 | The screenshot shows steps 3–7 of the second, successful attempt with the seed
|
|---|
| 58 | credentials `alice` / `test123` (the first, rejected attempt is still visible at
|
|---|
| 59 | the top of the window).
|
|---|
| 60 |
|
|---|
| 61 | 
|
|---|
| 62 |
|
|---|
| 63 | The query runs on the `project` schema (the connection sets
|
|---|
| 64 | `search_path=project,public`), so `users` means `project.users`.
|
|---|
| 65 |
|
|---|
| 66 | ### Alternate flow 4a (P3) — lookup combined with the live balance
|
|---|
| 67 |
|
|---|
| 68 | P3 describes an optional variant that checks the password in SQL and returns the
|
|---|
| 69 | balances in the same query. The P4 prototype does **not** use it: login always uses
|
|---|
| 70 | the query from step 4 with the hash comparison in Go, and the balances are read
|
|---|
| 71 | separately when the Trader asks for them (`[1] View balance`, see
|
|---|
| 72 | [UseCase0003](UseCase0003Implementation.md)).
|
|---|
| 73 |
|
|---|
| 74 | ## Seed credentials
|
|---|
| 75 |
|
|---|
| 76 | State after `./eduberza -init` (`server/db/data_load.sql`):
|
|---|
| 77 |
|
|---|
| 78 | | Username | Password | Available balance | Invested balance | Holdings |
|
|---|
| 79 | |-----------|-----------|------------------:|-----------------:|----------|
|
|---|
| 80 | | `alice` | `test123` | 8250.00 USD | 1750.00 USD | 0.5 ETH |
|
|---|
| 81 | | `bob` | `test123` | 5000.00 USD | 0.00 USD | — |
|
|---|
| 82 | | `charlie` | `test123` | 2500.00 USD | 0.00 USD | — |
|
|---|
| 83 |
|
|---|
| 84 | ## How to reproduce
|
|---|
| 85 |
|
|---|
| 86 | ```sh
|
|---|
| 87 | ./eduberza -init
|
|---|
| 88 | ./eduberza
|
|---|
| 89 | # [2] Login: alice / wrongpass -> Invalid credentials.
|
|---|
| 90 | # [2] Login: alice / test123 -> Login successful. (authenticated menu)
|
|---|
| 91 | ```
|
|---|
| 92 |
|
|---|
| 93 | The screenshots come from one real run of exactly these inputs.
|
|---|