googleforgames / googleforgames/open-match
Redis Username is ignored
- Dominant language
- Go
- Stars
- 3.4k
- Forks
- 358
- PR merge metrics
- No merged PRs in 30d
Description
**What happened**:
Even though the username for the redis connection can be configured and is considered within [the code](https://github.com/googleforgames/open-match/blob/v1.8.1/internal/statestore/redis.go#L235), it is not actually used. It always assumes the user `default`. I enabled `usePassword` and supplied a working username-password pair, but it only started working when I supplied the default user password (with the non-default username). This leads me to believe, that the username is completely ignored and only the password is actually important.
**What you expected to happen**:
The username should be considered. Otherwise only the default user can be used, making any kind of ACL configuration redundant.
**How to reproduce it (as minimally and precisely as possible)**:
1. Use a Redis Database with ACL enabled and a user `default` and `apple`, both with their own distinct passwords.
2. Adjust the matchmaker configuration and create the corresponding secret (with the password of user `apple`)
3. Create a ticket and get `io.grpc.StatusException: UNAVAILABLE: CreateTicket, id: coj74uis0ooc738qg5lg, failed to connect to redis: WRONGPASS invalid username-password pair or user is disabled.`
Config:
```
redis:
hostname: redis-master.redis
port: 6379
user: apple
usePassword: true
passwordPath: /app/config/redis/password
```
**Anything else we need to know?**:
This is most probably a bug within any of the dependencies (redigo), as the construction of the redis string looks fine: https://github.com/googleforgames/open-match/blob/v1.8.1/internal/statestore/redis.go#L235
**Output of `kubectl version`**:
Server Version: v1.27.11
**Cloud Provider/Platform (AKS, GKE, Minikube etc.)**:
Hetzner Cloud
**Open Match Release Version**:
1.8.1
**Install Method(yaml/helm)**:
YAML with Kustomize
Contributor guide
Research direction
Start in internal/statestore/redis.go around the Redis connection construction at line 235 and inspect how the configured username reaches the redigo dependency. Reproduce the issue with Redis ACL users default and apple using the supplied configuration and distinct passwords. Done means a non-default username and its password authenticate successfully, with the behavior verified against the reported WRONGPASS case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, redis
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100