Exercise 2: A Real Login-Bypass Injection — Possible Solution
====================================================================

THE EXTENDED FUNCTION
------------------------------
    def login_naive(conn, name, password):
        sql = f"SELECT id, name FROM authors WHERE name = '{name}' AND password = '{password}'"
        return conn.execute(sql).fetchall()

Same naive f-string style as the chapter's own find_author_naive(),
now checking two columns joined by AND instead of one.

NORMAL BEHAVIOR FIRST
------------------------------
    login_naive(conn, "Ann", "hunter2")     # [(1, 'Ann')]  -- correct password
    login_naive(conn, "Ann", "wrongpass")   # []             -- wrong password, correctly rejected

THE INJECTION
------------------------------
    login_naive(conn, "Ann' -- ", "anything_at_all")

The real SQL string this actually builds, character for character:

    SELECT id, name FROM authors WHERE name = 'Ann' -- ' AND password = 'anything_at_all'

The payload's own embedded quote closes the name string literal right
after 'Ann', and the two dashes that follow (--) start a real SQL
comment -- everything after that point on the line, including the
entire "AND password = '...'" clause, is treated as a comment and
never evaluated at all.

RESULT, VERIFIED DIRECTLY AGAINST A REAL SQLITE DATABASE
------------------------------------------------------------
    Result (bypassed the password check entirely): [(1, 'Ann')]

The query genuinely returns Ann's real row -- a successful login --
despite the password argument being complete nonsense
("anything_at_all"). The password check was never actually run; the
comment marker erased it from the query before the database engine
ever got to it.

WHY THIS IS A GENUINELY DIFFERENT REAL ATTACK FROM THE CHAPTER'S OWN
------------------------------------------------------------------------
The chapter's own find_author_naive() exploit (OR '1'='1') widens a
single condition into matching every row. This exercise's own comment-
based injection does something more targeted and, in a real system,
more dangerous: it doesn't just widen the query, it surgically removes
an entire security check from it, letting an attacker who knows (or
guesses) a real username log in as that user with literally any
password at all.

WHY THIS WORKS AS AN ANSWER
----------------------------
It extends the chapter's own real function into a genuinely different,
two-column real-world scenario (login, not a plain lookup), constructs
a real, working payload using a different injection technique (a
comment marker, not a boolean tautology), and verifies the exact
security consequence -- a full authentication bypass -- against a real
SQLite database rather than only asserting the payload "should" work.