Skip to content
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

WebUI does not work for non local machine #591

Closed
dsvi opened this issue May 26, 2017 · 5 comments
Closed

WebUI does not work for non local machine #591

dsvi opened this issue May 26, 2017 · 5 comments

Comments

@dsvi
Copy link

dsvi commented May 26, 2017

The WebUI, returned by <IPFS API URL>/webui has hardcoded localhost in it. So it doesn't really work for any other machine than localhost
It should take the API address from the go-ipfs config, not just force it to be localhost.

@daviddias
Copy link
Member

@dsvi that intended and is a security protection mechanism to make sure that you can't have access to admin features outside of your local machine :) Hope this clarifies

@dsvi
Copy link
Author

dsvi commented Jun 25, 2017

Not really, no. More confuses, than clarifies.
So i do have remote access to the json RPC API, through which i get the page and can control the daemon, but through the page itself, i can't control it.
What kind of "security" exactly this provides? Does it all holds on the fact that i can't change 'localhost' to any other string in the javascript?
It really sounds very silly, to put it mildly. The page itself doesn't have anything to do with security. It's a convenient GUI to the already provided and accessible RPC.

@DiagonalArg
Copy link

This issue should still be opened. It is the same as #628, #637 and #594.

@DevonJames
Copy link

DevonJames commented May 22, 2018

@diasdavid what specific security concerns would there be if the webui wasn't hardcoded to work with localhost only?

edit: seems like /Config and adding files via /Files would be the concerns. Many of us just want to use /Files to look up info about a file - seems like that functionality could be exposed to work with remote hosts without exposing any vulnerabilities, no?

this may be something we could lend some development cycles to implementing if its the right direction to take things

@olizilla
Copy link
Member

See: #836

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants