-
-
Notifications
You must be signed in to change notification settings - Fork 38
doc: guide for custom auth #395
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| --- | ||
| description: Integrating with a custom authentication system. | ||
| sidebar_position: 100 | ||
| sidebar_label: Custom Authentication | ||
| --- | ||
|
|
||
| # Integrating With a Custom Authentication System | ||
|
|
||
| You may be using an authentication provider that's not mentioned in the guides. Or you may have a custom-implemented one. Integrating ZenStack with any authentication system is pretty straightforward. This guide will provide the general steps to follow. | ||
|
|
||
| ## Determining what's needed for access control | ||
|
|
||
| The bridge that connects authentication and authorization is the `auth()` function that represents the authenticated current user. Based on your requirements, you should determine what fields are needed from it. The `auth()` object must at least contain an id field that uniquely identifies the current user. If you do RBAC, you'll very likely need an `auth().role` field available. Or even an `auth().permissions` field for fine-grained control. | ||
|
|
||
| The `auth()` call needs to be resolved to a "type" in ZModel. If you store user data in your database, you may already have a "User" model that carries all the fields you need to access. | ||
|
|
||
| ```zmodel | ||
| model User { | ||
| id String @id | ||
| role String | ||
| permissions String[] | ||
| ... | ||
| } | ||
| ``` | ||
|
|
||
| ZenStack picks up the model named "User" automatically to resolve `auth()` unless another model or type is specifically appointed (by using the `@@auth` attribute). For example, if you're not storing user data locally, you can define a "type" to resolve `auth()`. This way, you can provide typing without being backed by a database table. | ||
|
|
||
| ```zmodel | ||
| type Auth { | ||
| id String @id | ||
| role String | ||
| permissions String[] | ||
| @@auth | ||
| } | ||
| ``` | ||
|
|
||
| Just remember that any thing that you access from `auth().` must be resolved. | ||
|
|
||
| ## Fetching the current user along with the additional information | ||
|
|
||
| At runtime in your backend code, you need to provide a value for the `auth()` call to ZenStack, so it can use it to evaluate access policies. How this is done is solely dependent on your authentication mechanism. Here are some examples: | ||
|
|
||
| 1. If you use JWT tokens, you can issue tokens with user id and other fields embedded, then validate and extract them from the request. | ||
| 2. If you use a dedicated authentication service, you can call it to get the current user's information. | ||
|
|
||
| You must ensure that whatever approach you use, the user information you get can be trusted and free of tampering. | ||
|
|
||
| ## Creating an enhanced PrismaClient | ||
|
|
||
| Finally, you can call the `enhance` API to create an enhanced PrismaClient with the user information and enjoy automatically enforced access policies. | ||
|
|
||
| ```ts | ||
| const user = await getCurrentUser(); // your implementation | ||
| const db = enhance(prisma, { user }); | ||
| ``` | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
💡 Codebase verification
Sidebar position should be adjusted to maintain documentation order
The high
sidebar_position: 100appears to be inconsistent with the sequence of other authentication guides which use values 1-6. Since this is a custom authentication guide, it should be positioned appropriately within the sequence, likely after the specific auth provider guides.sidebar_positionto7to maintain a logical sequence after auth0 (6) and other specific providers🔗 Analysis chain
Verify the sidebar position value
The
sidebar_position: 100seems unusually high. Please confirm if this is intentional or if it should be adjusted to match the sequence of other authentication guides.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
Length of output: 452