I'm running Kibana 4.5.0 against Elasticsearch 2.3.1 with Shield and am trying to configure multiple Kibana instances on a single URL, to achieve this I was looking at specifying server.basePath within kibana.yml
server.port: 5602
server.basePath: "/foo"
When hitting https://servername:5602/, it sends me to https://servername:5602/foo, but then I get into a login redirect loop.
Thoughts?
Can you try deleting the sid cookie in your browser, or loading it in another browser or incognito window and see if you still see that happen? We've encountered a login redirect loop internally in rare cases, but haven't seen anything related to basePath, and I'd like to know if you are seeing what we're seeing or if this is another issue.
I'm seeing the same behavior in incognito.
Can you share what other settings you have in your kibana.yml (excluding the encryptionKey, of course)
These are all of the options currently set:
server.port: 5602
server.host: "10.64.16.15"
server.basePath: "/foo"
marvel.node_resolver: name
elasticsearch.url: "https://elasticsearch-node.contoso.com:9200"
elasticsearch.preserveHost: true
kibana.index: ".kibana-foo"
kibana.defaultAppId: "discover"
elasticsearch.username: "ServiceAccount_P"
elasticsearch.password: "**************"
server.ssl.cert: D:\kibana\kibana.contoso.com.crt
server.ssl.key: D:\kibana\kibana.contoso.com.pem
elasticsearch.ssl.ca: D:\Kibana\config\cacert.pem
elasticsearch.requestTimeout: 300000
logging.verbose: true
shield.encryptionKey: "****************"
I pinged the Shield UI author and he hasn't seen this issue before. We think it's probably a misconfiguration somewhere, just need to figure out where. I don't see anything wrong with your Kibana config though.
What are you using for your proxy, nginx or something? Can you share that configuration as well?
The plan is to run these behind an F5 LTM, but currently I was just targeting the server directly at https://servername:5602/foo to test it out. That should work, right?
If you also had the proxy in place, then it should work. The basePath setting just re-writes the URLs, something still has to serve up the site at that path though.
It sounded like you have the proxy up though, otherwise I'd expect the first request to be a 404, but perhaps I'm wrong. If you don't have a proxy in place, that would actually explain why / redirected to /foo.
Did you have some kind of proxy set up already to redirect kibana.contoso.com/foo to server1.contoso.com/?
Okay, I think I got it figured out. Misconfiguration of the F5 LTM on my side, sorry about that.
I was following this F5 KB for configuring the rewriting on the LTM and it was instructing to do the rewrites on the request and response, which I believe caused the problem since Kibana was performing the rewrites itself. Modifying it to change just the request seems to have made it work.
I was under the impression that specifying a server.basePath simply moved the path in which everything was accessed, so I would simply have to specify it for each instance and then direct traffic based on that context to each server/port rather than perform the rewriting on the requests.
I've encountered another redirect loop, not sure if it's the same one that you were referring to encountering internally.
As I mentioned, I'm routing to multiple Kibana instances from a single URL based on the context.
I can login fine to kibana.contoso.com/foo/ and get the sid cookie on the path of /foo/
I can then immediately login to kibana.contoso.com/ and get it's own sid cookie on path of /
But if I login to kibana.contoso.com/ first and get the cookie, and then proceed to login to kibana.contoso.com/foo/ I get stuck in a redirect loop. Since I now see the cookie at path /, I'm guessing that's causing some type of conflict? Simply deleting the sid cookie from / allows me to login fine.
It's worth mentioning that both Kibana instances have the same shield.encryptionKey value. More of an oversight when creating the second instance, I'm assuming they should be different?
If I change the shield.encryptionKey value on the /foo/ instance, I simply get redirected back to the login page to enter credentials, not stuck in a loop. I can see the request header submitting the cookie from / and getting a response back setting an expired, empty sid cookie on path /foo/
I meet a very similar issue, but return 404. I also use shield.
Here is my kibana.yml:
# sed '/^\s*#/d; /^$/d' /opt/kibana/config/kibana.yml
server.basePath: "/kibana"
elasticsearch.username: "hide"
elasticsearch.password: "hide"
And here is the curl -v output:
curl -v localhost:5601
* Rebuilt URL to: localhost:5601/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5601 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5601
> Accept: */*
>
< HTTP/1.1 200 OK
< kbn-name: kibana
< kbn-version: 4.5.0
< cache-control: no-cache
< content-type: text/html
< content-length: 231
< accept-ranges: bytes
< Date: Tue, 12 Apr 2016 14:39:18 GMT
< Connection: keep-alive
<
<script>var hashRoute = '/kibana/app/kibana';
var defaultRoute = '/kibana/app/kibana';
var hash = window.location.hash;
if (hash.length) {
window.location = hashRoute + hash;
} else {
window.location = defaultRoute;
* Connection #0 to host localhost left intact
}</script>
# curl -v localhost:5601/kibana/app/kibana
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5601 (#0)
> GET /kibana/app/kibana HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5601
> Accept: */*
>
< HTTP/1.1 404 Not Found
< kbn-name: kibana
< kbn-version: 4.5.0
< content-type: application/json; charset=utf-8
< cache-control: no-cache
< content-length: 38
< Date: Tue, 12 Apr 2016 14:39:49 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
{"statusCode":404,"error":"Not Found"}
# curl -v localhost:5601/kibana/app/kibana/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5601 (#0)
> GET /kibana/app/kibana/ HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5601
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< location: /kibana/app/kibana
< kbn-name: kibana
< kbn-version: 4.5.0
< cache-control: no-cache
< content-length: 0
< Date: Tue, 12 Apr 2016 14:41:31 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
This seems like a separate issue... Could you open a new thread and also explain more of your set-up? Are you using the Shield UI plugin for Kibana? It looks like your Kibana server isn't configured to use SSL, is this correct?
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.