Allow the WebUI to connect to an authenticated API

[hazae41]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

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]

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]

I think there is an old code that support Basic Auth (#836, #1586), but afaik there is no support for Bearer tokens.

The basic auth credentials are passed in URL form:

@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]

Thanks, I will try

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

[hazae41]

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]

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]

This issue was closed because it is missing author input.

[hazae41]

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]

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?