Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Freeway can learn about space/content/serve/* delegations #160

Closed
Tracked by #135
hannahhoward opened this issue Oct 9, 2024 · 1 comment
Closed
Tracked by #135

Freeway can learn about space/content/serve/* delegations #160

hannahhoward opened this issue Oct 9, 2024 · 1 comment
Assignees
@fforbeck

Comments

@hannahhoward
Copy link
Member

hannahhoward commented Oct 9, 2024 •
edited by fforbeck
Loading

Acceptance Criteria

  1. There is an API/protocol for sending a space/content/serve/* delegation to Freeway.
  2. After sending one, Freeway uses it to authorize serving requests.

Implementation Notes

  • This should be a new DB that belongs to Freeway itself.
  • It likely should be either KV or D1, possibly backed by R2 to store the full delegations if necessary.
  • See diagram for a high-level view.
@hannahhoward hannahhoward converted this from a draft issue Oct 9, 2024
@Peeja Peeja changed the title Way to index space/content/serve delegations by token Index space/content/serve delegations by audience & subject Oct 21, 2024
@Peeja Peeja changed the title Index space/content/serve delegations by audience & subject Freeway can learn about space/content/serve delegations Nov 29, 2024
@Peeja Peeja changed the title Freeway can learn about space/content/serve delegations Freeway can learn about space/content/serve/* delegations Nov 29, 2024
@Peeja Peeja assigned fforbeck and unassigned Peeja Nov 29, 2024
This was referenced Nov 29, 2024
Closed
Open
Closed
Merged
Merged
travis pushed a commit to storacha/w3up that referenced this issue Dec 4, 2024
@fforbeck
feat!: content serve authorization (#1590)
8b553a5 
### Context
To enable a gateway to serve content from a specific space, we must
ensure that the space owner delegates the `space/content/serve/*`
capability to the Gateway. This delegation allows the Gateway to serve
content and log egress events appropriately.

I created a new function `authorizeContentServe` for this implementation
and included it in the `createSpace` flow. This is a breaking change
because now the user is forced to provide the DIDs of the Content Serve
services, and the connection, or skip the authorization flow.

Additionally, with the `authorizeContentServe` function, we can
implement a feature in the Console App that enables users to explicitly
authorize the Freeway Gateway to serve content from existing/legacy
spaces.

### Main Changes
- **New Functionality:** Added a new function, `authorizeContentServe`,
in the `w3up-client` module to facilitate the delegation process.
Integrated it with the `createdSpace` flow.
- **Testing:** Introduced test cases to verify the authorization of
specified gateways.
- **Fixes:** Resolved issues with previously broken test cases (Egress
Record).

### Related Issues
- storacha/project-tracking#158
- storacha/project-tracking#160
This was referenced Dec 9, 2024
Closed
Closed
Closed
Merged
fforbeck added a commit to storacha/freeway that referenced this issue Dec 11, 2024
@fforbeck
feat: ucan invocation handler (#133)
b199bfa 
### Context
To enable the gateway to serve content from a specific space, the space
owner must delegate the `space/content/serve/*` capability to the
Gateway. This delegation ensures the Gateway has the authority to serve
the content and log egress events accurately.

This PR introduces a new handler to process POST requests to the
server's root path. The handler acts as a UCAN Invocation handler,
processing `access/delegate` invocations and extracting relevant
delegation proofs. If a delegation proof is valid, it is stored in
Cloudflare KV, allowing other handlers to retrieve and verify the proof
to determine whether content should be served and egress logged.

Note: It doesn't cover the token verification.

### Main Changes
#### **New Functionality**
- Added `withUcanInvocationHandler.js` to process `access/delegate`
invocations:
  - Validates delegation proofs.
- Stores valid proofs in a Cloudflare KV namespace dedicated to `content
serve` delegations.
- Feature Flag: `FF_DELEGATIONS_STORAGE_ENABLED` if enabled, the new
`withDelegationsStorage.js` handler will be used to find delegations in
KV, and the existing `withDelegationsStubs.js` will be disabled.

### Related Issues
- storacha/project-tracking#158
- storacha/project-tracking#160
@fforbeck
Copy link
Member

This has been implemented and merged into the main branch, so we can close it now. Further testing will be tracked in issue #159.

@github-project-automation github-project-automation bot moved this from In Progress to Done in Storacha Project Planning Dec 11, 2024
fforbeck added a commit to storacha/upload-service that referenced this issue Dec 11, 2024
@fforbeck
feat!: content serve authorization (storacha#1590)
0d4513d 
To enable a gateway to serve content from a specific space, we must
ensure that the space owner delegates the `space/content/serve/*`
capability to the Gateway. This delegation allows the Gateway to serve
content and log egress events appropriately.

I created a new function `authorizeContentServe` for this implementation
and included it in the `createSpace` flow. This is a breaking change
because now the user is forced to provide the DIDs of the Content Serve
services, and the connection, or skip the authorization flow.

Additionally, with the `authorizeContentServe` function, we can
implement a feature in the Console App that enables users to explicitly
authorize the Freeway Gateway to serve content from existing/legacy
spaces.

- **New Functionality:** Added a new function, `authorizeContentServe`,
in the `w3up-client` module to facilitate the delegation process.
Integrated it with the `createdSpace` flow.
- **Testing:** Introduced test cases to verify the authorization of
specified gateways.
- **Fixes:** Resolved issues with previously broken test cases (Egress
Record).

- storacha/project-tracking#158
- storacha/project-tracking#160
@fforbeck fforbeck mentioned this issue Dec 11, 2024
Merged
fforbeck added a commit to storacha/upload-service that referenced this issue Dec 11, 2024
@fforbeck
feat!: content serve authorization (storacha#1590)
6f42347 
To enable a gateway to serve content from a specific space, we must
ensure that the space owner delegates the `space/content/serve/*`
capability to the Gateway. This delegation allows the Gateway to serve
content and log egress events appropriately.

I created a new function `authorizeContentServe` for this implementation
and included it in the `createSpace` flow. This is a breaking change
because now the user is forced to provide the DIDs of the Content Serve
services, and the connection, or skip the authorization flow.

Additionally, with the `authorizeContentServe` function, we can
implement a feature in the Console App that enables users to explicitly
authorize the Freeway Gateway to serve content from existing/legacy
spaces.

- **New Functionality:** Added a new function, `authorizeContentServe`,
in the `w3up-client` module to facilitate the delegation process.
Integrated it with the `createdSpace` flow.
- **Testing:** Introduced test cases to verify the authorization of
specified gateways.
- **Fixes:** Resolved issues with previously broken test cases (Egress
Record).

- storacha/project-tracking#158
- storacha/project-tracking#160
@fforbeck fforbeck mentioned this issue Dec 13, 2024
Merged
fforbeck added a commit to storacha/upload-service that referenced this issue Dec 19, 2024
@fforbeck
feat: content serve authorization (storacha#1590) + set default gatew…
6cbb202 
…ay (#99)

To enable a gateway to serve content from a specific space, we must
ensure that the space owner delegates the `space/content/serve/*`
capability to the Gateway. This delegation allows the Gateway to serve
content and log egress events appropriately.

I created a new function `authorizeContentServe` for this implementation
and included it in the `createSpace` flow. This is a breaking change
because now the user is forced to provide the DIDs of the Content Serve
services, and the connection, or skip the authorization flow.

Additionally, with the `authorizeContentServe` function, we can
implement a feature in the Console App that enables users to explicitly
authorize the Freeway Gateway to serve content from existing/legacy
spaces.

- **New Functionality:** 
- Added a new function, `authorizeContentServe`, in the `w3up-client`
module to facilitate the delegation process. Integrated it with the
`createdSpace` flow.
- It also sets the Storacha Gateway as the default content server
service in case the user doesn't provide any in the `createSpace` call,
and doesn't use the `skipGatewayAuthorization=true` flag.
- **Testing:** Introduced test cases to verify the authorization of
specified gateways.
- **Fixes:** Resolved issues with previously broken test cases (Egress
Record).

### Related Issues
- storacha/project-tracking#158
- storacha/project-tracking#160
- storacha/project-tracking#207
- storacha#1604
- Resolves storacha/project-tracking#196
fforbeck added a commit to storacha/w3cli that referenced this issue Dec 19, 2024
@fforbeck
feat: content serve authorization (#205)
34efff2 
### Context
We must ensure that the space owner delegates the
`space/content/serve/*` capability to the Gateway. This delegation
allows the Gateway to serve content and log egress events appropriately.

### Changes
I've updated the CLI to enable the new gateway content serve
authorization flow when creating a space. This is a breaking change
because now the user is forced to provide the DIDs of the Content Serve
services, and the service endpoint, or skip the authorization flow.

### Related Issues
- storacha/project-tracking#158
- storacha/project-tracking#160
- storacha/project-tracking#207
- Resolves storacha/project-tracking#196
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fforbeck fforbeck

Labels
None yet
Projects
Storacha Project Planning
Status: Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Peeja @fforbeck @hannahhoward