SquidSpirit
9c88b4bb55
### Description
This PR introduces the functionality to persist user information in the database. When a user logs in via OIDC for the first time, a new user record is created. Subsequent logins will retrieve the existing user data from the database.
This change ensures that users have a persistent identity within our system, identified by their unique combination of OIDC issuer and subject ID.
#### Key Changes
* **User Persistence Logic**:
* In `ExchangeAuthCodeUseCase`, after successfully exchanging the authorization code, the logic now checks if the user exists in our database using their `issuer` and `source_id`.
* If the user is not found (`AuthError::UserNotFound`), a new record is created in the `user` table.
* The `User` entity returned by the use case now contains the internal database `id`.
* **Database Integration in Auth Feature**:
* Introduced a new `UserDbService` trait and its `sqlx`-based implementation, `UserDbServiceImpl`, to handle database operations for users.
* The `AuthRepository` is extended to include methods for querying (`get_user_by_source_id`) and saving (`save_user`) users, delegating the calls to the new `UserDbService`.
* The dependency injection container in `server/src/container.rs` has been updated to provide the `UserDbServiceImpl` to the `AuthRepositoryImpl`.
* **Domain and Data Model Updates**:
* The `User` domain entity now includes `id` (the database primary key) and `issuer` (from OIDC claims) to uniquely identify a user across different identity providers.
* The `UserResponseDto` now exposes the internal `id` instead of the `source_id`.
* **Session Management**:
* The user's session now stores the database `user_id` (`i32`) instead of the entire user object. This is more efficient and secure.
* Session keys have been centralized into a `constants.rs` file for better maintainability.
#### Database Changes
* A new database migration has been added to create the `user` table.
* The table includes columns for `id`, `issuer`, `source_id`, `displayed_name`, and `email`.
* A **`UNIQUE` index** has been created on `(source_id, issuer)` to guarantee that each user from a specific identity provider is stored only once.
#### Refactoring
* Minor refactoring in the `image` feature to change `id: Option<i32>` to `id: i32` for consistency with the new `User` entity model.
### Package Changes
_No response_
### Screenshots
_No response_
### Reference
Resolves #94
### Checklist
- [x] A milestone is set
- [x] The related issuse has been linked to this branch
Reviewed-on: #96
Co-authored-by: SquidSpirit <squid@squidspirit.com>
Co-committed-by: SquidSpirit <squid@squidspirit.com>
Blog
Development
- Frontend: SvelteKit with Tailwind CSS
- Backend: Rust actix-web
Despite SvelteKit being a full-stack framework, I still decided to adopt a separate front-end and back-end architecture for this blog project. I believe that this separation makes the project cleaner, reduces coupling, and aligns with modern development practices. Furthermore, I wanted to practice developing a purely back-end API.
As for the more detailed development approach, I plan to use Clean Architecture for the overall structure. Of course, such a small project may not necessarily require such complex design patterns, but I want to give myself an opportunity to practice them.
These will allow me to become more proficient in these modern development practices and leave a lot of flexibility and room for adjustments in the future.
For more information about the development process, you can check out the project board. As for the details of the architecture and convention, you can find them in the wiki.
License
This project uses a combination of the MIT License and a custom license. Based on the MIT License, anyone is permitted to use the code. However, before deploying the code, they must first replace any information belonging to "me" or any content that could identify "me," such as logos, names, and "about me" sections.