Tbt/gateway status - #1506
Conversation
| Ok(axum::http::StatusCode::OK) | ||
| } | ||
|
|
||
| /// Status handler that returns the user's authentication status as a `bool`. |
There was a problem hiding this comment.
style: this docstring mostly describes the internal implementation (reading the token, decoding claims, checking the database). Readers can get those details from the code. For API documentation it's more useful to describe the observable behaviour and response contract, eg "this endpoint returns whether the current user identified by their access_token is logged in, with a JSON true or false response body."
| auth_core::database::token_exists_in_database(&state.database_connection, &claims.subject) | ||
| .await?; | ||
|
|
||
| Ok((cache_headers, Json(is_authenticated))) |
There was a problem hiding this comment.
would it be better to return a JSON object? That makes it self-documenting and makes it easier to extend the "status" endpoint in future if we need it.
eg return
{"user_is_authenticated": true}
or similar
| } | ||
| }; | ||
|
|
||
| const AuthStatusIndicator = ({ |
There was a problem hiding this comment.
I think this is mixing two separate concerns:
(1) determining whether the user is authenticated
(2) displaying authentication status visually
I think that the goal is to provide react tooling that could be provided via a shared library that allows consuming applications to query authentication state and trigger the login flow if needed.
This component currently makes a lot of UI decisions on behalf of consumers (indicator, colours, text, tooltip, button behaviour etc), which limits how other teams can integrate it into their applications.
I'd suggest decoupling determining the users authenticated state, from a visual component that renders the state. Consuming applications could then decide how and when to present that information to users.
We could still provide an AuthStatusIndicator component as a convenience wrapper on top of that, but I think the authentication state/query mechanism should exist independently of any particular UI.
2 participants
frontend and backend of the feature