Feature: User auth #15

Merged
scott merged 29 commits from scott/kalkutago:feature/user-auth into main 2023-08-27 08:00:57 -04:00
Owner
  • Add user model
  • Add auth guard
  • Add association between users and tracks
  • Make the API differentiate tracks by user

Resolves #2

- [x] Add user model - [x] Add auth guard - [x] Add association between users and tracks - [x] Make the API differentiate tracks by user Resolves #2
scott self-assigned this 2023-06-26 11:04:04 -04:00
scott added 3 commits 2023-06-26 11:04:04 -04:00
scott added 3 commits 2023-06-26 11:58:16 -04:00
scott added 1 commit 2023-06-26 15:59:59 -04:00
scott force-pushed feature/user-auth from 3ce19da675 to e25301655b 2023-06-26 16:02:01 -04:00 Compare
scott force-pushed feature/user-auth from 396ed28079 to a390f79a75 2023-08-26 06:12:12 -04:00 Compare
scott added 12 commits 2023-08-26 06:15:16 -04:00
scott added 6 commits 2023-08-26 06:18:09 -04:00
scott changed title from WIP: Feature: User auth to Feature: User auth 2023-08-26 06:18:37 -04:00
scott added 3 commits 2023-08-26 06:54:51 -04:00
scott added 1 commit 2023-08-26 07:03:29 -04:00
todtb reviewed 2023-08-26 08:29:57 -04:00
@ -2,6 +2,8 @@ import { reactive } from "vue"
import { Track } from "./track"
Member

Have you tried out vuex or the newer pinia yet?

Have you tried out vuex or the newer pinia yet?
Author
Owner

It's been a while since I looked into it, but I think I remember reading something in their docs which suggested that they might be overkill for this situation.

It's been a while since I looked into it, but I think I remember reading something in their docs which suggested that they might be overkill for this situation.
@ -81,3 +103,2 @@
this.state = State.Fetched
},
}
async taskCompleted(track: Track, date: Date): Promise<Tick> {
Member

For the API calls, is there a reason for them to be in state?

For the API calls, is there a reason for them to be in `state`?
Author
Owner

From the Vue docs:

This also means any component importing store can mutate it however they want. While this works in simple cases, global state that can be arbitrarily mutated by any component is not going to be very maintainable in the long run. To ensure the state-mutating logic is centralized like the state itself, it is recommended to define methods on the store with names that express the intention of the actions.

From [the Vue docs](https://vuejs.org/guide/scaling-up/state-management.html#simple-state-management-with-reactivity-api): > This also means any component importing store can mutate it however they want. While this works in simple cases, global state that can be arbitrarily mutated by any component is not going to be very maintainable in the long run. To ensure the state-mutating logic is centralized like the state itself, it is recommended to define methods on the store with names that express the intention of the actions.
Member

Yeah, but do these mutate state? I thought they were just making the request and returning the parsed body?

Yeah, but do these mutate state? I thought they were just making the request and returning the parsed body?
Author
Owner

Ah, you raise a good point there. It was originally intended to, but then I changed it so that only the events update the state. Thanks for that.

Ah, you raise a good point there. It was originally intended to, but then I changed it so that only the events update the state. Thanks for that.
@ -0,0 +13,4 @@
.if_not_exists()
.col(
ColumnDef::new(Users::Id)
.integer()
Member

Does sea_orm support UUIDs?

Does sea_orm support UUIDs?
Author
Owner

It seems to support a UUID column type, but I don't see documentation for it, or for using it as a primary key. Is that important?

It seems to support a UUID column type, but I don't see documentation for it, or for using it as a primary key. Is that important?
Member

For this, probably not. However UUIDs can be nice for PKs on publicly facing resources as you cannot crawl them (ie /user/3 suggests /user/4 exists). Slugs can be used to keep the url tidy.

For this, probably not. However UUIDs can be nice for PKs on publicly facing resources as you cannot crawl them (ie `/user/3` suggests `/user/4` exists). Slugs can be used to keep the url tidy.
Author
Owner

That makes sense. Though I think I might do /user/{name} if we add public profile pages (and /me for the logged in user)

That makes sense. Though I think I might do `/user/{name}` if we add public profile pages (and `/me` for the logged in user)
@ -0,0 +11,4 @@
async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
manager
.create_table(
Table::create()
Member

Interesting DSL here...

Interesting DSL here...
Author
Owner

These are generated by the sea-orm CLI 🤷

These are generated by the sea-orm CLI 🤷
todtb approved these changes 2023-08-26 10:04:29 -04:00
scott added 2 commits 2023-08-26 11:05:23 -04:00
scott requested review from todtb 2023-08-26 11:05:48 -04:00
scott added 1 commit 2023-08-26 11:18:26 -04:00
scott added 1 commit 2023-08-26 11:21:42 -04:00
scott reviewed 2023-08-26 14:48:42 -04:00
@ -21,0 +32,4 @@
track_id: i32,
user: &users::Model,
) -> Result<Json<tracks::Model>, Either<Status, api::ErrorResponder>> {
if let Some(Some(user)) = user
Author
Owner

rename user -> track in assignment here

rename `user` -> `track` in assignment here
scott marked this conversation as resolved
@ -96,0 +94,4 @@
let receiver_count = tx.receiver_count();
if receiver_count > 0 {
trace!(receiver_count = receiver_count, update = as_serde!(self); "sending update");
let count = tx.send(self.clone())?;
Author
Owner

use count here

use count here
scott marked this conversation as resolved
scott added 2 commits 2023-08-26 14:51:21 -04:00
scott merged commit 0051d87d47 into main 2023-08-27 08:00:57 -04:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TWS/kalkutago#15
No description provided.