Literary Lions Forum

Forum features and request flow

The application handles requests with net/http and renders templates on the server. SQLite stores the discussion and account data. The feature work connects book listings, posts and comments with category filters, sorting, likes and profile views. Forms submit to the backend rather than depending on a browser-side application.

Responsibilities were shared within the two-person team. The contribution section above identifies my backend and integration work without attributing the entire interface or application to one person.

The template package was wrong

During the later review I found a template-package choice that undermines the otherwise parameterised data path.

internal/handlers/helpers.go line 7:

import "text/template"

Go has two template packages with near-identical APIs:

They are interchangeable in use, which is exactly the problem. text/template happily parses and executes an HTML file. It just inserts every value verbatim. Swapping the import is a one-line change that removes an entire vulnerability class, and there is no compiler error, no test failure, and nothing in the output that looks wrong.

The chain, start to finish

Comment bodies go from the request straight to the database and back out into the page, with no escaping anywhere in the path.

In. The handler reads the raw form value and checks only that it is non-empty:

content := r.FormValue("content")
if content == "" {
    http.Error(w, "Comment content cannot be empty", http.StatusBadRequest)
    return
}

Stored. Directly into SQLite, parameterised. There is no SQL injection, which makes the escaping gap easier to miss, because the query looks like it was handled properly:

query := `INSERT INTO Comments (post_id, user_id, content) VALUES (?, ?, ?)`
_, err = database.GetDB().Exec(query, postID, userID, content)

Out. And rendered by the non-escaping template:

<p>{{.Content}}</p>

That is at HTML/comments.html:67, and again at :112. Post titles and usernames render the same way at HTML/index.html:60, posts.html:65 and books.html:73.

So a comment containing <script>...</script> is stored verbatim and re-emitted verbatim into the HTML of every subsequent page view. Any logged-in user who posts it has run script in every other reader's browser, as the forum's own origin. That is stored XSS, and with cookies on this app the interesting part does not stop at the script tag.

The fix is to change one import to html/template. It escapes text interpolations in HTML context by default, and handles the cases that trip people up. < becomes <, attribute and URL contexts are escaped differently, and template.JS becomes an explicit, greppable opt-in instead of the default.

Authentication and session handling

The account implementation includes password hashing and server-side session state.

Passwords are bcrypt with DefaultCost, and re-hashing happens on password change:

if err := bcrypt.CompareHashAndPassword([]byte(hashedPassword), []byte(oldPassword)); err != nil {
    ...
}
newPasswordHash, err := bcrypt.GenerateFromPassword([]byte(newPassword), bcrypt.DefaultCost)

Sessions are server-side. A session_id cookie resolves to a row in a sessions table with an expiry. Logging out and session expiry actually revoke, rather than relying only on a signed token the client holds. This gives the application a server-side revocation path.

The schema is idempotent. Migrations run at startup with CREATE TABLE IF NOT EXISTS, so the container starts against an empty volume without a separate migration step.

The inspected queries use parameters. Examples such as the comment and likes inserts pass values through placeholders. Fixed ORDER BY clauses select supported sort options. These examples do not establish that every injection-related risk was exhaustively audited, and they do not prevent the separate HTML-escaping gap.

No repository layer

Every handler opens database/sql and writes its own queries. comments.go, books.go, index.go, helpers.go all import it directly. There is no service layer and no repository, and profile reads live in the same file as password changes.

That is a fair way to write a 2,000-line forum. It is also the first thing I would change now. The e-commerce project written later has an explicit three-layer rule: Handler may not touch the database. The contrast makes the cost concrete. There, business rules are testable without a live connection. Here, every rule lives next to a QueryRow.

Shape of the work

The history spans September 2024 to June 2026, but that is not continuous feature development. Most application work landed in September 2024. The later maintenance commit migrated Go module paths and added Docker Compose. The confirmed two-person contributions above describe the implementation work rather than inferring effort from the length of the calendar span.

Three dependencies, all of them doing real work: google/uuid for identifiers, mattn/go-sqlite3 for the cgo driver, and golang.org/x/crypto for bcrypt.