Skip to content
New issue

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

#

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

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # 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