3393863dd2
* Add status property to content item structure This commit introduces a new `status` property to the content item structure, allowing content items to maintain a status such as 'draft', 'published', 'review', 'pending'. This status is mapped to the corresponding status in Wordpress and Keystatic clients to ensure consistent usage across platforms. Content retrieval methods now also include a status filter. * Refactor code for style and readability improvements This commit includes changes in various files across different packages to improve code readability, including adjusting spacing and breaking down complex lines into simpler parts. In addition, the switch statement in `wp-client.ts` has been refactored and status values are now held in variables, and the CSS classes in `global-loader.tsx` have been reorganized.
56 lines
2.0 KiB
Plaintext
56 lines
2.0 KiB
Plaintext
---
|
|
title: "Configuration"
|
|
description: "Learn how authentication works in MakerKit and how to configure it."
|
|
publishedAt: 2024-04-11
|
|
order: 0
|
|
parent: "authentication/authentication"
|
|
status: "published"
|
|
---
|
|
|
|
The way you want your users to authenticate can be driven via configuration.
|
|
|
|
If you open the global configuration at `src/configuration.ts`, you'll find
|
|
the `auth` object:
|
|
|
|
```tsx title="configuration.ts"
|
|
import type { Provider } from '@supabase/gotrue-js/src/lib/types';
|
|
|
|
auth: {
|
|
requireEmailConfirmation: false,
|
|
providers: {
|
|
emailPassword: true,
|
|
phoneNumber: false,
|
|
emailLink: false,
|
|
oAuth: ['google'] as Provider[],
|
|
},
|
|
}
|
|
```
|
|
|
|
As you can see, the `providers` object can be configured to only display the
|
|
auth methods we want to use.
|
|
|
|
1. For example, by setting both `phoneNumber` and `emailLink` to `true`, the
|
|
authentication pages will display the `Email Link` authentication
|
|
and the `Phone Number` authentication forms.
|
|
2. Instead, by setting `emailPassword` to `false`, we will remove the
|
|
`email/password` form from the authentication and user profile pages.
|
|
|
|
## Requiring Email Verification
|
|
|
|
This setting needs to match what you have set up in Supabase. If you require email confirmation before your users can sign in, you will have to flip the following flag in your configuration:
|
|
|
|
```ts
|
|
auth: {
|
|
requireEmailConfirmation: false,
|
|
}
|
|
```
|
|
|
|
When the flag is set to `true`, the user will not be redirected to the onboarding flow, but will instead see a successful alert asking them to confirm their email. After confirmation, they will be able to sign in.
|
|
|
|
When the flag is set to `false`, the application will redirect them directly to the onboarding flow.
|
|
|
|
## Emails sent by Supabase
|
|
|
|
Supabase spins up an [InBucket](http://localhost:54324/) instance where all the emails are sent: this is where you can find emails related to password reset, sign-in links, and email verifications.
|
|
|
|
To access the InBucket instance, you can go to the following URL: [http://localhost:54324/](http://localhost:54324/). Save this URL, you will use it very often. |