Open adriangalilea opened 2 months ago
Updated 3. as I found the solution following the docs and seems not related to Dgraph adapter.
Updated 2. as I managed to patch the dgraph-adapter so that it doesn't use id
on user
Update 2 on 2.
Dgraph has introduces since this adapter:
The @id directive is used for external identifiers, such as email addresses.
So the right solution may be doing this, I never quite understood why next-auth insist in using his own id's rather than allow internal db id's.
Seems to be intentional and never answered by @balazsorban44
Also updated JWT to HS512, removed the section of the docs, documented the code and respect backwards compatibility.
Adapter type
@auth/dgraph-adapter
Environment
Reproduction URL
https://github.com/adriangalilea/next-auth-example
Describe the issue
There are several issues with the Dgraph adapter:
1. JWT session and @auth directive
update
Fixed it and pushed it on the pull request.
original
This is no longer true.
So this area of the docs can be removed for simplicity, once tested.
2.
DgraphClientError: unknown field
update 2
Dgraph has
So the right solution may be doing this, I never quite understood why next-auth insist in handling id's itself.
However I'll continue overriding it and respecting Dgraph internal id's as I suspect it'd be better for performance.
update
Patched the Dgraph adapter so that it respects dgraph internal id.
repo branch
original
I spent way too many hours debugging this until I realised that it's the fact that Dgraph doesn't accept external
id
's.Currently there is an open PR
This error completely prevents the use of the Dgraph adapter.
3.
The edge runtime does not support Node.js 'crypto' module.
update:
I managed to fix the edge runtime issue by following Guides/Edge Compatibility
Fix can be seen here
original message:
I haven't identified specifically what part of the adapter is causing this, but it's def not up to date to be ran on the edge, thus can't check if user is logged in on the middleware, I know there's been some debate around edge runtime and auth, but I think it should be consistent with the rest of auth.js regardless.
How to reproduce
Expected behavior
Working adapter.