Copying/moving a predicate with password type

[johnholiver]

Hi, I have a question that seems to be landing me in the realm of "it's currently impossible".

TLDR, I need to copy or move a predicate from user.password to identity.password (in a new node).

The longer explanation is that my project uses DGraph as a store for everything for my application, including storing user credentials (auth). The application is restrictive in the sense that one user (email) is unique and can only access one account. It served it well for many years, but it came time for the next step.
I'm implementing a large initiative that would allow users to visit many accounts. To do so, auth predicates that were centered in a user model would now be moved to an identity model, which the user model would reference. Stuff like email, password, besides other predicates such as social login related, lang, name.

What's the issue?

Well, as it is quite well understood, user.password being of password schema type, can't be queried, only verified by checkpwd. I did some research online, and the docs don't seem to mention how I could migrate a password-type predicate to another place. I don't mean to reduce any security of the pwd, I don't need to even see the hashed values, just need the uid and predicate name of the triplet replaced. Ofc, "just that" is looking like a big ask atm.

For context: I'm on v24.1.4 in both dev and prod, and I've already empirically ruled out the obvious paths so we don't loop on those. val() of a password predicate returns nothing — running an upsert with me() { aggPwd as max(val(pwd)) } makes the engine itself respond with "queries":{"me":[{"max(val(pwd))":null}]}, which is about as definitive as it gets. A schema-swap workaround is also blocked: ALTER from password → string errors with Schema change not allowed from PASSWORD to STRING (and the reverse direction is blocked too), and DropAttr deletes the data outright, so I can't expose the hash by retyping the predicate. I also tried the "traversal" upsert pattern (uid(user) → user.identity → uid(identity), set val(psw) on identity) — the upsert returns Success, but post-verification indicates that nothing happened. Hence the question — is there any binary-protocol or admin path that lets me write a Value_PasswordVal directly, or some equivalent, without it being re-hashed?

Does anyone see any way I could achieve a copy of the predicate from A -> B when both are of type password? The alternatives I'm looking at are way more work than I was expecting to have:

• Forking dgraph to include a way to do it, running my migration, and returning to the original
• Export/Import with some attempt to manipulate in between
• Copy passwords gradually via business logic, as users login and using the original user.password to check and if successful, mutating identity.password.

None of the above is great. AI for research can't seem to help. My hope is that someone here can tell me that it can be done via some shady, undocumented API. :) But if it isn't shady, I'll take it too!

[matthewmcneely]

I think it can be done, but you'll have to export RDF. The triple looks like this:

<user_uid> <user.password> "<hash>"^^<xs:password> .

The magic is that xs.password type. Live load into your new graph.

You can see a test of this in systest/live_pw_test.go#L99-L121.