ipfs-companion
ipfs-companion copied to clipboard
ipfs
Feature request: support basic (or custom headers) auth for public gateway requests
It would be good if ipfs companion would allow me to use gateways which are running behind nginx with basic auth on them. The idea is a username/pw fields next to the public gateway configuration.
An alternative which works too would be to allow users to provide custom gateway request headers.
I would avoid putting basic auth in user interface, but I feel an option to provide additional headers with requests to HTTP gateway may be an elegant way to cover that and other use cases.
@hsanjuan Would it be a single set of headers used for both local and public gateway, or is there a good reason to have separate sets?
@lidel I guess it doesn't hurt to have them for local too (since go-ipfs is going to ignore them). Works for me at least.
Hm.. having slept on it I think if people start putting auth tokens there, we should have separate sets for public and custom gateway: otherwise it will leak secrets to all gateways.
This could be delivered as a subtask of #491, where we want to enable users to define multiple nodes and switch between them. Basically, every node would have a field to specify "custom headers" :sparkles:
I just tried setting my IPFS API URL to https://user:[email protected] and it didn't work at first. However, during troubleshooting I tried browsing to https://user:[email protected]/api/v0/config at which point I was prompted "you are about to login to this site" by the browser. Upon clicking OK, the plugin suddenly was able to connect as well.
This is in Firefox, and I'm guessing the reason it didn't work originally is because the plugin was waiting for me to confirm the login, and once I was logged in it was good to go. Further testing suggests that once I'm logged in, I can even remove the user:password@ from the API URL
It would be nice if basic auth "just worked", either by giving me a way to provide basic auth for the API in configuration (so the password doesn't show up in the plugin pop-up window) or at least give me a hint that I need to take some action to get auth working.
Ok, so basic auth seems to work fine in the context of redirecting to local node:
produces this warning the first time a redirect is made:
Doing the same for canonical public gateway + shutting down local node (to force use of public one):
seems to also work:
@hsanjuan the above seems to work fine these days – mind confirming?
@hsanjuan: I think it is just Firefox caching credentials for the host, which means it asks for them for every new site
So it does what we want (uses basic auth from the public gateway URL user provided). The problem is UX around it: when credentials are present in the URL, user gets a popup similar to this one:
Doing this one time is fine, but we don't want to see popups for every subdomain hostname when subdomain gateway like dweb.link is used.
Unsure if there is a fix for this.
Something we could explore in the past is to remove user and password from the redirect URL, and instead move it to HTTP header Authorization: Basic <credentials> – perhaps the warning goes away if the credentials are not in the URL?
Sadly, this will stop working in Chromium in 2023 because of Google forcing extensions to move to ManifestV3 which no longer has blocking request API (#666), so I don't see a fix for this that would work across all browsers.
Ideas welcome.
In Firefox I get the "do you want to visit with these credentails" popup, and when I click YES, I get the basic auth credentials pop up, completely empty.
I think the possibility of adding custom headers is good... must all features support Chromium?
I wonder if this is related to redirects or something, I will have to check configs. How does Firefox knows if a site requires authentication in the first place.