-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more detail to Credentials provider. #8482
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
@anthonyshew is attempting to deploy a commit to the authjs Team on Vercel. A member of the Team first needs to authorize it. |
|
||
You can also use the `jwt()` callback to interact with your database to regain some of the functionality from [more powerful providers](reference/core/providers): | ||
|
||
```js |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would love some help on this pseudo-code!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this could live in the authorize()
callback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right. Switched it up now. Does this make more sense? Anything you'd add/subtract/adjust?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can assume that updating jwt token in callbacks has been fixed?
After speaking with the Auth.js maintainers about a change to the Credentials provider documentation, I'm opening this PR to introduce additional information about:
While Auth.js does prefer to encourage use of other providers, the username-password model is (despite its flaws) still widely used today. Over time, I know I've personally seen a handful of users ask about the discouragement of the Credentials provider and express discontent with the way it is documented.
With this PR, I'm hoping to (slightly) close the gap on the community's understanding of the Credentials provider. While we can still (in my opinion, properly) discourage use of the username-password model, we can still bring in the understanding that some folks are going to want to opt to take on those risks, anyway.
Please note
The psuedo-code that I've added in for interacting with a database is most likely wrong at the time of this PRs authorship. I've never used the Credentials provider myself but am aware that the maintainers have seen successful implementations that communicate with a database. Hoping I can get some maintainer help to document that code correctly!