ipfs / ipfs-webui

A frontend for an IPFS Kubo and IPFS Desktop
https://webui.ipfs.io
MIT License
1.57k stars 490 forks source link

Allow the WebUI to connect to an authenticated API #2243

Open hazae41 opened 4 months ago

hazae41 commented 4 months ago

Checklist

Description

ipfs/kubo#2389

Is there a way to connect to an authenticated API from the WebUI?

It seems the WebUI only accepts an URL or a Multiaddress without any possibility to customize the Authorization header

Maybe there should be a way to put the authorization into the URL via path or query parameters?

Thanks

hazae41 commented 4 months ago

I managed to get it to work by putting the secret token in a cookie and by using a Nginx reverse proxy to pass the cookie into an authorization header

server {
    listen       80;

    location / {
        proxy_http_version    1.1;
        proxy_pass            https://ipfs.example.com/;
        proxy_ssl_server_name on;
        proxy_set_header      Authorization      "Bearer $cookie_token";
        proxy_pass_header     Authorization;
        client_max_body_size  100M;
    }
}

Then go to your proxy url /webui and execute the following JavaScript in the web console

document.cookie="token=YOUR_IPFS_TOKEN"

Reload the page and voila

https://github.com/hazae41/safe-ipfs

lidel commented 4 months ago

I think there is an old code that support Basic Auth (https://github.com/ipfs/ipfs-webui/issues/836, https://github.com/ipfs/ipfs-webui/issues/1586), but afaik there is no support for Bearer tokens.

The basic auth credentials are passed in URL form:

image

@hazae41 does Basic Auth work for you (then we can close this), or do you need ability to pass custom Authorization header (then we should turn this into feature request).

hazae41 commented 4 months ago

Thanks, I will try

Yet Bearer should be good to add at some point if you have time

hazae41 commented 4 months ago

When the WebUI is same-origin, I can successfully go to /webui and enter the user:pass in URL and it works

But when the WebUI is cross-origin, its requests don't pass CORS, because it sends an OPTIONS preflight request without Authorization header, so the API then replies a Forbidden 403 since there is no header, which fails the CORS preflight test

The solution would be to always reply to OPTIONS requests with HTTP 200

I also noticed it can work with Bearer if we enter this JSON into the URL input

{"url":"https://ipfs.example.com","headers":{"authorization":"Bearer YOUR_TOKEN"}}
github-actions[bot] commented 4 months ago

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

github-actions[bot] commented 3 months ago

This issue was closed because it is missing author input.

hazae41 commented 2 months ago

It's still an issue when connecting from a third-party, it's blocked by CORS

The solution would be to always reply to OPTIONS requests with HTTP 200

vpavlin commented 2 months ago

Can't you just set Allow-Origin and Allow-Methods in IPFS config?

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "POST", "OPTIONS"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["'${IPFS_EXTERNAL_URL}'"]'

Or is the problem that you don't control the node?