Accessing User Data in Protected Endpoints

A Quick Recap: The get_current_user Dependency

Remember the get_current_user dependency you created? It's the engine for everything we're doing in this lesson. On any request to a protected endpoint, it:

1. Extracts the JWT from the Authorization header.
2. Decodes and validates the token.
3. Fetches the corresponding user object from the database.
4. Makes that full SQLAlchemy User object available to our endpoint function.

This means that within any protected endpoint, we have a trusted current_user variable that holds all the information about the person making the request.

Step 1: Assigning Ownership on Resource Creation

A major security flaw in many APIs is allowing the client to specify the owner of a new resource. For example, letting a user send {"title": "My Post", "content": "...", "user_id": 5} in a request body would allow them to create a post on behalf of user 5.

The correct approach is to determine the owner from the trusted JWT. Let's implement this for your "create post" endpoint.

First, you'll need to modify your Pydantic schema for creating posts to remove the user_id field. The client should only send the title and content. Your dependency will handle the rest.

Next, you will modify the create_post endpoint to use the current_user dependency to set the owner.

The following video provides an excellent, practical walkthrough of this exact process. It also introduces a CurrentUser type alias using typing.Annotated, a modern Python feature that makes your endpoint signatures cleaner and more readable.

After watching the video, update your own code to implement this pattern. By doing this, you've made your API more secure and improved the user experience—the client no longer needs to know or provide its own user ID.

Step 2: Enforcing Authorization with Ownership Checks

Now that posts are correctly associated with their owners, we must ensure that only the owner can modify or delete them. This is authorization—determining if an authenticated user has permission to perform a specific action.

The logic is straightforward:

1. Protect the update and delete endpoints with your current_user dependency.
2. Inside the endpoint, first fetch the resource (e.g., the post) the user is trying to modify.
3. Compare the resource's owner ID (post.user_id) with the ID of the person making the request (current_user.id).
4. If they don't match, raise an HTTPException with a 403 Forbidden status code.

A 403 Forbidden error tells the client: "We know who you are, and you are not allowed to do this." This is distinct from the 401 Unauthorized error, which means "We don't know who you are."

The next part of the same video demonstrates this perfectly.

Go ahead and apply these authorization checks to your update_post and delete_post endpoints.

Step 3: Hands-On Test Drive

Theory is one thing, but seeing it in action is what solidifies learning. Let's run a test scenario to confirm our ownership rules are working correctly.

1. Start fresh: Delete your SQLite database file to ensure a clean slate, then run your FastAPI application.
2. Create User A: Go to the /docs page and create a new user (e.g., userA@example.com).
3. Log in as User A: Use the Authorize button in Swagger UI to log in as User A and get a token.
4. Create Post 1: As User A, create a new post. Note its ID (it should be 1).
5. Create User B: Log out (clear the authorization in Swagger). Create a second user (e.g., userB@example.com).
6. Log in as User B: Authorize as User B.
7. Test the Rule: Attempt to update or delete Post 1 (the one created by User A).

You should receive a 403 Forbidden error with the detail message you configured, proving that your authorization logic is working!

This testing flow is demonstrated visually in the video.

Step 4: Retrieving User-Specific Data

The final common use case is creating an endpoint that lists resources belonging only to the authenticated user. Let's build a new endpoint, GET /posts/me, that returns all posts created by the current user.

This brings together everything you've learned: a protected endpoint and a database query filtered by the current user's ID.

In your posts router file, add a new endpoint like this:

from typing import List
from .. import schemas, models, auth_utils # Adjust imports as needed
from sqlalchemy.orm import Session
from sqlalchemy import select




# ... (your router setup)

@router.get("/me", response_model=List[schemas.Post])
async def get_my_posts(
    db: Session = Depends(database.get_db), 
    current_user: models.User = Depends(auth_utils.get_current_user)
):
    """
    Retrieve all posts created by the currently authenticated user.
    """



    # Create a query to select posts where the user_id matches the current user's id
    query = select(models.Post).where(models.Post.user_id == current_user.id)
    result = await db.execute(query)
    posts = result.scalars().all()
    
    return posts

Dissecting this endpoint:

• It's protected by Depends(auth_utils.get_current_user), so we have access to the current_user object.
• The SQLAlchemy query is simple but powerful: select(models.Post).where(models.Post.user_id == current_user.id). It filters the Post table to find only those records whose user_id matches the ID of the person making the request.
• It returns a list of posts, correctly serialized by the response_model.

Add this endpoint to your application and test it. After creating posts with both User A and User B, you should see that calling this endpoint while logged in as User A only returns posts made by User A.

Conclusion

Excellent work! You have now mastered a fundamental aspect of secure API development. You've moved beyond simple authentication to implement robust authorization, ensuring users can only interact with their own data.

Key Takeaways:

• The authenticated current_user object is the trusted source for a user's identity within an endpoint.
• Ownership of new data should always be assigned on the server-side using the current_user.id, never from the request body.
• Authorization logic (403 Forbidden) prevents users from accessing or modifying resources they don't own.
• You can easily create endpoints that provide a personalized view of data by filtering database queries with current_user.id.

With a fully functional and secure CRUD API for users and posts, you are now well-prepared to tackle the primary goal of this course. In the next module, we will begin integrating a machine learning model into our FastAPI application, creating a prediction endpoint that we can secure using the authentication and authorization skills you've just honed.