Conversation
| import formbody from "@fastify/formbody" | ||
| import { toWebRequest, toFastifyReply } from "./lib/index.js" | ||
|
|
||
| declare module "fastify" { |
There was a problem hiding this comment.
I'll check with the maintainers but I think we probably should leave the session management up to the user given we are having them define their own auth prehandlers. nextauthjs#9587 (comment)
There was a problem hiding this comment.
Ah, I overlooked the part where users need to define the session decorator themselves in their prehandlers. I've reverted that in the next commit.
However, I believe many Fastify plugin libraries within its ecosystem actually define the decorators themselves. For instance, take a look at https://github.com/fastify/fastify-passport. Users can create the auth middleware using a helper from the library:
server.get(
'/',
{ preValidation: fastifyPassport.authenticate('test', { authInfo: false }) },
async () => 'hello world!'
)That said, this could result in duplicated names for decorator properties: fastify/fastify#1955 . But I suppose that's just how things work in the Fastify ecosystem. We can stick to the current design though.
There was a problem hiding this comment.
nextauthjs#9587 (comment) Yeah I agree it would be simpler for users but they want to keep it flexible which is also fair.
|
@hillac Hi! Could you please take another look? I've corrected the issues. Some mistakes are made because I copied files for the whole auth config from the express folder without double-checking after completing testing. |
The code works good in my machine!
I just finished the example in /dev fold. Pretty much a direct copy paste of your work tbh.
And I noticed
reply.sessionshould actually be typed in the plugin itself rather than the user end?