Has anyone created a Dgraph DQL/GraphQL database adapter for next-auth?
Thinking this probably varies as schema is different, just beginning to learn next-auth, so feel free to chime in with any advice in this area.
Has anyone created a Dgraph DQL/GraphQL database adapter for next-auth?
Thinking this probably varies as schema is different, just beginning to learn next-auth, so feel free to chime in with any advice in this area.
With firebase auth? You need an auth provider to use it…
J
Well not firebase. First pass we want to just use our database as the source for password based credentials. And I believe we (@pbassham) got that working with just a simple signin callback. But we need to persist sessions to a database to be able to use those sessions by pointer reference in SSR with Next.js. There is a bunch (really just a few) of adapters made already for working with different sql flavors, mongo, dynamodb, and fauna. But there is nothing for Dgraph. We don’t want to silo this data away from our graph but connect it. Why have a graph if we have to keep siloing parts of connected data out to other sources. So building off from the prisma adapter I believe would be the way to go. It would require a minimum schema to make it work, but that is not the limitation to what that data can connect to. Eventually we want to make it so that a user can authenticate through whatever provider they want and we link it to the same user by email address. So we offload all authentication to any provider but store in graph the users sessions so we can manage and track them within one cohesive graph.
Hello Amaster ! I’ve just push a PR for a Dgraph/graphql adapter !
https://github.com/nextauthjs/adapters/pull/170
Unfortunately, next-auth discourage the use of credentials in favor of OAuth and passwordless authentication. So this adapter and more generally the next-auth package won’t be useful if you want to use a password flavored authentication flow in combination with Dgraph.
Hello,
First of all thanks for the adapter, and sorry to revive this thread, but I think is the right one to address this.
As far as I know, this approach is incompatible with edge runtime due “Dgraph only works with HS256 or RS256 algorithms” and the need of jsonwebtoken.
Did anyone face this issue? When I use auth
from the middleware I get:
⨯ Error: The edge runtime does not support Node.js 'crypto' module.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
at <unknown> (webpack-internal:///(middleware)/./node_modules/next/dist/esm/server/web/globals.js:33)
at Object.get (webpack-internal:///(middleware)/./node_modules/next/dist/esm/server/web/globals.js:33:19)
at module.exports [as sign] (webpack-internal:///(middleware)/./node_modules/jsonwebtoken/sign.js:115:58)
at client (webpack-internal:///(middleware)/./node_modules/@auth/dgraph-adapter/lib/client.js:28:73)
at DgraphAdapter (webpack-internal:///(middleware)/./node_modules/@auth/dgraph-adapter/index.js:29:69)
at eval (webpack-internal:///(middleware)/./auth.ts:39:81)
at (middleware)/./auth.ts (file:///Users/adrian/Developer/self.fm/.next/server/middleware.js:84:1)
at __webpack_require__ (file:///Users/adrian/Developer/self.fm/.next/server/edge-runtime-webpack.js:37:33)
at fn (file:///Users/adrian/Developer/self.fm/.next/server/edge-runtime-webpack.js:285:21)
at eval (webpack-internal:///(middleware)/./middleware.ts:7:63)
at (middleware)/./middleware.ts (file:///Users/adrian/Developer/self.fm/.next/server/middleware.js:95:1) {
middleware: true
}
Any ideas on how to solve it?
How is next-auth dealing with HS512 while respecting the edge runtime?
Thanks!
I can’t edit the last message so I’ll append a new one.
First, dgraph now accepts HS512, so the suggestions on the adapter, using alternative encoding methods, seems dated.
Second, I’m running into a unknown field issues, just realized it’s because next-auth is sending it’s own ID, which dgraph doesn’t accept, I wonder how can this be fixed, and when did this change in dgraph.