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

Inbuilt web UI Connection Settings default of localhost is confusing #3300

Closed
daviesalex opened this issue Jul 12, 2015 · 1 comment
Closed
Assignees
Milestone

Comments

@daviesalex
Copy link
Contributor

When you install Influx on a node, and go to http://node:8083/, the (hidden) settings pane attempts to connect to localhost. Since the JS is using this to determine the hostname that it sends HTTP requests against, this is wrong in almost all cases (would only work on the case you have installed Influx locally, which I guess is common for developers).

The error that is returned ("Couldn't connect to host (http://localhost:8086): error") is not that clear either; this could be read to be a server side issue between the web handler communicating with the Influx backend on 8086.

I think this should default to the HTTP Host as specified in the request header for index.html. The HTML comes from ./shared/admin/index.html:

 66                         <h3 class="panel-title">Connection Settings</h3>
 67                     </div>
 68                     <div class="panel-body">
 69                         <form class="form-inline" id="form-settings">
 70                             <div class="form-group">
 71                                 <label for="hostname">Host</label>
 72                                 <input type="text" class="form-control" id="hostname" placeholder="localhost">
 73                             </div>

There are a couple of obvious ways to do this:

  1. Template the rendering of ./shared/admin/index.html
  2. Use javascript to detect the default HTTP host and set that

(2) feels like a bit of a hack; (1) may be more work.

Thoughts?

@toddboom
Copy link
Contributor

@daviesalex I think this is fixed with the changes in #3184. I'm closing this for now, but either a build from master or any of the v0.9.2 build should have this fixed. Thanks!

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

3 participants