LukeParke/better-auth
1
0
Fork 0
mirror of https://github.com/LukeHagar/better-auth.git synced 2025-12-06 12:27:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: new contribution category (#1174)

Browse Source
This commit is contained in:
Maxwell
2025-01-21 18:05:17 +10:00
committed by GitHub
parent dfcce1ee2a
commit 47f14a22cb
12 changed files with 909 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
CONTRIBUTING.md
View File

@@ -1,36 +1,16 @@
# Contributing to Better Auth
Thanks for taking the time to improve Better Auth! This is a small document to get you started. Before submitting a new issue or PR, check if it already exists in issues or PRs.
Thanks for taking the time to improve Better Auth! This is a small document to get you started.
### Areas you can contribute
Please refer to the [getting-started documentation](https://better-auth.com/docs/contribute/getting-started) specific to contributing for more information.
**Issues**
Probably the best way to get going is to see if there is open issues acknowledged by the team. Feel free to open an issue if you found a bug or a missing feature you'd like to work on, and there aren't any issues mentioning it.
**Framework Integrations**
We aim to support as many frameworks as possible in the JavaScript ecosystem. If you'd like to integrate one we don't already cover, start by adding documentation. Since the core is designed to be flexible, a simple doc should work for most frameworks. If we believe the integration should go further to reduce friction, we might ask you to contribute or handle it ourselves.
In general, we avoid framework-specific solutions unless it's a thin layer, especially on the server side. If there's a way to make it work without tying it to a specific framework, and it still works well, we'd prefer that.
Right now, everything you need—framework integrations, plugins, and all the necessary glue code—is bundled into a single package. Since our current integrations are minimal, we don’t plan on splitting them into separate packages for the time being.
**Plugins**
If you plan to contribute a new core plugin open an issue first. If we see fit with the plans we have in mind we'll give you a green light. If not you can still publish your plugins yourself.
Make sure to read the plugin documentation before you start developing one.
**New Core Features**
Before you start working on a new core feature it's better to open an issue first. Once you have a green light you can get started. If you start working on something larger, it's a good idea to create a draft (WIP) PR at an early stage so that we can guide you in the right direction.
**Security Issues**
## Security Issues
If you see any security issue we prefer you to disclose it via an email (security@better-auth.com). All reports will be promptly addressed, and you'll be credited accordingly.
### A Few Guidelines to keep in mind
Learn more about our [security issues documentation](https://better-auth.com/docs/contribute/security-issues).
## A Few Guidelines to keep in mind
- Rather than extensive configurations, focus instead on providing opinionated, best-practice defaults.
- Try to make a consistent and predictable API across all supported frameworks
@@ -38,6 +18,8 @@ If you see any security issue we prefer you to disclose it via an email (securit
## Development
Read more about development in the [getting-started documentation](https://better-auth.com/docs/contribute/getting-started#development-setup).
1. Fork the repo
2. clone your fork.
3. install node.js (preferable latest LTS).
@@ -51,9 +33,4 @@ If you see any security issue we prefer you to disclose it via an email (securit
## Testing
At the moment, we're only focusing on unit tests. Before we reach v1, we'll expand to include extensive integration testing. For now, please follow these guidelines:
- Add your tests in the same place as your functionality—no need to create separate folders.
- Avoid mocking unless absolutely necessary.
- Only use vitest for testing.
- If you need an auth instance, use getTestInstance instead of creating one manually, unless there's a specific reason to do so.
Read more about testing in the [testing guide](https://better-auth.com/docs/contribute/testing).

42
docs/components/sidebar-content.tsx
View File

@@ -1,12 +1,18 @@
import {
BookOpenCheck,
CircleHelp,
FlaskConical,
GitFork,
HandHelping,
Gauge,
Key,
LucideAArrowDown,
LucideIcon,
Mail,
Mailbox,
NotebookPen,
Phone,
Plug,
ScanFace,
ShieldCheck,
UserCircle,
@@ -1223,6 +1229,42 @@ export const contents: Content[] = [
},
],
},
{
title: "Contribute",
Icon: () => <GitFork className="text-current size-4" />,
list: [
{
title: "Getting Started",
href: "/docs/contribute/getting-started",
icon: () => <BookOpenCheck className="text-current size-4" />,
},
{
title: "Areas to Contribute",
href: "/docs/contribute/areas-to-contribute",
icon: () => <HandHelping className="w-4 h-4 text-current" />,
},
// {
// title: "Database Adapters",
// href: "/docs/contribute/database-adapters",
// icon: () => <Plug className="w-4 h-4 text-current" />,
// },
{
title: "Testing",
href: "/docs/contribute/testing",
icon: () => <FlaskConical className="w-4 h-4 text-current" />,
},
{
title: "Documenting",
href: "/docs/contribute/documenting",
icon: () => <NotebookPen className="w-4 h-4 text-current" />,
},
{
title: "Security Issues",
href: "/docs/contribute/security-issues",
icon: () => <ShieldCheck className="w-4 h-4 text-current" />,
},
],
},
];
export const examples: Content[] = [

2
docs/content/docs/concepts/plugins.mdx
View File

@@ -24,7 +24,7 @@ export const auth = betterAuth({
```
Client plugins are added when creating the client. Most plugin require both server and client plugins to work correctly.
The Better-Auth auth client on the frontend uses the `createAuthClient` function provided by `better-auth/client`.
The Better Auth auth client on the frontend uses the `createAuthClient` function provided by `better-auth/client`.
```ts title="auth-client.ts"
import { createAuthClient } from "better-auth/client";

89
docs/content/docs/contribute/areas-to-contribute.mdx Normal file
View File

@@ -0,0 +1,89 @@
---
title: Areas To Contribute
description: Areas to contribute to BetterAuth
---
## Working on Issues
The easiest way to start contributing is by tackling existing issues. Here's how:
1. Check our [github issues](https://github.com/better-auth/better-auth/issues) for issues labeled `good first issue`, `help wanted` or `question`
2. Comment on the issue you'd like to work on to avoid duplicate efforts
3. If you've found a bug or have a feature request not listed, please create a new issue:
- For bugs: Include steps to reproduce, expected vs actual behavior
- For features: Describe the feature and its use cases
## Framework Integrations
Better Auth aims to support as many frameworks as possible in the JavaScript ecosystem. Here's how you can help expand our framework support:
### Adding New Framework Support
1. Start with documentation for basic integration
2. Focus on framework-agnostic solutions where possible
3. Keep integrations minimal and maintainable
### Integration Guidelines
- Prefer framework-agnostic solutions over framework-specific ones
- Keep server-side integrations as thin as possible
- All integrations currently live in the main package (packages/better-auth)
- Focus on reducing implementation friction while maintaining flexibility
### Current Structure
We currently maintain all integrations (frameworks, plugins, utilities) in a single package for simplicity. As the project grows, we may consider splitting these into separate packages.
## Plugin Development
Want to extend Better Auth's functionality? Here's our plugin contribution process:
### Core Plugins
1. **Open an Issue First**: Describe your plugin idea
2. **Get Approval**: Wait for team feedback before starting
3. **Development**: Follow our <Link href="/docs/guides/your-first-plugin">plugin development guide</Link>
### Community Plugins
- Feel free to develop and publish plugins independently
- Use our <Link href="/docs/concepts/plugins">Plugin docs</Link> as a reference
- Consider sharing your plugin in our <Link href="https://discord.com/channels/1288403910284935179/1296056387968700416">community showcase channel</Link>.
## Core Feature Development
Contributing to core features requires careful coordination:
### Process
1. **Open an Issue**: Describe the feature and its use cases
2. **Discussion**: Get feedback from the team and community
3. **Planning**: Outline implementation approach
4. **Development**: Create a draft PR early for guidance
### Best Practices
- Start with a minimal viable implementation
- Include tests and documentation
- Keep backwards compatibility in mind
- Follow our coding standards
## Security Contributions
Security is our top priority. If you discover a security vulnerability:
1. **DO NOT** create a public issue
2. Send details to security@better-auth.com
3. Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
Learn more about our [security issues documentation](https://better-auth.com/docs/contribute/security-issues).
## Other Ways to Contribute
- Improve error messages
- Add test cases
- Enhance documentation
- Share examples
- Report performance issues
- Suggest optimizations
Remember, all contributions, no matter how small, are valuable to the project. If you're unsure about anything, don't hesitate to ask in our <Link href="https://discord.gg/GYC3W7tZzb">Discord server</Link>.
Let's make authentication better, together! 🚀

6
docs/content/docs/contribute/database-adapters.mdx Normal file
View File

@@ -0,0 +1,6 @@
---
title: Database Adapters
description: Adding a new database adapter to BetterAuth
---
WORKIN IN PROGRESS.

326
docs/content/docs/contribute/documenting.mdx Normal file
View File

@@ -0,0 +1,326 @@
---
title: Documenting
description: Documentation Guide for Better Auth
---
## Overview
Better Auth uses [Fumadocs](https://fumadocs.vercel.app/) with MDX for documentation. This page explains how to add and update documentation effectively.
## Project Structure
<Files>
<Folder name="docs" defaultOpen>
<Folder name="components" defaultOpen>
<File name="sidebar-content.tsx" />
</Folder>
<Folder name="content" defaultOpen>
<Folder name="docs" defaultOpen>
<File name="some_documentation.mdx" />
</Folder>
</Folder>
</Folder>
</Files>
## Writing Documentation
### Creating New Pages
1. Add your MDX file in `docs/content/docs/<your_file_name>.mdx`:
<Callout>
#### File Name Convention * The file name should be in the format of
`some-feature.mdx`. (Kebab-case) * The file name represents the URL route to
that page. For example, if the file name is `some-feature.mdx`, the URL route
will be `/docs/some-feature`. * Place the file in their respective category
folder. For example, if the file is in the `guides` category, place it in the
`/guides` folder.
</Callout>
```mdx
---
title: Your Feature
description: Description of your feature
---
# Your Feature
Introduction to your feature here...
```
2. Update the sidebar in `docs/components/sidebar-content.tsx`:
<Callout>
To find out what icon you would like to use for the sidebar, you can check out
the <Link href="https://lucide.dev/icons/">Lucide Icons</Link> library.
</Callout>
```tsx
export const contents: Content[] = {
items: [
{
// Existing items...
},
{
title: "Your Section",
icon: <SomeLucideIcon className="size-4" />,
items: [
{
title: "Your Feature",
icon: <OtherLucideIcon className="size-4" />,
href: "/docs/your-feature",
},
],
},
],
};
```
---
## MDX Guidelines
### Basic Formatting
```mdx
# Main Title
## Section
This is a paragraph with **bold** and _italic_ text.
### Subsection
- List item 1
- List item 2
1. Order list item 1
2. Order list item 2
```
### Components
<Accordions>
<Accordion title="Callouts">
```mdx
<Callout>Important information goes here</Callout>
<Callout type="warn">Some warning</Callout>
<Callout type="info">Some info</Callout>
<Callout type="error">Some error</Callout>
```
<Callout>Important information goes here</Callout>
<Callout type="warn">Some warning</Callout>
<Callout type="info">Some info</Callout>
<Callout type="error">Some error</Callout>
</Accordion>
<Accordion title="Files">
```mdx
<Files>
<Folder name="docs" defaultOpen>
<File name="some_documentation.mdx" />
</Folder>
</Files>
```
<Files>
<Folder name="docs" defaultOpen>
<File name="some_documentation.mdx" />
</Folder>
</Files>
</Accordion>
<Accordion title="Links">
```mdx
<Link href="/docs/introduction">Link to Introduction</Link>
```
<Link href="/docs/introduction">Link to Introduction</Link>
</Accordion>
<Accordion title="Accordions">
```mdx
<Accordions>
<Accordion title="Accordion 1">
Some content!
</Accordion>
<Accordion title="Accordion 2">
Some content!
</Accordion>
</Accordions>
```
<Accordions>
<Accordion title="Accordion 1">
Some content!
</Accordion>
<Accordion title="Accordion 2">
Some content!
</Accordion>
</Accordions>
</Accordion>
<Accordion title="Steps">
```mdx
<Steps>
<Step>
## Step 1
Hello world!
</Step>
<Step>
## Step 2
Hello world!
</Step>
</Steps>
```
<Steps>
<Step>
<span className="text-xl font-bold">Step 1</span>
<span className="block mb-3 mt-2">Hello world!</span>
</Step>
<Step>
<span className="text-xl font-bold">Step 2</span>
<span className="block mb-3 mt-2">Hello world!</span>
</Step>
</Steps>
</Accordion>
<Accordion title="Tabs">
```mdx
<Tabs items={['Javascript', 'Rust']}>
<Tab value="Javascript">Javascript is weird</Tab>
<Tab value="Rust">Rust is fast</Tab>
</Tabs>
```
<Tabs items={['Javascript', 'Rust']}>
<Tab value="Javascript">Javascript is weird</Tab>
<Tab value="Rust">Rust is fast</Tab>
</Tabs>
</Accordion>
</Accordions>
### Code Blocks
Use language-specific syntax highlighting:
````mdx
```typescript
import { BetterAuth } from "better-auth";
const auth = new BetterAuth({
// configuration
});
```
````
Optionally, you can also specify a file name for the code block:
````mdx
```typescript title="auth.ts"
import { BetterAuth } from "better-auth";
const auth = new BetterAuth({
// configuration
});
```
````
You can also highlight specific lines in a codeblock:
````mdx
```typescript title="auth.ts"
import { BetterAuth } from "better-auth";
const auth = new BetterAuth({ // [!codeㅤhighlight]
// configuration // [!codeㅤhighlight]
}); // [!codeㅤhighlight]
```
````
The result:
```typescript title="auth.ts"
import { BetterAuth } from "better-auth";
const auth = new BetterAuth({// [!code highlight]
// configuration // [!code highlight]
}); // [!code highlight]
```
---
## Best Practices
### Do's
- Keep documentation up-to-date with code changes
- Use clear, concise language
- Include practical examples
- Document error cases and edge conditions
- Use proper headings hierarchy
- Include cross-references to related docs
### Don'ts
- Don't repeat information unnecessarily
- Don't leave outdated examples
- Don't use complex jargon without explanation
- Don't skip documenting breaking changes
- Don't leave TODO comments in published docs
## Local Development
```bash
# Install dependencies
pnpm install
# Start docs development server
pnpm -F docs dev
```
## Document Types
### 1. Guides
- Step-by-step instructions
- Tutorial-style content
### 2. Reference Documentation
- API documentation
- Configuration options
- Type definitions
### 3. Examples
- Code snippets
- Complete examples
- Use cases
## Contributing to Documentation
1. **Find the Right File**
- Navigate to `docs/content/docs/`
- Locate the relevant MDX file or create a new one
2. **Make Your Changes**
- Update or add content
- Follow the MDX formatting guidelines
- Include examples where appropriate
3. **Test Locally**
- Run the development server
- Check your changes
- Verify links and navigation
4. **Submit Changes**
- Create a pull request
- Include a clear description of documentation changes
- Request review from documentation maintainers
## Getting Help
Need assistance with documentation?
- Join our <Link href="https://discord.gg/GYC3W7tZzb">Discord server</Link> and ask for help!
- Open an issue with the `documentation` label
Remember: Good documentation is crucial for Better Auth's success. Thank you for helping improve it! 📚

131
docs/content/docs/contribute/getting-started.mdx Normal file
View File

@@ -0,0 +1,131 @@
---
title: Contributing to BetterAuth
description: Getting started to contribute to BetterAuth
---
Hello and welcome! We're thrilled that you're interested in contributing to Better Auth. Whether you're fixing bugs, adding new features, improving documentation, or just sharing ideas, your contribution helps make Better Auth better for everyone.
## Getting Started
Before diving in, here are a few important resources:
- Take a look at our existing <Link href="https://github.com/better-auth/better-auth/issues">issues</Link> and <Link href="https://github.com/better-auth/better-auth/pulls">pull requests</Link>
- Join our community discussions in <Link href="https://discord.gg/GYC3W7tZzb">Discord</Link>
## Development Setup
To get started with development:
<Callout type="warn">
Make sure you have <Link href="https://nodejs.org/en/download">Node.JS</Link>{" "}
installed, preferably on LTS.
</Callout>
<Steps>
<Step>
### 1. Fork the repository
Visit https://github.com/better-auth/better-auth
Click the "Fork" button in the top right.
</Step>
<Step>
### 2. Clone your fork
```bash
# Replace YOUR-USERNAME with your GitHub username
git clone https://github.com/YOUR-USERNAME/better-auth.git
cd better-auth
```
</Step>
<Step>
### 3. Install dependencies
Make sure you have <Link href="https://pnpm.io/installation">pnpm</Link> installed!
```bash
pnpm install
```
</Step>
<Step>
### 4. Prepare ENV files
Copy the example env file to create your new `.env` file.
```bash
cp -n ./docs/.env.example ./docs/.env
```
</Step>
</Steps>
## Making changes
Once you have an idea of what you want to contribute, you can start making changes. Here are some steps to get started:
<Steps>
<Step>
### 1. Create a new branch
```bash
# Make sure you're on main
git checkout main
# Pull latest changes
git pull upstream main
# Create and switch to a new branch
git checkout -b feature/your-feature-name
```
</Step>
<Step>
### 2. Start development server
Start the development server:
```bash
pnpm dev
```
To start the docs server:
```bash
pnpm -F docs dev
```
</Step>
<Step>
### 3. Make Your Changes
* Make your changes to the codebase.
* Write tests if needed. (Read more about testing <Link href="/docs/contribute/testing">here</Link>)
* Update documentation. (Read more about documenting <Link href="/docs/contribute/documenting">here</Link>)
</Step>
</Steps>
## Best Practices
- Write clear commit messages
- Update documentation to reflect your changes
- Add tests for new features
- Follow our coding standards
- Keep pull requests focused on a single change
## Need Help?
Don't hesitate to ask for help! You can:
- Open an <Link href="https://github.com/better-auth/better-auth/issues">issue</Link> with questions
- Join our <Link href="https://discord.gg/GYC3W7tZzb">community discussions</Link>
- Reach out to project maintainers
Together, we can make Better Auth an even better authentication solution. Thank you for being part of our community!
Your contributions are greatly appreciated, and we look forward to collaborating with you!

113
docs/content/docs/contribute/security-issues.mdx Normal file
View File

@@ -0,0 +1,113 @@
---
title: Security Policy and Disclosure Guidelines
description: Security Policy and Disclosure Guidelines in BetterAuth
---
## Our Security Commitment
At Better Auth, security is our highest priority. We take all security concerns seriously and appreciate the efforts of security researchers and our community in responsibly disclosing potential vulnerabilities.
## Reporting a Vulnerability
### Preferred Method
Please report security issues by emailing:
```
security@better-auth.com
```
### What to Include
When reporting a security issue, please include:
1. **Description**
- Clear explanation of the vulnerability
- Affected versions/components
- Type of vulnerability (e.g., XSS, CSRF, Authentication Bypass)
2. **Reproduction Steps**
- Detailed steps to reproduce the vulnerability
- Any required setup or configuration
- Code samples if applicable
- Example payload if relevant
3. **Impact Assessment**
- Potential security impact
- What an attacker might be able to accomplish
- Affected user groups or data
4. **Supporting Materials**
- Screenshots or videos (if applicable)
- Proof of concept code (if available)
- Related references or CVEs
5. **Mitigation Suggestions**
- Proposed fixes or workarounds
- Recommended security controls
## Our Response Process
1. **Initial Response**
- Acknowledgment within 24 to 48 hours
- Case number assignment
- Initial severity assessment
2. **Investigation**
- Technical review of the report
- Impact analysis
- Verification of reproduction steps
- Development of fix strategy
3. **Resolution Timeline**
- Critical vulnerabilities: 24-48 hours
- High severity: 1 week
- Medium severity: 2 weeks
- Low severity: Next release cycle
4. **Communication**
- Regular updates on fix progress
- Notification when fix is ready
- Coordination on disclosure timeline
## Disclosure Policy
1. **Responsible Disclosure**
- No public disclosure before fix implementation
- Coordinated release of security advisories
- Credit given to reporters in security advisories
2. **Fix Release Process**
- Security patches released as priority updates
- Clear documentation of fixes
- Migration guides if needed
3. **Post-Fix Communication**
- Public security advisories
- Notification to affected users
- Updated security documentation
## Bug Bounty Program
Currently, we do not operate a formal bug bounty program. However, we do recognize and credit security researchers who:
- Follow responsible disclosure guidelines
- Provide clear and actionable reports
## Out of Scope
The following are typically out of scope:
- DOS/DDOS attacks
- Spam attacks
- Social engineering
- Physical security issues
- Issues requiring physical access
- Issues in dependencies (report to them directly)
- TLS configuration issues without practical impact
## Contact Information
- Security Issues: security@better-auth.com
Remember: Security is a collaborative effort. Thank you for helping keep Better Auth and its users secure!

189
docs/content/docs/contribute/testing.mdx Normal file
View File

@@ -0,0 +1,189 @@
---
title: Testing in Better Auth
description: Testing Guide for Better Auth
---
## Overview
We use Vitest as our testing framework of choice. Currently, we focus on unit tests, with plans to expand to integration testing in the future.
This guide will help you understand our testing philosophy and how to write effective tests.
<Callout type="warn">
We expect you to have knowledge of Vitest before you start writing tests. If
you're new to Vitest, we recommend you read the [Vitest
documentation](https://vitest.dev/guide/) first.
</Callout>
## Testing Philosophy
Our approach to testing emphasizes:
- Simplicity over complexity
- Real implementations over mocks
- Co-location of tests with source code
- Minimal test setup
- Clear and readable test cases
## Getting Started
### Setup
```bash
# Install dependencies including Vitest
pnpm install
# Run tests
pnpm run test
```
## Test Structure
### File Organization
We follow a co-location strategy for tests. Place your test files next to the source files they test:
<Files>
<Folder name="auth" defaultOpen>
<File name="auth.ts" />
<File name="auth.test.ts" />
</Folder>
<Folder name="plugins" defaultOpen>
<File name="oauth.ts" />
<File name="oauth.test.ts" />
</Folder>
</Files>
### Test File Naming
- Use `.test.ts` extension for test files
- Name test files after the module they test
- For TypeScript, use `.test.ts` or `.test.tsx` for React components
## Writing Tests
### Basic Test Structure
<Callout type="info">
This is just example code, and isn't meant to be used as-is. It's meant to
demonstrate the structure of a test file.
</Callout>
```ts title="auth.test.ts"
//...
import { describe, it, expect } from "vitest";
import { getTestInstance } from "./test-utils/test-instance";
describe("Authentication Module", () => {
it("should successfully authenticate a user", async () => {
const { client } = getTestInstance();
const result = await client.signIn.email({
email: "hello@gmail.com",
password: "123456",
});
expect(result.success).toBe(true);
expect(result.user).toBeDefined();
});
});
```
### Using `getTestInstance`
The test instance provides multiple handy properties that you can use to test your feature.
```ts
import { getTestInstance } from "../test-utils";
const {
client,
auth,
cookieSetter,
customFetchImpl,
db,
sessionSetter,
signInWithTestUser,
signInWithUser,
testUser,
} = getTestInstance();
```
Only create custom instances when needed
```typescript
import { getTestInstance } from "../test-utils";
const { auth } = getTestInstance({
customConfig: {
// your custom configuration
},
});
```
## Best Practices
### Do's
- Write descriptive test names that explain the expected behavior
- Test both success and failure cases
- Keep tests focused and atomic
- Use setup and teardown when needed
- Test edge cases and boundary conditions
<Callout type="info">
This is just example code, and isn't meant to be used as-is. It's meant to
demonstrate the best Practices of testing.
</Callout>
```typescript
describe("User Authentication", () => {
it("should reject invalid credentials", async () => {
const { client } = getTestInstance();
const result = await client.signIn.email({
email: "invalid@example.com",
password: "wrong",
});
expect(result.success).toBe(false);
expect(result.error).toBeDefined();
});
it("should handle empty inputs appropriately", async () => {
const { client } = getTestInstance();
const result = await client.signIn.email({
email: "",
password: "",
});
expect(result.success).toBe(false);
expect(result.error).toMatch(/required/);
});
});
```
### Don'ts
- Don't create unnecessary mocks
- Don't test implementation details
- Don't create separate test folders
- Don't write brittle tests
- Don't test external libraries
## Future Plans
- Implement integration testing
- Add end-to-end testing
- Expand API testing coverage
- Add performance testing
- Implement snapshot testing where appropriate
## Contributing
When submitting a PR:
- Ensure all tests pass
- Add tests for new features
- Update tests for modified features
- Follow existing test patterns
- Include meaningful assertions
Need help? Feel free to reach out in our <Link href="https://discord.gg/GYC3W7tZzb">Discord server</Link>!

2
docs/content/docs/guides/your-first-plugin.mdx
View File

@@ -56,7 +56,7 @@ Although this does nothing, you have technically just made yourself your first p
### Defining a schema
In order to save each user’s birthday data, we must create a schema on top of the `user` model.
By creating a schema here, this also allows <Link href="/docs/concepts/cli">Better-Auth’s CLI</Link> to generate the schemas required to update your database.
By creating a schema here, this also allows <Link href="/docs/concepts/cli">Better Auth’s CLI</Link> to generate the schemas required to update your database.
<Callout type="info">
You can learn more about <Link href="/docs/concepts/plugins#schema">plugin schemas here</Link>.

2
docs/content/docs/plugins/2fa.mdx
View File

@@ -330,7 +330,7 @@ When `trustDevice` is set to `true`, the current device will be remembered for 6
By adding an `issuer` you can set your application name for the 2fa application.
For example, if your user uses Google Auth, the default appName will show up as `Better-Auth`. However, by using the following code, it will show up as `my-app-name`.
For example, if your user uses Google Auth, the default appName will show up as `Better Auth`. However, by using the following code, it will show up as `my-app-name`.
```ts
twoFactor({

2
docs/content/docs/reference/faq.mdx
View File

@@ -1,6 +1,6 @@
---
title: FAQ
description: Frequently asked questions about Better-Auth.
description: Frequently asked questions about Better Auth.
---
This page contains frequently asked questions, common issues, and other helpful information about Better Auth.