Report a Dgraph Bug
When running Dgraph 1.2.6 with both --auth_token string
and --acl_secret_file
, login in events are accepted and granted without an auth token.
What version of Dgraph are you using?
v.1.2.6
Have you tried reproducing the issue with the latest release?
Yes
What is the hardware spec (RAM, OS)?
- Docker container: 20.04 LTS (Focal Fossa)
- Host System: Pop!_OS (Ubuntu 19.10)
Steps to reproduce the issue (command/config used to run Dgraph).
- Start Dgraph Alpha with ACL and AuthToken configured (see
docker-compose.yaml
andacl_auth_config.hcl
) - Query to login endpoint with bogus AuthToken (see commands)
acl_auth_config.hcl
whitelist = "10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,172.20.0.0/12"
acl_secret_file = "/dgraph/acl/hmac_secret_file"
auth_token = "6jtXKSTL9vz5KPg"
docker-compose.yaml
services:
backgcs-alpha1:
command: dgraph alpha --my=backgcs-alpha1:7080 --lru_mb=1024 --zero=backgcs-zero1:5080
--config /dgraph/config/acl_auth_config.hcl
container_name: backgcs-alpha1
image: dgraph/dgraph:v1.2.6
ports:
- published: 8080
target: 8080
- published: 9080
target: 9080
volumes:
- read_only: true
source: ./acl
target: /dgraph/acl/
type: bind
- read_only: true
source: ./config
target: /dgraph/config
type: bind
working_dir: /data/alpha1
backgcs-zero1:
command: dgraph zero --my=backgcs-zero1:5080 --replicas 1 --idx 1
container_name: backgcs-zero1
image: dgraph/dgraph:v1.2.6
ports:
- published: 5080
target: 5080
- published: 6080
target: 6080
working_dir: /data/zero1
version: '3.5'
commands
## Invalid auth-token
/usr/bin/curl --silent \
--header 'X-Dgraph-AuthToken: bogus' \
--request POST localhost:8080/login \
--data '{"userid": "groot", "password": "password" }' | jq
## No auth-token
/usr/bin/curl --silent \
--request POST localhost:8080/login \
--data '{"userid": "groot", "password": "password" }' | jq
Expected behavior and actual result.
I expected that either a bogus auth-token or absence of an auth-token would be rejected. This is the behavior in v20.03.4
.
The documentation is ambiguous in this area as it doesn’t document using ACLs with auth-token explicitly, and only documents v1.2.2
and earlier for the 1.x versions.
The actual results are:
{
"data": {
"accessJWT": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTk0NDczNDEsImdyb3VwcyI6WyJndWFyZGlhbnMiXSwidXNlcmlkIjoiZ3Jvb3QifQ.dP1Poj5_tk5ccL0CG5KNcaHiPGeI4Epn0-i-jSvdxJw",
"refreshJWT": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MDIwMTc3NDEsInVzZXJpZCI6Imdyb290In0.jA3uiOlpoiZMTELJSqWbMfb2CgoEaOlTD4bKVEqeu-k"
}
}