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

Accessing the webui behind a proxy #95

Closed
surajrav opened this issue Nov 21, 2015 · 6 comments
Closed

Accessing the webui behind a proxy #95

surajrav opened this issue Nov 21, 2015 · 6 comments

Comments

@surajrav
Copy link

Hi, I have a server with my basic webapp being served via nginx.

Now I have installed ipfs and want to add a /ipfsui proxy target which would take me to the webui for ipfs, thus I made the following additions to my existing fowardproxy in nginx.conf

        location /ipfsui {
            proxy_pass http://127.0.0.1:5001/webui/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        location /ipfs {
            proxy_pass http://127.0.0.1:5001;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }    

Now I can go to the ipfs ui by going to http://my_server_ip/ipfsui which properly redirects me to
http://my_server_ip/ipfs/hash_here/#/

However, the page has no relevant ipfs info (like my peer id and so on).

Then I went on to inspect the console error messages and found:

Uncaught TypeError: Cannot read property 'split' of undefined     bundle.js:2185
(anonymous function) @ bundle.js:2185
(anonymous function) @ bundle.js:21711
EventEmitter.emit @ bundle.js:6430
Response.handle @ bundle.js:7115
xhr.onreadystatechange @ bundle.js:6878
bundle.js:2225 Object {version: undefined, updateAvailable: false, updating: false, gateway: "http://127.0.0.1:8080"}

After looking up these error lines I came to the conclusion that the code in page.jsx (which has since changed in the main webui git repo, link: https://github.com/ipfs/webui/blob/master/js/views/page.jsx, but not changed so as it would overcome this problem of mine) determines the ipfs api url and port from window.location.host and window.location.port.

This is the snippet of the webapp that that I currently get served (via ipfs of course):

var host = window.location.hostname
var port = window.location.port || 80
var daemonConf = LocalStorage.get('daemon')
if (daemonConf) {
  host = daemonConf.host
  port = daemonConf.port
}
var ipfs = require('ipfs-api')(host, port)
var ipfsHost = window.location.host

var Page = React.createClass({
  displayName: 'Page',
  getInitialState: function () {
    var t = this

    ipfs.config.get('Addresses.Gateway', function (err, res) {
      if (err || !res) return console.error(err)

      var split = res.Value.split('/')
      var port = split[4]

(you can see where the code failed to split and tracedback from this snippet and the error above)

I know that not everyone will be running this behind a proxy and also that I can temp fix via making the ipfs api listen on 0.0.0.0 by setting it via ipfs config ... but want to ask if there is anby other way to get around my current problem before I embark on that path.

@jbenet
Copy link
Member

jbenet commented Nov 21, 2015

this is important to get right. i suspect changes to go-ipfs are necessary
to do so.

On Fri, Nov 20, 2015 at 7:02 PM Suraj Ravichandran notifications@github.com
wrote:

Hi, I have a server with my basice webapp being served via nginx.

Now I have installed ipfs and want to add a /ipfsui proxy target which
would take me to the webui for ipfs, thus I made the following addtions to
my existing fowardproxy in nginx.conf

    location /ipfsui {
        proxy_pass http://127.0.0.1:5001/webui/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /ipfs {
        proxy_pass http://127.0.0.1:5001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

Now I can go to the ipfs ui by going to http://my_server_ip/ipfsui which
properly redirects me to
http://my_server_ip/ipfs/hash_here/#/

However, the page has no relevant ipfs info (like my peer id and so on).

Then I went on to inspect the console error messages and found:

Uncaught TypeError: Cannot read property 'split' of undefined bundle.js:2185
(anonymous function) @ bundle.js:2185
(anonymous function) @ bundle.js:21711
EventEmitter.emit @ bundle.js:6430
Response.handle @ bundle.js:7115
xhr.onreadystatechange @ bundle.js:6878
bundle.js:2225 Object {version: undefined, updateAvailable: false, updating: false, gateway: "http://127.0.0.1:8080"}

After looking up these error lines I came to the conclusion that the code
in page.jsx (which has since changed in the main webui git repo, link:
https://github.com/ipfs/webui/blob/master/js/views/page.jsx, but not
changed so as it would overcome this problem of mine) determines the ipfs
api url and port from window.location.host and window.location.port.

This is the snippet of the webapp that that I currently get served (via
ipfs ofcourse):

var host = window.location.hostname
var port = window.location.port || 80
var daemonConf = LocalStorage.get('daemon')
if (daemonConf) {
host = daemonConf.host
port = daemonConf.port
}
var ipfs = require('ipfs-api')(host, port)
var ipfsHost = window.location.host

var Page = React.createClass({
displayName: 'Page',
getInitialState: function () {
var t = this

ipfs.config.get('Addresses.Gateway', function (err, res) {
  if (err || !res) return console.error(err)

  var split = res.Value.split('/')
  var port = split[4]

(you can see where the code failed to split and tracedback from this
snippet and the error above)

I know that not everyone will be running this behind a proxy and also that
I can temp fix via making the ipfs api listen on 0.0.0.0 by setting it
via ipfs config ... but want to ask if there is anby other way to get
around my current problem before I embark on that path.


Reply to this email directly or view it on GitHub
#95.

@zertrin
Copy link

zertrin commented Sep 27, 2016

Has there been any change since last year that makes it possible to access the webui via a reverse proxy? I have tried with apache, the page redirects and loads but no data from the node is shown.

For information, I'm running ipfs as a docker container with its port 5001 exposed on the host as 127.0.0.1:5001, then I set up a reverse proxy with apache in a VirtualHost listening on my.ip.add.ress:5001. (Previous tries with domain names were also unsuccessful).

@zertrin
Copy link

zertrin commented Sep 27, 2016

My current workaround without opening to the world the port from the server where ipfs is running is using SSH port forwarding like this:

ssh -L 5001:localhost:5001 myserver.example.org

and then accessing from my computer at http://localhost:5001/webui

It's working but still looking to avoid having to open a SSH connection and using a reverse proxy.

@wrouesnel
Copy link

There's also problems if you're trying to put HTTPS in front of the UI via nginx. It loads fine, but then the web-ui immediately tries to access it's own content via HTTP rather then HTTPS and is blocked.

@yonailo
Copy link

yonailo commented Feb 13, 2017

Moreover, Geolocation API is not working for non-localhost non-https origins (https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only). How can I set up a HTTPS proxy in this case ? I have tried without success.

@olizilla
Copy link
Member

Closing in favour of #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

6 participants