checkUserPassword with @auth issues

Issues GraphQL
1

Hi, for the following schema:

type User @secret(field:"passwd") {
  email: String! @id @search(by: [hash])
}

I get correct results for both with valid JWT token and without it:

{
  checkUserPassword(email:"user1@localhost", passwd:"secret1") {
    email
  }
}
{
  "data": {
    "checkUserPassword": {
      "email": "user1@localhost"
    }
  }
}

But after adding @auth rule:

type User @secret(field:"passwd") @auth(
query: {rule: """
{$isAuthenticated: {eq: "true"} }
"""}
){
  email: String! @id @search(by: [hash])
}

I get this error when using no JWT token:

{
  "errors": [
    {
      "message": "Dgraph query failed because Dgraph execution failed because line 3 column 11: Expected Left round brackets. Got: lex.Item [6] \"{\" at 3:11"
    }
  ],
  "data": {
    "checkUserPassword": null
  }
}

And then I get this error when using valid JWT token:

{
  "errors": [
    {
      "message": "Dgraph query failed because Dgraph execution failed because line 2 column 1: Expected some name. Got: lex.Item [14] \"@\" at 2:1"
    }
  ],
  "data": {
    "checkUserPassword": null
  },
}

Both errors are the same when no matter when using valid or bad password.

At the same time the following query works correctly:

queryUser {
    email
  }

I think that because checkUserPassword is used for user validation, it should be allowed for all cases (even with @auth rule). Or maybe there should be another rule for checkUserPassword (not related to query rule).

With the above schema I was expecting that the user could be logged in (after validating with checkUserPassword), but could not query for other users.

Used dgraph/dgraph:a3d48429 and dgraph/dgraph:master for testing.

2

Hi @miko,

Thanks for reporting this. This has been reported recently in Combining @secret and @auth directives and Auth rule with other directives .
This issue is being worked upon in this sprint and there is an RFC, Auth Rule for CheckPassword Query .

Let us know if the worked upon solution (A separate auth rule field for checkPassword query) fits your use case.

3

Yes, the solution seems perfect. Thanks for letting me know.