unified validation logic, specified whether the "x" tag is required or

optional in the bud-11 table
This commit is contained in:
pippellia-btc
2026-02-25 15:44:17 +01:00
parent 4d2cc07a01
commit f82748e03b
+20 -21
View File
@@ -55,33 +55,32 @@ Example HTTP Authorization Header:
Authorization: Nostr ewogICJpZCI6ICI3YTE3MzVjMzg1MmNmM2YzNzRlZGFlNGIyYWYyZWUxOGU3NTBlNmRlYzU4M2UxOWM0Nzk1ZDNiMTc5YWY2ZDE3IiwKICAia2luZCI6IDI0MjQyLAogICJwdWJrZXkiOiAiNzliZTY2N2VmOWRjYmJhYzU1YTA2Mjk1Y2U4NzBiMDcwMjliZmNkYjJkY2UyOGQ5NTlmMjgxNWIxNmY4MTc5OCIsCiAgImNyZWF0ZWRfYXQiOiAxNzcyMDE5MDQ0LAogICJ0YWdzIjogWwogICAgWyJ0IiwidXBsb2FkIl0sCiAgICBbImV4cGlyYXRpb24iLCIxNzA4ODU4NjgwIl0sCiAgICAvLyBBdXRob3JpemF0aW9uIHRva2VuIE1BWSBoYXZlIG11bHRpcGxlICJ4IiB0YWdzCiAgICBbIngiLCJiMTY3NDE5MWE4OGVjNWNkZDczM2U0MjQwYTgxODAzMTA1ZGM0MTJkNmM2NzA4ZDUzYWI5NGZjMjQ4ZjRmNTUzIl0sCiAgXSwKICAiY29udGVudCI6ICIiLAogICJzaWciOiAiNGI1N2MyMmIxNzk3YjEwOTUzMGZmZTVkMDRjYWJhYzQ2OGIxYTU5NDI4NzNhNTE0MTMzNGVjYmM3NzY5NGZjOTY4YTFiOTQxOTc5YmExMzYwMmZjZWIxZGFkODAxNGFiNjQ2OWM2YWU5Y2VmMGI1NjY4Y2MyM2FkMTQ0OWUxMDMiCn0
```
## Base validation
## Validation
Servers must perform the following checks in order to validate the authorization token
To validate an authorization token, a server MUST perform the following checks:
1. The `kind` must be `24242`
2. `created_at` must be in the past
3. The `expiration` tag must be set to a Unix timestamp in the future
4. The `t` tag must have a verb matching the intended action of the endpoint
5. If `server` tags are present, the server MUST verify that its domain name is present in at least one `server` tag.
1. The event `kind` MUST be `24242`.
2. The `created_at` timestamp MUST be in the past.
3. An `expiration` tag MUST be present and set to a Unix timestamp in the future.
4. The `t` tag MUST contain a verb matching the intended action of the endpoint.
5. If one or more `server` tags are present, the server MUST verify that its domain name appears in at least one `server` tag.
6. If the endpoint requires `x` tags, the server MUST verify that at least one `x` tag matches the blob hash implied by the endpoint.
## Endpoint Authorization Requirements
The following table defines, for each endpoint, the required `t` tag action and the implied blob hash (if any). The token MUST include at least one `x` tag whose value matches the implied blob hash.
If an endpoint has an implied blob hash and it cannot be determined (e.g. missing `X-SHA-256` header), authorization MUST fail.
The table below defines, for each endpoint, the required `t` tag action, the implied blob hash (if any), and whether at least one matching `x` tag is required.
| Endpoint | Action | Implied blob hash |
| -------------------- | -------- | ------------------------------------------ |
| `GET /<sha256>` | `get` | The `<sha256>` in the URL |
| `HEAD /<sha256>` | `get` | The `<sha256>` in the URL |
| `PUT /upload` | `upload` | `X-SHA-256` request header |
| `HEAD /upload` | `upload` | `X-SHA-256` request header |
| `DELETE /<sha256>` | `delete` | The `<sha256>` in the URL |
| `GET /list/<pubkey>` | `list` | — |
| `PUT /mirror` | `upload` | sha256 of the mirrored blob |
| `PUT /media` | `media` | `X-SHA-256` request header |
| `HEAD /media` | `media` | `X-SHA-256` request header |
| Endpoint | Required `t` | Implied Blob Hash | `x` Tag Requirement |
|----------------------|--------------|-------------------------------|---------------------|
| `GET /<sha256>` | `get` | `<sha256>` from the URL | optional |
| `HEAD /<sha256>` | `get` | `<sha256>` from the URL | optional |
| `PUT /upload` | `upload` | `X-SHA-256` request header | required |
| `HEAD /upload` | `upload` | `X-SHA-256` request header | required |
| `DELETE /<sha256>` | `delete` | `<sha256>` from the URL | required |
| `GET /list/<pubkey>` | `list` | — | not applicable |
| `PUT /mirror` | `upload` | SHA-256 of the mirrored blob | required |
| `PUT /media` | `media` | `X-SHA-256` request header | required |
| `HEAD /media` | `media` | `X-SHA-256` request header | required |
## Security Considerations