-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
file:// URLs get mangled #16983
Comments
Yup, this is something we can easily fix. Do you mind opening a PR to address this? |
@chrisronline perhaps we should consider here custom whitelists of specific protocols other than |
@gmoskovicz Yup, that sounds definitely viable. I don't think there are any concerns with that, but pinging @kobelb and @legrego to double check. |
@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:
I'll look for others if we go forward with the custom whitelist, but those are what immediately came to mind |
@legrego @chrisronline Sounds good to me, but this will still allow things like So we might want to have a whitelist with some blacklisted, that will give the needed functionality. |
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. |
@gmoskovicz @timroes brought up a good point about |
@chrisronline in the context of my ask, i wasn't thinking about |
@chrisronline I think we might want to stick with We should consume that setting in the markdown visualization and the link field formatter. |
Pinging @elastic/kibana-app-services (Team:AppServices) |
for visibility there are new comments in this issue, so there's still demand for a solution: |
+1 to adding a whilelist of options. |
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
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. Are there currently any plans on implementing this? Thanks for a wonderfull and empowering product! |
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. |
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:
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!
The text was updated successfully, but these errors were encountered: