-
Notifications
You must be signed in to change notification settings - Fork 30
HTTP API, access control and API tokens #159
Comments
Cool, @Kubuxu !!! I am in a super urge to implement this myself. Before the villagers come after me with torches and pitchforks. Do you have a plan to attack this? |
We are not really sure how it should work or how to continue but we would love to see any progress on it. The cleanest solution so far seems usage of JSON Web Tokens as there are already libraries supporting. Right now the most useful would be a draft for a spec which would allow us to agree on one thing. It would also have to define granularity of the tokes and me extensible for future (including changing format and splitting permissions). |
Agreed.
Will try my hand at writing a spec. Let's do this. Can you point me to any popular spec inside IPFS, so I can |
There is no strict format, checkout https://github.com/ipfs/specs/tree/master/repo or other files in this repo. |
Will it help to use keys for a user and app. That might help to solve the origin problems, you have two tokens that could sign a transaction. App is public, user has a private key and a public key, ipfs can provide the jwt token with expiration, etc, which are signed using the private key of the user and includes the app key. |
Focusing on the app to start makes more sense regardless |
This issue is here to sum up: need, possible solutions and discussions on the access control of IPFS HTTP API.
What?
Currently we have two APIs, full access API (on port 5001) and limited read only API (on port 8080). This is so websites can't interfere with functioning of IPFS node, change it settings, add files and so on.
This thread aims to change it, allowing full merge of full access and read only APIs.
Why?
In current state, Webapps built fully on top of IPFS, require users to manually tweak their configs to grant them full write access, this has ugly side effect of giving app completely full access to your node and makes IFPS Webapps much harder to use.
Solution
We should introduce API tokens, that would allow user to easily grant, revoke and limit access of some webapps.
Problems
This solution (as any) has it problems, main is storage of the secret token inside the webapp living in the browser, without separate security origin (as browsers do not handle ipfs paths in a way that we would expect).
My idea for the tokens is signed IPLD object very similar in format to JSON Web Tokens. We could also use JWT themselves as they are already libraries for handling them.
Related:
fs:/
security policy in FF: Origin policy for fs: URIs ipfs-companion#71The text was updated successfully, but these errors were encountered: