Test your FastAPI Users knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
Why would validating a registration request body with a Pydantic schema (as FastAPI Users does) be preferable to accepting raw, unvalidated form/JSON data directly?
In this round
Why would validating a registration request body with a Pydantic schema (as FastAPI Users does) be preferable to accepting raw, unvalidated form/JSON data directly?
What is the purpose of FastAPI Users' pluggable "user manager" class that developers typically subclass and customize?
How does FastAPI Users typically identify a user record internally, and why might using a UUID rather than an auto-incrementing integer ID be the default choice?
What does FastAPI Users' support for OAuth2 (social login, e.g. "Sign in with Google") typically add on top of its core email/password authentication?
What consideration is important when deciding whether to expose the raw FastAPI Users user model directly as an API response versus using a dedicated output schema?
What does FastAPI Users' pre-built registration router typically provide out of the box?
What does FastAPI Users' `current_active_user` dependency check that a more basic `current_user` dependency might not?
How does FastAPI Users typically integrate with an application's database layer?
Why is it generally considered risky for a team to hand-roll their own authentication system from scratch instead of using a well-established library like FastAPI Users?
Why does FastAPI Users hash user passwords before storing them, rather than storing plaintext passwords?
What does it mean that FastAPI Users' routers are designed to be "mounted" onto a FastAPI application, e.g. `app.include_router(fastapi_users.get_auth_router(...))`?
Why might a project choose a JWT-based authentication backend over a database-backed session/cookie backend with FastAPI Users?