dxps / fullstack-rust-axum-dioxus-rwa Goto Github PK

AS-IS
Currently, the authorization is all or nothing: any authenticated user can update or delete any article (besides creating one, of course).

TO-BE
Only the user that is the author of (aka own) an article can update or delete it.

The routes within the SPA are working. For example: navigating from HomePage (/) to SignIn (/signin) works fine.

But if you go directly to http://localhost:8080/signin you get a 404.

Use the approach that exists in get_user_profile handler. This means:

• return Json(json!({ "profile": profile })))
• and thus UserProfileDTO is one single struct
  (instead of two structs, like the case of UserOutDTO and its UserOutDTOUserAttrs child).

Some parts are duplicated, thus need to be extracted into a reusable function:

1. The INSERT INTO tags_articles statements (done in both add and update methods).
2. Rendering the AppError based on Error or DatabaseError.

Currently, a i64 (the internal id, database generated) is being exposed in the token.
For security purposes, a globally unique must be exposed to the outside world.

The current implementation deletes only from articles table.
If an article has tags, then it obviously fails with:

update or delete on table "articles" violates foreign key constraint "fk_article_id" on table "tags_articles"

follow_user and create_article handlers are using user_claims: Claims as method arguments.
But they are using only user_claims.sub part which is actually the UserId.
Therefore, it's more clear and efficient to use user_id: UserId extractor.

And update_article and delete_article handlers are not using any of these, so they behave as public (not protected as they should be) endpoints.

TBD if this is an issue with the updated - Dioxus 0.3 - version or it is a bug in the front-end code.
Currently, when going to any path in the browser - such as /sign-in - it shows the homepage.

Currently, src/repos/users_repo.rs file contains explicit implementations (impl FromRow ... for ...) for User, UserId and UserEntry.

Initial reasoning was to try to keep the domain model as clean as possible.
However, just adding the sqlx::FromRow into the existing #[derive(...) attribute shouldn't hurt, but eliminate those implementations:

Hi, great example project - thanks!

I'm not sure if the specc requires swagger/OpenAPI docs, but I think it would be a great addition in order to match what someone would expect from a production app.

By default, in cases where the request body can't be deserialized as JSON, the response code is 422 (Unprocessable Entity), but the body is a text (explicitly declared also by the response's content-type header with value text/plain; charset=utf-8:

Failed to deserialize the JSON body into the target type: missing field `password` at line 5 column 3

A proper response of such an HTTP API would be a JSON with an error attribute, at minimum.

While the server can gracefully shutdown if it receives the expected signal, cargo-watch does not have an option to specify which signal to send to the running (server) process, nor wait for it to shutdown (see this).

The alternative is to use watchexec.

Trying to create an article with the same slug it returns an HTTP RC 500.

And in the log it throws this:

2023-01-29T20:59:05.718215Z DEBUG backend::app_errors: From sqlx err: Database(PgDatabaseError { 
severity: Error, code: "23505", 
message: "duplicate key value violates unique constraint \"unique_slug\"", 
detail: Some("Key (slug)=(how-to-train-your-dragon) already exists."), 
hint: None, position: None, where: None, schema: Some("public"), 
table: Some("articles"), column: None, data_type: None, 
constraint: Some("unique_slug"), 
file: Some("nbtinsert.c"), line: Some(663), routine: Some("_bt_check_unique") })

It should return a 422 (Unprocessable Entity).

As title mentioned, the server should be able to gracefully shutdown.
And Axum supports it.

POST {{APIURL}}/profiles/jane/follow returns HTTP RC 500, instead of a 404.

When trying to run example (git clone..; ./run_dev.sh) I'm getting following error:

[INFO] 🚅 Running build command...
[ERROR] 🚫 Serve startup failed: error[E0107]: this struct takes 2 generic arguments but 1 generic argument was supplied
   --> /home/spock/.cargo/registry/src/github.com-1ecc6299db9ec823/dioxus-core-0.2.1/src/virtual_dom.rs:109:19
    |
109 |     dirty_scopes: IndexSet<ScopeId>,
    |                   ^^^^^^^^ ------- supplied 1 generic argument
    |                   |
    |                   expected 2 generic arguments
    |
note: struct defined here, with 2 generic parameters: `T`, `S`
   --> /home/spock/.cargo/registry/src/github.com-1ecc6299db9ec823/indexmap-1.9.3/src/set.rs:67:12
    |
67  | pub struct IndexSet<T, S> {
    |            ^^^^^^^^ -  -
help: add missing generic argument
    |
109 |     dirty_scopes: IndexSet<ScopeId, S>,
    |                                   +++```

Looks like libraries used by project has some issues.

In AppError, AuthInvalidTokenErr(String) is kinda artificial and it should be covered by the more generic AuthUnauthorized.

AS-IS
Currently, any user can follow any user, including himself (which it doesn't make sense, ofc).

TO-BE
A user can follow any other user, except of himself.

follow_user must return follower's Profile, not followed user's Profile

This is helpful for cases like #5 where other starting points (such as the user's email, not user's id) are needed.

Currently, the front-end is done using version 0.3 of Dioxus.

The initial try to upgrade to version 0.4 showed that it's not that easy breezy.
Since version 0.5 introduces signals and thus provides a nicer API, I'd skip the upgrade to 0.4.

This issue is mainly a reminder to do this when Dioxus ver. 0.5 will be released.

Additional elements must be exposed as configuration values.

This includes:

1. JWT lifetime
2. JWT signing secret

Currently, the response body is fine, but it throws HTTP status code 500.