feat: flatten (de)serialization of custom user claims #1159

jorgehermo9 · 2025-01-08T23:20:29Z

Closes #1115

Left some doubts as // TODO: in the code, please take a look into that comments when reviewing.

CC @Django-Fakkeldij

src/auth/jwt.rs

src/auth/snapshots/loco_rs__auth__jwt__tests__valid token and custom boolean claims.snap

examples/demo/src/models/users.rs

src/auth/jwt.rs

Django-Fakkeldij · 2025-01-11T18:10:03Z

Think this looks great! Thank you for taking the time to fix this issue ❤️

jorgehermo9 · 2025-01-12T16:00:30Z

Fixed failed CI

Co-authored-by: Jorge Hermo <[email protected]>

kaplanelad

Thanks for opening this PR.

src/auth/jwt.rs

starters/rest-api/src/models/users.rs

jorgehermo9 · 2025-01-18T08:51:36Z

Hi @kaplanelad, thank you for your review. Addressed the changes you suggested.

kaplanelad · 2025-01-22T18:10:31Z

@jorgehermo9 can you fix the CI, please?

jorgehermo9 · 2025-01-23T11:49:44Z

Hi @kaplanelad . The loco-gen-deploy action is failing (https://github.com/loco-rs/loco/actions/runs/12927511346/job/36052787934?pr=1159) because the app generated tries to use the loco version 0.14.0 instead of the local one. As we changed the public API of the JWT module (and updated the template in loco-new in this PR), the app generated should use the local loco crate instead of pulling 0.14.0 from the registry, where the JWT API is not updated with these changes.

To reproduce, in the root directory of this branch, run

cargo install --path ./loco-new
loco new -n myapp --db sqlite --bg async --assets serverside -a

(those are the commands being ran in https://github.com/loco-rs/loco/actions/runs/12927511346/job/36052787934?pr=1159)

and in myapp/Cargo.toml you can see this

In order to fix that, we should link to the local loco dependency, using the LOCO_DEV_MODE_PATH env variable as other CI workflows do

loco/.github/workflows/loco-gen-ci.yml

Line 73 in 1787a76

LOCO_DEV_MODE_PATH: ${{ github.workspace }}

with the following command in local development (being at the repo root directory) LOCO_DEV_MODE_PATH=.. loco new -n myapp --db sqlite --bg async --assets serverside -a the generated Cargo.toml file looks like this

and the app can be compiled succesfully.

I updated the CI workflow in cac9e5c to address this

jorgehermo9 · 2025-01-23T12:34:16Z

Now it is failing because the local loco-rs crate is not copied in the dockerfile https://github.com/loco-rs/loco/actions/runs/12928528426/job/36055996790?pr=1159

How should we proceed here? If the dockerfile build should pull the dependency from crates.io, we have to publish a new loco-rs version containing the public api changes.

The other option is to copy the local loco dependency into the docker build context. Tried that in 18de238 but I don't know if it's the best workaround... any suggestions?

jorgehermo9 · 2025-01-23T13:03:43Z

.github/workflows/loco-gen-deploy.yml

-      - name:
-        run: cargo loco generate deployment --kind docker && docker build -t demo .
-        working-directory: ./myapp
+      - name: generate deployment


we have to split this in two steps (generate deployment and build deployment) because cargo loco generate deployment --kind docker if we have the local loco dependency in the path

The docker build works because once we are copying the files in the container, we move the loco directory to ${{github.workspace}} from /tmp/myapp/loco so the app can compile with cargo build --release

(see the dockerfile template)

jorgehermo9 · 2025-01-23T13:04:16Z

loco-gen/src/templates/deployment/docker/docker.t

@@ -7,7 +7,10 @@ FROM rust:1.83.0-slim as builder
 WORKDIR /usr/src/

 COPY . .
-
+{% if loco_dev_mode_path -%}


I had to use this in order to build from a local loco dependency instead of pulling the crate from crates.io

jorgehermo9 · 2025-01-23T13:39:29Z

Fixed CI.

The main problem was that the loco-gen-deploy action was not able to build from a local loco-rs dependency as it was pulling the crate from crates.io. In order to test this PR, a local loco-rs dependency is needed instead, and that dependency must be copied to the docker build context.

0897e27 and 18de238 addressed this limitation

jorgehermo9 · 2025-01-24T12:39:35Z

loco-gen/tests/templates/snapshots/generate[docker_file_[404_html]_[None]]@deployment.snap

@@ -7,7 +7,8 @@ FROM rust:1.83.0-slim as builder
 WORKDIR /usr/src/

 COPY . .
-
+#  The `loco` root folder should be moved to this dockerfile path so the context can copy it to the image
+RUN mkdir -p /home/runner/work/loco/loco && mv loco/* /home/runner/work/loco/loco && rm -rf loco


Now this template uses the LOCO_DEV_MODE_PATH and as the loco-gen-ci action sets that env var https://github.com/loco-rs/loco/blob/master/.github/workflows/loco-gen-ci.yml#L73, these snapshots were generated with LOCO_DEV_MODE_PATH=/home/runner/work/loco/loco cargo insta test --review --all-features in local

kaplanelad · 2025-01-26T08:24:26Z

@jorgehermo9 There are too many changes in this PR that are unrelated to the feature being implemented.
If there’s an issue with the CI, please let us know, and we’ll investigate it.

Kindly revert the unrelated changes so we can focus on the scope of this PR. Once that’s done, I’ll review the problem.

Thanks!

Co-authored-by: Elad Kaplan <[email protected]>

jorgehermo9 · 2025-01-26T10:25:10Z

Hi @kaplanelad

As you said

@jorgehermo9 can you fix the CI, please?

I debugged what was happening (loco-gen-ci was pulling the loco-rs crate from crates.io instead of using the local modified dependency) and addressed the issue so the CI passed.

Reverted the changes. You can find what I did in commits cac9e5c, 0897e27, 18de238 and f6a03a8. After those commits, the CI passed successfully.

jorgehermo9 added 5 commits January 6, 2025 20:15

feat: initial implementation

b3bc611

test: implement more jwt tests

a4bddb6

test: reduce code duplication with rstest

a96dd62

test: rename variables

97aa482

Merge branch 'loco-rs:master' into master

3767c4d