Update: My new theory is that maybe this is so you can have a built-in login system with Dgraph. And not having to create your own. Or depend on third parties login systems.
Well, I don’t know why they supported Password type in GraphQL. I have no idea. I also don’t know how it would work with Auth. However, I will explain the difference.
Password type has no authorization setting. It obscures only one predicate - the password itself. The rest is not protected by anything. This type only serves to store passwords. Nothing more. In the past it was used to create manual login systems. I mean, that’s still how it’s used. The use of this type is free, you can do whatever you want with it.
However, this implementation they made in GraphQL I didn’t understand the purpose. I need to analyze the PRs to understand what they wanted with this. That’s a lot to cover.
On the surface, there’s nothing too much or fancy with this Type. I don’t understand what connection Docs makes between secret and auth.
Quickly analyzing the links above, it seems to me that there is something that connects the two things. But I still don’t know the whole thing. There’s a lot, and tests to dig into and understand.
To search for specific things in the repo and even find tests. I make a clone of the repository, I use VsCode. I use the VSCode search engine(cmd+shift+F) and search for example for “@secret(”. So I can see where it is being used. And with the “gitblame” extension I can identify which PRs they came from.
Apparently you can’t create your own query. Dgraph does this automatically. GraphQL Schema does not need to indicate “checkMemberPassword”. My suspicion is that this will be generated automatically and you can see it in the GraphQL Schema when you generate it.
@Jan-Niclas_Gladbach what problem are you having? Just trying to use a password fields to write an auth rule? I would be careful about using it in a @auth rule, because that means the password would be in your jwt as clear text always. I would write a mutation script that checls the password using that query not in an auth rule and generate a jwt token that is authorized but does not contain the password. I wrote some articles around this
For simplicity I didn’t use the password field or specially generated functions to check the password But, you could enhance what I had to add those things somewhat easily.
Hey, thank you for all the help!
The dgraph documentation makes the impression that the auth system is very flexible, but after a lot of tinkering, the way described in your article seems to be the only working one. And the only truly secure one.
I will implement it exact this way now
The documentation conveyed the picture, that the authorization is more like the firebase way, where I can check the parameters within the user request. The documentation could be a bit more strict.
Thank you very much for your help, I will implement this for now and open a new ticket if I come across any errors. We can close this one