Merge branch 'main' into dev

This commit is contained in:
Nuh
2024-12-18 11:10:39 +03:00
committed by nazeh
3 changed files with 13 additions and 12 deletions

View File

@@ -30,10 +30,10 @@ COPY Cargo.toml Cargo.lock ./
COPY . .
# Build the project in release mode for the MUSL target
RUN cargo build --release --bin pubky_homeserver --target x86_64-unknown-linux-musl
RUN cargo build --release --bin pubky-homeserver --target x86_64-unknown-linux-musl
# Strip the binary to reduce size
RUN strip target/x86_64-unknown-linux-musl/release/pubky_homeserver
RUN strip target/x86_64-unknown-linux-musl/release/pubky-homeserver
# ========================
# Runtime Stage
@@ -44,7 +44,7 @@ FROM alpine:3.20
RUN apk add --no-cache ca-certificates
# Copy the compiled binary from the builder stage
COPY --from=builder /usr/src/app/target/x86_64-unknown-linux-musl/release/pubky_homeserver /usr/local/bin/homeserver
COPY --from=builder /usr/src/app/target/x86_64-unknown-linux-musl/release/pubky-homeserver /usr/local/bin/homeserver
# Set the working directory
WORKDIR /usr/local/bin

View File

@@ -62,17 +62,18 @@ pubkyauth:///
&secret=mAa8kGmlrynGzQLteDVW6-WeUGnfvHTpEmbNerbWfPI
```
and finally show that URL as a QR code to the user.
4. The `Authenticator` app scans that QR code, parse the URL, and show a consent form for the user..
5. The user decides whether or not to grant these capabilities to the `3rd Party App`.
6. If the user approves, the `Authenticator` then uses their Keypair, to sign an [AuthToken](#authtoken), then encrypt that token with the `client_secret`, then calculate the `channel_id` by hashing that secret, and send that encrypted token to the callback url, which is the `relay` + `channel_id`.
7. `HTTP Relay` forwards the encrypted AuthToken to the `3rd Party App` frontend.
8. And confirms the delivery with the `Authenticator`
9. `3rd Party App` decrypts the AuthToken using its `client_secret`, read the `pubky` in it, and send it to their `homeserver` to obtain a session.
10. `Homeserver` verifies the session and stores the corresponding `capabilities`.
11. `Homeserver` returns a session Id to the frontend to use in subsequent requests.
12. `3rd Party App` uses the session Id to access some resource at the Homeserver.
13. `Homeserver` checks the session capabilities to see if it is allowed to access that resource.
14. `Homeserver` responds to the `3rd Party App` with the resource.
7. If the user approves, the `Authenticator` then uses their Keypair, to sign an [AuthToken](#authtoken), then encrypt that token with the `client_secret`, then calculate the `channel_id` by hashing that secret, and send that encrypted token to the callback url, which is the `relay` + `channel_id`.
8. `HTTP Relay` forwards the encrypted AuthToken to the `3rd Party App` frontend.
9. And confirms the delivery with the `Authenticator`
10. `3rd Party App` decrypts the AuthToken using its `client_secret`, read the `pubky` in it, and send it to their `homeserver` to obtain a session.
11. `Homeserver` verifies the session and stores the corresponding `capabilities`.
12. `Homeserver` returns a session Id to the frontend to use in subsequent requests.
13. `3rd Party App` uses the session Id to access some resource at the Homeserver.
14. `Homeserver` checks the session capabilities to see if it is allowed to access that resource.
15. `Homeserver` responds to the `3rd Party App` with the resource.
## AuthToken encoding
```abnf