Skip to content

Revise "The AUTH command #hz3" #462

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 9, 2025
Merged

Revise "The AUTH command #hz3" #462

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ca49cda
Revise "The AUTH command #hz3"
TropicolX Nov 8, 2025
24a4cae
Fix formatting of error message in auth-06-hz3.md
TropicolX Nov 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 22 additions & 19 deletions stage_descriptions/auth-06-hz3.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,16 @@
In this stage, you'll add support for responding to the `AUTH` command.
In this stage, you'll add support for the `AUTH` command.

Check warning on line 1 in stage_descriptions/auth-06-hz3.md

View workflow job for this annotation

GitHub Actions / LLM Doc Lint

internal_consistency (stage_descriptions/auth-06-hz3.md) failed 

tools/llm-linter/reports/junit.xml
Raw output 
The document says, “For this stage, you just need to respond to the AUTH command appropriately,” implying only AUTH behavior is required. However, the Tests section requires the server to handle ACL SETUSER and return +OK, which expands the scope beyond “just” AUTH. This creates an internal contradiction about what must be implemented in this stage’s scope.

Suggested fixes:
  - description: "Clarify scope by stating that ACL SETUSER is assumed to be implemented already, and this stage focuses only on AUTH responses."
  - current: "For this stage, you just need to respond to the `AUTH` command appropriately. You don't need to actually authenticate the connection."
  - proposed: "For this stage, you only need to implement the correct responses for the `AUTH` command. You don't need to mark the connection as authenticated or enforce authentication on other commands. Assume `ACL SETUSER` support is already available from a previous stage."
  - description: "Alternatively, explicitly include minimal ACL SETUSER handling in this stage’s requirements."
  - current: "It will then send an `ACL SETUSER` command, specifying the `default` user and a password: ... Your server should respond with `OK` encoded as a simple string (`+OK\r\n`)."
  - proposed: "In addition to `AUTH`, implement minimal handling for `ACL SETUSER` so that `ACL SETUSER <user> >password` returns `+OK\r\n` and stores the password for use by `AUTH`."

### The `AUTH` command
### The `AUTH` Command

The [`AUTH`](https://redis.io/docs/latest/commands/auth/) command is used to authenticate the current connection with the specified user.
The [`AUTH`](https://redis.io/docs/latest/commands/auth/) command authenticates the current connection with a specified username and password.

Example usage:
The command format is:

```bash
AUTH <username> <password>
```

For example:

```bash
# Authentication failure
Expand All @@ -16,11 +22,11 @@
OK
```

The `AUTH` command responds with `+OK\r\n` if the specified password's hash matches with any of the hashes in the user's password list.
The server responds with `+OK\r\n` if the specified password's hash matches any of the hashes in the user's password list.

In case of wrong password, the response is a RESP simple error `WRONGPASS invalid username-password pair or user is disabled.`.
If no match is found, the server responds with the [RESP simple error](https://redis.io/docs/latest/develop/reference/protocol-spec/#simple-errors): `WRONGPASS invalid username-password pair or user is disabled.`

In this stage, you just need to respond to the `AUTH` command appropriately. You don't actually need to authenticate the connection. We'll get to that in the later stages.
For this stage, you just need to respond to the `AUTH` command appropriately. You don't need to actually authenticate the connection. We'll get to that in later stages.

### Tests

Expand All @@ -30,18 +36,16 @@
$ ./your_program.sh
```

It'll then send a `ACL SETUSER` command, specifying the `default` user and a password.
It will then send an `ACL SETUSER` command, specifying the `default` user and a password:

```bash
$ redis-cli
# Expect: +OK\r\n
> ACL SETUSER default >mypassword
$ redis-cli ACL SETUSER default >mypassword
OK
```

The tester will validate that the response to the `ACL SETUSER` command is `+OK\r\n`.
Your server should respond with `OK` encoded as a simple string (`+OK\r\n`).

It'll then send two `AUTH` commands, specifying the `default` user. First, it'll send a wrong password. Next, it'll send the correct password.
Next, the tester will send two `AUTH` commands: one with a wrong password and another with a correct password.

```bash
# Expect error starting with: WRONGPASS
Expand All @@ -53,13 +57,12 @@
OK
```

The tester will validate the following for the responses to the `AUTH` command:

- In case of incorrect password, the response is a RESP simple error starting with the string `WRONGPASS`.
- In case of correct password, the response is `+OK\r\n`.
The tester will verify that:
- Wrong passwords return a [simple error](https://redis.io/docs/latest/develop/reference/protocol-spec/#simple-errors) starting with `WRONGPASS`.
- Correct passwords return `+OK\r\n`.

### Notes

- The tester will be lenient in checking error messages. Any authentication failure starting with `WRONGPASS` is valid. For example,
- The tester will be lenient in checking error messages. Any authentication failure starting with `WRONGPASS` is valid. For example:
- `WRONGPASS wrong password`
- `WRONGPASS invalid authentication`
- `WRONGPASS invalid authentication`
Loading