mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-08-20 22:52:29 +02:00
Add pt 2 and 3
This commit is contained in:
William Fu-Hinthorn
@@ -0,0 +1,337 @@
|
||||
# Connecting an Authentication Provider
|
||||
|
||||
In the previous tutorial, we added [resource authorization](../../concepts/auth.md#resource-authorization) to give users private conversations. However, we were still using hard-coded tokens for authentication, which is not secure. Now we'll replace those tokens with real user accounts using [OAuth2](../../concepts/auth.md#oauth2-authentication).
|
||||
|
||||
We'll keep the same [`Auth`](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth) object and [resource-level access control](../../concepts/auth.md#resource-level-access-control), but upgrade our authentication to use Supabase as our identity provider. While we use Supabase in this tutorial, the concepts apply to any OAuth2 provider. You'll learn how to:
|
||||
|
||||
1. Replace test tokens with real [JWT tokens](../../concepts/auth.md#jwt-tokens)
|
||||
2. Integrate with OAuth2 providers for secure user authentication
|
||||
3. Handle user sessions and metadata while maintaining our existing authorization logic
|
||||
|
||||
!!! note "This is part 3 of our authentication series:"
|
||||
|
||||
1. [Basic Authentication](getting_started.md) - Control who can access your bot
|
||||
2. [Resource Authorization](resource_auth.md) - Let users have private conversations
|
||||
3. Production Auth (you are here) - Add real user accounts and validate using OAuth2
|
||||
|
||||
!!! warning "Prerequisites"
|
||||
|
||||
- Complete the [Resource Authorization](resource_auth.md) tutorial
|
||||
- [Create a Supabase project](https://supabase.com/dashboard)
|
||||
- Have your project URL and service role key ready
|
||||
|
||||
## Background
|
||||
|
||||
OAuth2 involves three main roles:
|
||||
|
||||
1. **Authorization server**: The identity provider (e.g., Supabase, Auth0, Google) that handles user authentication and issues tokens
|
||||
2. **Application backend**: Your LangGraph application. This validates tokens and serves protected resources (conversation data)
|
||||
3. **Client application**: The web or mobile app where users interact with your service
|
||||
|
||||
A standard OAuth2 flow works something like this:
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Client
|
||||
participant AuthServer
|
||||
participant LangGraph Backend
|
||||
|
||||
User->>Client: Initiate login
|
||||
User->>AuthServer: Enter credentials
|
||||
AuthServer->>Client: Send tokens
|
||||
Client->>LangGraph Backend: Request with token
|
||||
LangGraph Backend->>AuthServer: Validate token
|
||||
AuthServer->>LangGraph Backend: Token valid
|
||||
LangGraph Backend->>Client: Serve request (e.g., run agent or graph)
|
||||
```
|
||||
|
||||
In the following example, we'll use Supabase as our auth server. The LangGraph application will provide the backend for your app, and we will write test code for the client app.
|
||||
Let's get started!
|
||||
|
||||
## Setting Up Authentication Provider
|
||||
|
||||
First, let's install the required dependencies. Start in your `custom-auth` directory and ensure you have the `langgraph-cli` installed:
|
||||
|
||||
```bash
|
||||
cd custom-auth
|
||||
pip install -U "langgraph-cli[inmem]"
|
||||
```
|
||||
|
||||
Next, we'll need to fech the URL of our auth server and the private key for authentication.
|
||||
Since we're using Supabase for this, we can do this in the Supabase dashboard:
|
||||
|
||||
1. In the left sidebar, click on t️⚙ Project Settings" and then click "API"
|
||||
2. Copy your project URL and add it to your `.env` file
|
||||
|
||||
```shell
|
||||
echo "SUPABASE_URL=your-project-url" >> .env
|
||||
```
|
||||
|
||||
3. Next, copy your service role secret key and add it to your `.env` file
|
||||
|
||||
```shell
|
||||
echo "SUPABASE_SERVICE_KEY=your-service-role-key" >> .env
|
||||
```
|
||||
|
||||
4. Finally, copy your "anon public" key and note it down. This will be used later when we set up our client code.
|
||||
|
||||
```bash
|
||||
SUPABASE_URL=your-project-url
|
||||
SUPABASE_SERVICE_KEY=your-service-role-key
|
||||
```
|
||||
|
||||
## Implementing Token Validation
|
||||
|
||||
In the previous tutorials, we used the [`Auth`](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth) object to:
|
||||
|
||||
1. Validate hard-coded tokens in the [authentication tutorial](getting_started.md)
|
||||
2. Add resource ownership in the [authorization tutorial](resource_auth.md)
|
||||
|
||||
Now we'll upgrade our authentication to validate real JWT tokens from Supabase. The key changes will all be in the [`@auth.authenticate`](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth.authenticate) decorated function:
|
||||
|
||||
1. Instead of checking against a hard-coded list of tokens, we'll make an HTTP request to Supabase to validate the token
|
||||
2. We'll extract real user information (ID, email) from the validated token
|
||||
|
||||
And we'll keep our existing resource authorization logic unchanged
|
||||
|
||||
Let's update `src/security/auth.py` to implement this:
|
||||
|
||||
```python
|
||||
import os
|
||||
import httpx
|
||||
from langgraph_sdk import Auth
|
||||
|
||||
auth = Auth()
|
||||
|
||||
# This is loaded from the `.env` file you created above
|
||||
SUPABASE_URL = os.environ["SUPABASE_URL"]
|
||||
SUPABASE_SERVICE_KEY = os.environ["SUPABASE_SERVICE_KEY"]
|
||||
|
||||
|
||||
@auth.authenticate
|
||||
async def get_current_user(authorization: str | None):
|
||||
"""Validate JWT tokens and extract user information."""
|
||||
assert authorization
|
||||
scheme, token = authorization.split()
|
||||
assert scheme.lower() == "bearer"
|
||||
|
||||
try:
|
||||
# Verify token with auth provider
|
||||
async with httpx.AsyncClient() as client:
|
||||
response = await client.get(
|
||||
f"{SUPABASE_URL}/auth/v1/user",
|
||||
headers={
|
||||
"Authorization": authorization,
|
||||
"apiKey": SUPABASE_SERVICE_KEY,
|
||||
},
|
||||
)
|
||||
assert response.status_code == 200
|
||||
user = response.json()
|
||||
return {
|
||||
"identity": user["id"], # Unique user identifier
|
||||
"email": user["email"],
|
||||
"is_authenticated": True,
|
||||
}
|
||||
except Exception as e:
|
||||
raise Auth.exceptions.HTTPException(status_code=401, detail=str(e))
|
||||
|
||||
|
||||
# Keep our resource authorization from the previous tutorial
|
||||
@auth.on
|
||||
async def add_owner(ctx, value):
|
||||
"""Make resources private to their creator using resource metadata."""
|
||||
filters = {"owner": ctx.user.identity}
|
||||
metadata = value.setdefault("metadata", {})
|
||||
metadata.update(filters)
|
||||
return filters
|
||||
```
|
||||
|
||||
The most important change is that we're now validating tokens with a real authentication server. Our authentication handler has the private key for our Supabase project, which we can use to validate the user's token and extract their information.
|
||||
|
||||
Let's test this with a real user account!
|
||||
|
||||
## Testing Authentication Flow
|
||||
|
||||
Create a new file `create_users.py`. This will stand-in for a frontend that lets users sign up and log in.
|
||||
|
||||
```python
|
||||
import argparse
|
||||
import asyncio
|
||||
import os
|
||||
|
||||
import dotenv
|
||||
import httpx
|
||||
from langgraph_sdk import get_client
|
||||
|
||||
dotenv.load_dotenv()
|
||||
|
||||
# Get email from command line
|
||||
parser = argparse.ArgumentParser()
|
||||
parser.add_argument("email", help="Your email address for testing")
|
||||
args = parser.parse_args()
|
||||
|
||||
base_email = args.email.split("@")
|
||||
email1 = f"{base_email[0]}+1@{base_email[1]}"
|
||||
email2 = f"{base_email[0]}+2@{base_email[1]}"
|
||||
|
||||
SUPABASE_URL = os.environ["SUPABASE_URL"]
|
||||
SUPABASE_SERVICE_KEY = os.environ["SUPABASE_SERVICE_KEY"]
|
||||
|
||||
|
||||
async def sign_up(email: str, password: str):
|
||||
"""Create a new user account."""
|
||||
async with httpx.AsyncClient() as client:
|
||||
response = await client.post(
|
||||
f"{SUPABASE_URL}/auth/v1/signup",
|
||||
json={"email": email, "password": password},
|
||||
headers={"apiKey": SUPABASE_SERVICE_KEY},
|
||||
)
|
||||
assert response.status_code == 200
|
||||
return response.json()
|
||||
|
||||
async def main():
|
||||
# Create two test users
|
||||
password = "secure-password" # CHANGEME
|
||||
print(f"Creating test users: {email1} and {email2}")
|
||||
await sign_up(email1, password)
|
||||
await sign_up(email2, password)
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
Then run the setup script:
|
||||
|
||||
```shell
|
||||
python create_users.py CHANGEME@example.com
|
||||
```
|
||||
|
||||
!!! tip "About test emails"
|
||||
We'll create two test accounts by adding "+1" and "+2" to your email. For example, if you use "myemail@gmail.com", we'll create "myemail+1@gmail.com" and "myemail+2@gmail.com". All emails will be delivered to your original address.
|
||||
|
||||
⚠️ Before continuing: Check your email and click both confirmation links. This would normally be handled by your frontend.
|
||||
|
||||
Now let's test that users can only see their own data. Create a new file `test_oauth.py`. This will stand-in for your application's frontend.
|
||||
|
||||
```python
|
||||
import argparse
|
||||
import asyncio
|
||||
import os
|
||||
|
||||
import dotenv
|
||||
import httpx
|
||||
from langgraph_sdk import get_client
|
||||
|
||||
dotenv.load_dotenv()
|
||||
|
||||
# Get email from command line
|
||||
parser = argparse.ArgumentParser()
|
||||
parser.add_argument("email", help="Your email address for testing")
|
||||
args = parser.parse_args()
|
||||
|
||||
# Create two test emails from the base email
|
||||
base_email = args.email.split("@")
|
||||
email1 = f"{base_email[0]}+1@{base_email[1]}"
|
||||
email2 = f"{base_email[0]}+2@{base_email[1]}"
|
||||
|
||||
# Initialize auth provider settings
|
||||
SUPABASE_URL = os.environ["SUPABASE_URL"]
|
||||
SUPABASE_ANON_KEY = os.environ["SUPABASE_ANON_KEY"]
|
||||
|
||||
|
||||
async def login(email: str, password: str):
|
||||
"""Get an access token for an existing user."""
|
||||
async with httpx.AsyncClient() as client:
|
||||
response = await client.post(
|
||||
f"{SUPABASE_URL}/auth/v1/token?grant_type=password",
|
||||
json={
|
||||
"email": email,
|
||||
"password": password
|
||||
},
|
||||
headers={
|
||||
"apikey": SUPABASE_ANON_KEY,
|
||||
"Content-Type": "application/json"
|
||||
},
|
||||
)
|
||||
if response.status_code == 200:
|
||||
return response.json()["access_token"]
|
||||
else:
|
||||
raise ValueError(f"Login failed: {response.status_code} - {response.text}")
|
||||
|
||||
|
||||
async def main():
|
||||
password = "secure-password"
|
||||
|
||||
# Log in as user 1
|
||||
user1_token = await login(email1, password)
|
||||
user1_client = get_client(
|
||||
url="http://localhost:2024", headers={"Authorization": f"Bearer {user1_token}"}
|
||||
)
|
||||
|
||||
# Create a thread as user 1
|
||||
thread = await user1_client.threads.create()
|
||||
print(f"✅ User 1 created thread: {thread['thread_id']}")
|
||||
|
||||
# Try to access without a token
|
||||
unauthenticated_client = get_client(url="http://localhost:2024")
|
||||
try:
|
||||
await unauthenticated_client.threads.create()
|
||||
print("❌ Unauthenticated access should fail!")
|
||||
except Exception as e:
|
||||
print("✅ Unauthenticated access blocked:", e)
|
||||
|
||||
# Try to access user 1's thread as user 2
|
||||
user2_token = await login(email2, password)
|
||||
user2_client = get_client(
|
||||
url="http://localhost:2024", headers={"Authorization": f"Bearer {user2_token}"}
|
||||
)
|
||||
|
||||
try:
|
||||
await user2_client.threads.get(thread["thread_id"])
|
||||
print("❌ User 2 shouldn't see User 1's thread!")
|
||||
except Exception as e:
|
||||
print("✅ User 2 blocked from User 1's thread:", e)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
Fetch the SUPABASE_ANON_KEY that you copied from the Supabase dashboard in step (1), then run the test. Make sure the server is running (if you have run `langgraph dev`):
|
||||
|
||||
```bash
|
||||
python test_oauth.py CHANGEME@example.com
|
||||
```
|
||||
|
||||
> ➜ custom-auth SUPABASE_ANON_KEY=eyJh... python test_oauth.py CHANGEME@example.com
|
||||
> ✅ User 1 created thread: d6af3754-95df-4176-aa10-dbd8dca40f1a
|
||||
> ✅ Unauthenticated access blocked: Client error '403 Forbidden' for url 'http://localhost:2024/threads'
|
||||
> ✅ User 2 blocked from User 1's thread: Client error '404 Not Found' for url 'http://localhost:2024/threads/d6af3754-95df-4176-aa10-dbd8dca40f1a'
|
||||
|
||||
Perfect! Our authentication and authorization are working together:
|
||||
1. Users must log in to access the bot
|
||||
2. Each user can only see their own threads
|
||||
|
||||
All our users are managed by the Supabase auth provider, so we don't need to implement any additional user management logic.
|
||||
|
||||
## Congratulations! 🎉
|
||||
|
||||
You've successfully built a production-ready authentication system for your LangGraph application! Let's review what you've accomplished:
|
||||
|
||||
1. Set up an authentication provider (Supabase in this case)
|
||||
2. Added real user accounts with email/password authentication
|
||||
3. Integrated JWT token validation into your LangGraph server
|
||||
4. Implemented proper authorization to ensure users can only access their own data
|
||||
5. Created a foundation that's ready to handle your next authentication challenge 🚀
|
||||
|
||||
This completes our authentication tutorial series. You now have the building blocks for a secure, production-ready LangGraph application.
|
||||
|
||||
## What's Next?
|
||||
|
||||
Now that you have production authentication, consider:
|
||||
|
||||
1. Building a web UI with your preferred framework (see the [Custom Auth](https://github.com/langchain-ai/custom-auth) template for an example)
|
||||
2. Learn more about the other aspects of authentication and authorization in the [conceptual guide on authentication](../../concepts/auth.md).
|
||||
3. Customize your handlers and setup further after reading the [reference docs](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth).
|
||||
@@ -0,0 +1,259 @@
|
||||
# Making Conversations Private
|
||||
|
||||
In this tutorial, we will extend our chatbot to give each user their own private conversations. We'll add [resource-level access control](../../concepts/auth.md#resource-level-access-control) so users can only see their own threads.
|
||||
|
||||
!!! note "This is part 2 of our authentication series:"
|
||||
|
||||
1. [Basic Authentication](getting_started.md) - Control who can access your bot
|
||||
2. Resource Authorization (you are here) - Let users have private conversations
|
||||
3. [Production Auth](add_auth_server.md) - Add real user accounts and validate using OAuth2
|
||||
|
||||
## Understanding Resource Authorization
|
||||
|
||||
In the last tutorial, we controlled who could access our bot. But right now, any authenticated user can see everyone else's conversations! Let's fix that by adding [resource authorization](../../concepts/auth.md#resource-authorization).
|
||||
|
||||
First, make sure you have completed the [Basic Authentication](getting_started.md) tutorial and that your secure bot can be run without errors:
|
||||
|
||||
```bash
|
||||
cd custom-auth
|
||||
pip install -e .
|
||||
langgraph dev --no-browser
|
||||
```
|
||||
|
||||
> - 🚀 API: http://127.0.0.1:2024
|
||||
> - 🎨 Studio UI: https://smith.langchain.com/studio/?baseUrl=http://127.0.0.1:2024
|
||||
> - 📚 API Docs: http://127.0.0.1:2024/docs
|
||||
|
||||
## Adding Resource Authorization
|
||||
|
||||
Recall that in the last tutorial, the [`Auth`](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.Auth) object let us register an [authentication function](../../concepts/auth.md#authentication), which the LangGraph platform uses to validate the bearer tokens in incoming requests. Now we'll use it to register an **authorization** handler.
|
||||
|
||||
Authorization handlers are functions that run **after** authentication succeeds. These handlers can add [metadata](../../concepts/auth.md#resource-metadata) to resources (like who owns them) and filter what each user can see.
|
||||
|
||||
Let's update our `src/security/auth.py` and add one authorization handler that is run on every request:
|
||||
|
||||
```python hl_lines="29-39"
|
||||
from langgraph_sdk import Auth
|
||||
|
||||
# Keep our test users from the previous tutorial
|
||||
VALID_TOKENS = {
|
||||
"user1-token": {"id": "user1", "name": "Alice"},
|
||||
"user2-token": {"id": "user2", "name": "Bob"},
|
||||
}
|
||||
|
||||
auth = Auth()
|
||||
|
||||
|
||||
@auth.authenticate
|
||||
async def get_current_user(authorization: str | None) -> Auth.types.MinimalUserDict:
|
||||
"""Our authentication handler from the previous tutorial."""
|
||||
assert authorization
|
||||
scheme, token = authorization.split()
|
||||
assert scheme.lower() == "bearer"
|
||||
|
||||
if token not in VALID_TOKENS:
|
||||
raise Auth.exceptions.HTTPException(status_code=401, detail="Invalid token")
|
||||
|
||||
user_data = VALID_TOKENS[token]
|
||||
return {
|
||||
"identity": user_data["id"],
|
||||
}
|
||||
|
||||
|
||||
@auth.on
|
||||
async def add_owner(
|
||||
ctx: Auth.types.AuthContext, # Contains info about the current user
|
||||
value: dict, # The resource being created/accessed
|
||||
):
|
||||
"""Make resources private to their creator."""
|
||||
# Add owner when creating resources
|
||||
filters = {"owner": ctx.user.identity}
|
||||
metadata = value.setdefault("metadata", {})
|
||||
metadata.update(filters)
|
||||
|
||||
# Only let users see their own resources
|
||||
return filters
|
||||
```
|
||||
|
||||
The handler receives two parameters:
|
||||
|
||||
1. `ctx` ([AuthContext](../../cloud/reference/sdk/python_sdk_ref.md#langgraph_sdk.auth.types.AuthContext)): contains info about the current `user`, the user's `permissions`, the `resource` ("threads", "crons", "assistants"), and the `action` being taken ("create", "read", "update", "delete", "search", "create_run")
|
||||
2. `value` (`dict`): data that is being created or accessed. The contents of this dict depend on the resource and action being accessed. See [adding scoped authorization handlers](#scoped-authorization) below for information on how to get more tightly scoped access control.
|
||||
|
||||
Notice that our simple handler does two things:
|
||||
|
||||
1. Adds the user's ID to the resource's metadata.
|
||||
2. Returns a metadata filter so users only see resources they own.
|
||||
|
||||
## Testing Private Conversations
|
||||
|
||||
Let's test our authorization. Create a new file `test_private.py`:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
from langgraph_sdk import get_client
|
||||
|
||||
async def test_private():
|
||||
# Create clients for both users
|
||||
alice = get_client(
|
||||
url="http://localhost:2024",
|
||||
headers={"Authorization": "Bearer user1-token"}
|
||||
)
|
||||
|
||||
bob = get_client(
|
||||
url="http://localhost:2024",
|
||||
headers={"Authorization": "Bearer user2-token"}
|
||||
)
|
||||
|
||||
# Alice creates a thread and chats
|
||||
alice_thread = await alice.threads.create()
|
||||
print(f"✅ Alice created thread: {alice_thread['thread_id']}")
|
||||
|
||||
await alice.runs.create(
|
||||
thread_id=alice_thread["thread_id"],
|
||||
assistant_id="agent",
|
||||
input={"messages": [{"role": "user", "content": "Hi, this is Alice's private chat"}]}
|
||||
)
|
||||
|
||||
# Bob tries to access Alice's thread
|
||||
try:
|
||||
await bob.threads.get(alice_thread["thread_id"])
|
||||
print("❌ Bob shouldn't see Alice's thread!")
|
||||
except Exception as e:
|
||||
print("✅ Bob correctly denied access:", e)
|
||||
|
||||
# Bob creates his own thread
|
||||
bob_thread = await bob.threads.create()
|
||||
await bob.runs.create(
|
||||
thread_id=bob_thread["thread_id"],
|
||||
assistant_id="agent",
|
||||
input={"messages": [{"role": "user", "content": "Hi, this is Bob's private chat"}]}
|
||||
)
|
||||
print(f"✅ Bob created his own thread: {bob_thread['thread_id']}")
|
||||
|
||||
# List threads - each user only sees their own
|
||||
alice_threads = await alice.threads.list()
|
||||
bob_threads = await bob.threads.list()
|
||||
print(f"✅ Alice sees {len(alice_threads)} thread")
|
||||
print(f"✅ Bob sees {len(bob_threads)} thread")
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(test_private())
|
||||
```
|
||||
|
||||
Run the test code and you should see output like this:
|
||||
|
||||
```bash
|
||||
✅ Alice created thread: 533179b7-05bc-4d48-b47a-a83cbdb5781d
|
||||
✅ Bob correctly denied access: Client error '404 Not Found' for url 'http://localhost:2024/threads/533179b7-05bc-4d48-b47a-a83cbdb5781d'
|
||||
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
|
||||
✅ Bob created his own thread: 437c36ed-dd45-4a1e-b484-28ba6eca8819
|
||||
✅ Alice sees 1 thread
|
||||
✅ Bob sees 1 thread
|
||||
```
|
||||
|
||||
This means:
|
||||
|
||||
1. Each user can create and chat in their own threads
|
||||
2. Users can't see each other's threads
|
||||
3. Listing threads only shows your own
|
||||
|
||||
## Adding scoped authorization handlers {#scoped-authorization}
|
||||
|
||||
The broad `@auth.on` handler matches on all [authorization events](../../concepts/auth.md#authorization-events). This is concise, but it means the contents of the `value` dict are not well-scoped, and we apply the same user-level access control to every resource. If we want to be more fine-grained, we can also control specific actions on resources.
|
||||
|
||||
Update `src/security/auth.py` to add handlers for specific resource types:
|
||||
|
||||
```python
|
||||
# Keep our previous handlers...
|
||||
|
||||
@auth.on.threads.create
|
||||
async def on_thread_create(
|
||||
ctx: Auth.types.AuthContext,
|
||||
value: Auth.types.on.threads.create.value,
|
||||
):
|
||||
"""Add owner when creating threads."""
|
||||
metadata = value.setdefault("metadata", {})
|
||||
metadata["owner"] = ctx.user.identity
|
||||
return {"owner": ctx.user.identity}
|
||||
|
||||
@auth.on.threads.read
|
||||
async def on_thread_read(
|
||||
ctx: Auth.types.AuthContext,
|
||||
value: Auth.types.on.threads.read.value,
|
||||
):
|
||||
"""Only let users read their own threads."""
|
||||
return {"owner": ctx.user.identity}
|
||||
|
||||
@auth.on.threads.create_run
|
||||
async def on_run_create(
|
||||
ctx: Auth.types.AuthContext,
|
||||
value: Auth.types.on.threads.create_run.value,
|
||||
):
|
||||
"""Only let thread owners create runs."""
|
||||
return {"owner": ctx.user.identity}
|
||||
|
||||
@auth.on.assistants
|
||||
async def on_assistants(
|
||||
ctx: Auth.types.AuthContext,
|
||||
value: Auth.types.on.assistants.value,
|
||||
):
|
||||
raise Auth.exceptions.HTTPException(
|
||||
status_code=403,
|
||||
detail="Not authorized to access assistants"
|
||||
)
|
||||
```
|
||||
|
||||
Notice that instead of one global handler, we now have specific handlers for:
|
||||
|
||||
1. Creating threads
|
||||
2. Reading threads
|
||||
3. Creating runs
|
||||
4. Accessing assistants
|
||||
|
||||
The first three of these match specific **actions** on each resource (see [resource actions](../../concepts/auth.md#resource-actions)), while the last one (`@auth.on.assistants`) matches _any_ action on the `assistants` resource. For each request, LangGraph will run the most specific handler that matches the resource and action being accessed. This means that the four handlers above will run rather than the broad "@auth.on" handler.
|
||||
|
||||
Try adding the following test code to `test_private.py`:
|
||||
|
||||
```python
|
||||
async def test_private():
|
||||
# ... Same as before
|
||||
# Try creating an assistant. This should fail
|
||||
try:
|
||||
await alice.assistants.create("agent")
|
||||
print("❌ Alice shouldn't be able to create assistants!")
|
||||
except Exception as e:
|
||||
print("✅ Alice correctly denied access:", e)
|
||||
|
||||
# Try searching for assistants. This also should fail
|
||||
try:
|
||||
await alice.assistants.search()
|
||||
print("❌ Alice shouldn't be able to search assistants!")
|
||||
except Exception as e:
|
||||
print("✅ Alice correctly denied access to searching assistants:", e)
|
||||
```
|
||||
|
||||
And then run the test code again:
|
||||
|
||||
```bash
|
||||
> python test_private.py
|
||||
✅ Alice created thread: dcea5cd8-eb70-4a01-a4b6-643b14e8f754
|
||||
✅ Bob correctly denied access: Client error '404 Not Found' for url 'http://localhost:2024/threads/dcea5cd8-eb70-4a01-a4b6-643b14e8f754'
|
||||
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404
|
||||
✅ Bob created his own thread: 400f8d41-e946-429f-8f93-4fe395bc3eed
|
||||
✅ Alice sees 1 thread
|
||||
✅ Bob sees 1 thread
|
||||
✅ Alice correctly denied access:
|
||||
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500
|
||||
✅ Alice correctly denied access to searching assistants:
|
||||
```
|
||||
|
||||
Congratulations! You've built a chatbot where each user has their own private conversations. While this system uses simple token-based authentication, the authorization patterns we've learned will work with implementing any real authentication system. In the next tutorial, we'll replace our test users with real user accounts using OAuth2.
|
||||
|
||||
## What's Next?
|
||||
|
||||
Now that you can control access to resources, you might want to:
|
||||
|
||||
1. Move on to [Production Auth](add_auth_server.md) to add real user accounts
|
||||
2. Read more about [authorization patterns](../../concepts/auth.md#authorization)
|
||||
3. Try adding shared resources between users
|
||||
Reference in New Issue
Block a user