-
Notifications
You must be signed in to change notification settings - Fork 42
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
[FEATURE REQUEST] Add Storj support #3
Comments
After deeper experimentation, I think an issue appears as Storj requires having data encrypted. However, your project doesn't allow passing Encryption Passphrase as URL parameter. Can you tell me if (1) this seems to be the problem from your point of view too, and (2) if it's a feature you're planing to add :) Here's the error when I use the default gateway endpoint :
Here's the error log when I use the explicit bucket endpoint :
|
Thanks for the issue report. I don't have much experience with Storj, but if I'm reading the docs correctly, it doesn't look like you have to pass the encryption passphrase as a URL parameter when using presigned URLs. (Here's an example in the docs where they don't.) I think they use the Auth Service to map S3 access tokens to the encryption passphrase and such. So I don't think the lack of encryption passphrase is the issue; the tokens from "Generate S3 Gateway Credentials" following these steps should be sufficient. The other thing I noticed is your LFS client is receiving HTTP 413 Content Too Large responses, so perhaps the issue has something to do with multipart uploads. Your Git LFS client (and every other I know of) doesn't support multipart uploads/downloads, but Storj recommends them for small uploads and may require them for larger ones (S3 requires multipart for objects larger than 5 GB). How big are the files you're trying to upload? I probably won't have time to play with Storj for a few days at least, but let me know if you find another issue or if something here solves your problem. |
Hello,
This project is really awesome, however the proxy doesn't seems to properly handle every S3-compatible storage. For instance, the Storj doesn't seem to be properly supported even if it's possible to generate some S3-like credentials.
The main difference I saw during my experiments with other providers is the lack of an
userid
which gives my a endpoint like : thishttps://access-key:[email protected]/gateway.storjshare.io/test-bucket
I'd be glad to help to implement it, so feel free to ask me for more details/tests :)
The text was updated successfully, but these errors were encountered: