file:// URLs get mangled

[hrichardlee]

Kibana version: 6.2.2

Elasticsearch version: 6.2.2

Server OS version: Windows Server 2016

Browser version: Chrome 64

Browser OS version: Windows 7

Original install method (e.g. download page, yum, from source, etc.): Download page

Description of the problem including expected versus actual behavior: When there is a URL field that starts with file://, Kibana creates an <a> tag with href="http://myserver/app/file//[etc]" which is not usable.

Steps to reproduce:

1. Create a document with a field called "test" that has a value, "file://c/temp.txt."
2. Set the "test" field to be in the URL format
3. When viewing the document, try to click on the "test" link

This was also reported in the forums https://discuss.elastic.co/t/kibana-url-format-bug-file/121414 (the poster there said they would create an issue, but I haven't been able to find it).

I think the fix for this would just be to add "file://" to whitelistUrlSchemes in https://github.com/elastic/kibana/blob/d06ee13ab83baba86a36ffd69fe6277f845a034c/src/core_plugins/kibana/common/field_formats/types/url.js

Thanks!

[chrisronline]

Yup, this is something we can easily fix. Do you mind opening a PR to address this?

[gmoskovicz]

@chrisronline perhaps we should consider here custom whitelists of specific protocols other than http/https? What do you think?

[chrisronline]

@gmoskovicz Yup, that sounds definitely viable. I don't think there are any concerns with that, but pinging @kobelb and @legrego to double check.

[legrego]

@chrisronline @gmoskovicz In general I don't have a problem with a custom whitelist, but if we take this route, we may want to blacklist certain protocols from ever being included:

• javascript: - pseudo-protocol, but we certainly don't want to allow JS to execute
• chrome:, resource: - both used by Firefox/FF plugins...I'm not very familiar with them, but they don't sound like something we'd want to allow.

I'll look for others if we go forward with the custom whitelist, but those are what immediately came to mind

[gmoskovicz]

@legrego @chrisronline Sounds good to me, but this will still allow things like file, ftp and others.

So we might want to have a whitelist with some blacklisted, that will give the needed functionality.

[alex-kuck]

I would definitely support the use of blacklisting instead of whitelisting, since we are using custom protocols in order to start our own applications. The current behaviour is quite restrictive.

[chrisronline]

@gmoskovicz @timroes brought up a good point about file:// protocols here. What is the use case for wanting to support this? Are folks starting browsers (and Kibana) with this security restriction disabled?

[gmoskovicz]

@chrisronline in the context of my ask, i wasn't thinking about file:// but a custom protocol for a custom Java application.

[timroes]

@chrisronline I think we might want to stick with http and https as default, but create an setting for whitelisting more protocols. I would suggest, that this setting even goes into kibana.yml, so only an administrator can change it. I think that would be the safest and still allow users to also whitelist file in case they work around the browser security in some way.

We should consume that setting in the markdown visualization and the link field formatter.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[kertal]

for visibility there are new comments in this issue, so there's still demand for a solution:

https://github.com/elastic/kibana/issues/112774

[jeffvestal]

+1 to adding a whilelist of options. I would like to be able to have clickable mailto:user@company.co links for example.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[GeorgeGkinis]

We would also like to be able to click-open mailto:name@domain.com links.

Adding an advanced setting for allowed schemes would not be that hard and leaves the responsibility to the kibana admins. @timroes kibana.yml config would indeed also be a nice and safer option.

Are there currently any plans on implementing this? This ticket has been open for 5 years now.

Thanks for a wonderfull and empowering product!

[kertal]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.