Right now RustTune has no concept of a logged-in user. Features like favorites (#17), recently played songs (#15), and playlists (#18) are all being built, but there's no user identity layer to tie that data to a specific person persistently. Without this, favorites and playlists would either reset on refresh or be shared across all users — which breaks the whole personalization side of the app.
Implement a full authentication system on the backend with the following endpoints:
- POST /api/auth/register — accept username + password, store with hashed password
- POST /api/auth/login — validate credentials, return a signed JWT
- GET /api/auth/me — return current user info from token
Also add Actix-Web middleware to extract and validate the JWT on protected routes (favorites, playlists, queue), with token expiry and refresh token support.
This involves backend security design, middleware architecture, database schema changes (adding a users table), and directly unblocks multiple other open issues (#17, #18, #15, #20) that currently have no user context to anchor data to. It's foundational infrastructure for the entire personalization layer of the app.
Additional context
Checked all 31 open issues and the current Cargo.toml — no auth-related work exists
anywhere in the codebase yet.
Hi @KDeekshita ,
I would like to work on this issue under Gssoc. Please assign it to me!
Right now RustTune has no concept of a logged-in user. Features like favorites (#17), recently played songs (#15), and playlists (#18) are all being built, but there's no user identity layer to tie that data to a specific person persistently. Without this, favorites and playlists would either reset on refresh or be shared across all users — which breaks the whole personalization side of the app.
Implement a full authentication system on the backend with the following endpoints:
Also add Actix-Web middleware to extract and validate the JWT on protected routes (favorites, playlists, queue), with token expiry and refresh token support.
This involves backend security design, middleware architecture, database schema changes (adding a users table), and directly unblocks multiple other open issues (#17, #18, #15, #20) that currently have no user context to anchor data to. It's foundational infrastructure for the entire personalization layer of the app.
Additional context
Checked all 31 open issues and the current Cargo.toml — no auth-related work exists
anywhere in the codebase yet.
Hi @KDeekshita ,
I would like to work on this issue under Gssoc. Please assign it to me!