-
Notifications
You must be signed in to change notification settings - Fork 246
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.
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
Add http server to subspace-gateway. #3286
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good start, but it is missing remote input validation, which could introduce a security vulnerability. It’s also missing object data hash validation, but I don’t think that’s a security issue.
I also have a few suggestions to avoid code duplication, and a bunch of comment updates. Feel free to ignore the comment stuff for now.
Let me know if you’d like me to help with any of these changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review!
#[serde(rename = "pieceIndex")] | ||
piece_index: u64, | ||
#[serde(rename = "pieceOffset")] | ||
piece_offset: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like spreading the dependency across contexts. I would prefer changing types.
eb2e985
to
135f043
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Once we’ve got the dependencies and the hash type cleaned up, we should be ready to go.
#[serde(rename = "pieceIndex")] | ||
piece_index: u64, | ||
#[serde(rename = "pieceOffset")] | ||
piece_offset: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing to Blake3Hash
here might simplify some of the code below.
|
||
async fn request_object_mappings(endpoint: String, key: String) -> anyhow::Result<ObjectMapping> { | ||
let client = reqwest::Client::new(); | ||
let object_mappings_url = format!("http://{}/objects/{}", endpoint, key,); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hardcoding the HTTP protocol would avoid the usage of indexers with HTTPS endpoints? For example, using the currenthttps://indexer.taurus.autonomys.xyz
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using this indexer could be useful for debugging and testing purposes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d suggest making the protocol part of the endpoint URL, like we do for RPC clients:
subspace/crates/subspace-gateway/src/commands/run/network.rs
Lines 20 to 21 in 07a3f4e
#[arg(long, value_hint = ValueHint::Url, default_value = "ws://127.0.0.1:9944")] | |
node_rpc_url: String, |
Note: using HTTP isn’t a security issue here, because:
- the raw object data is already public on the chain
- we check the hash of the returned data, so it can’t be modified in transit
HTTP might be a minor privacy issue, because the hash and timing of each object fetch is unencrypted. It’s up to Carlos if that’s a significant issue in our use case though.
Allowing HTTPS in this PR would make that a deployment decision, not a developer coding decision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this suggestion. I'll create and test a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I made PR #3293 to simplify the code further.
|
||
async fn request_object_mappings(endpoint: String, key: String) -> anyhow::Result<ObjectMapping> { | ||
let client = reqwest::Client::new(); | ||
let object_mappings_url = format!("http://{}/objects/{}", endpoint, key,); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d suggest making the protocol part of the endpoint URL, like we do for RPC clients:
subspace/crates/subspace-gateway/src/commands/run/network.rs
Lines 20 to 21 in 07a3f4e
#[arg(long, value_hint = ValueHint::Url, default_value = "ws://127.0.0.1:9944")] | |
node_rpc_url: String, |
Note: using HTTP isn’t a security issue here, because:
- the raw object data is already public on the chain
- we check the hash of the returned data, so it can’t be modified in transit
HTTP might be a minor privacy issue, because the hash and timing of each object fetch is unencrypted. It’s up to Carlos if that’s a significant issue in our use case though.
Allowing HTTPS in this PR would make that a deployment decision, not a developer coding decision.
#[serde(rename = "pieceIndex")] | ||
piece_index: u64, | ||
#[serde(rename = "pieceOffset")] | ||
piece_offset: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I wanted to go a bit further, see 02c0ca4
(#3293) in #3293.
#[serde(deserialize_with = "string_to_u32")] | ||
block_number: BlockNumber, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a bug to me. Why would you want to receive a number as a string in JSON instead of an actual number? This should be a number, just like all the others in this very struct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I thought that was a bit weird! The block number provided by the node in the mapping subscription is a number:
subspace/crates/sc-consensus-subspace-rpc/src/lib.rs
Lines 230 to 237 in 3d5483e
pub struct ObjectMappingResponse { | |
/// The block number that the object mapping is from. | |
pub block_number: BlockNumber, | |
/// The object mappings. | |
#[serde(flatten)] | |
pub objects: GlobalObjectMapping, | |
} |
(Specifically a u32
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be a problem on my end. I expected it to be a u64/BigInt
so postgres automatically parsed to string.
This PR adds an HTTP endpoint to
subspace-gateway
as an update toAutoDrive Gateway
project. It reuses the object fetcher and keeps the existing RPC-server. The new API serves files reconstructed from DSN by object fetcher using object mappings received from the object mapping indexer.Changes
run
command torpc
command and move shared codehttp
command to serve requests onhttp://<IP>:<PORT>/data/{object_hash}
usingactix-web
framework.Code contributor checklist: