Kibana: Kibana 6.7.0 does not use credentials for some JS fetch actions

[flyingstar16]

Kibana version:
6.7.0

Elasticsearch version:
6.7.0

Server OS version:
Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux
(Debian stretch (9.8))

Browser version:
Firefox 60.5.1 ESR
Google Chrome 73.0.3683.86

Browser OS version:
Debian Linux testing

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

Describe the bug:
the fetch requests for:

• /translations/en.json (on Firefox)
• /ui/favicons/manifest.json (on Chrome)

are not passing credentials when using Kibana with Apache's authz module, thereby returning error 401.

This is the default behaviour of a fetch
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
for Firefox < 61.0b13; because 60 is ESR (https://www.mozilla.org/en-US/firefox/organizations/) this behavior should be fixed.
Also, it affects the current Google Chrome stable version.

This causes Kibana not to load at all on Firefox

Steps to reproduce:

1. Secure Kibana with an Apache "require valid-user" directive, e.g.
   
   AuthType Basic
   AuthName "Restricted"
   AuthBasicProvider file
   AuthUserFile /etc/apache2/passwords
   Require valid-user
   
2. Open in Firefox ESR
3. Kibana throws an error saying that it received a 401 for "translations"

Expected behavior:
Kibana loads

Screenshots (if relevant):

Errors in browser console (if relevant):

Unhandled promise rejection 
Error: Translations request failed with status code: 401
Stack trace:
_callee$@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:229:104845
tryCatch@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:497:447403
invoke@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:497:451288
defineIteratorMethods/</prototype[method]@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:497:448524
asyncGeneratorStep@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:229:99820
_next@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:229:100128
run@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:228:1704713
notify/<@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:228:1705000
flush@https://my.kibana.url/built_assets/dlls/vendors.bundle.dll.js:228:1711738
vendors.bundle.dll.js:228:1705454

Provide logs and/or server output (if relevant):

<MY_IP> - - [27/Mar/2019:14:37:55 +0100] "GET /translations/en.json HTTP/1.1" 401 657 "https://my.kibana.url/app/kibana" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"
<MY_IP> - - [27/Mar/2019:14:47:33 +0100] "GET /ui/favicons/manifest.json HTTP/1.1" 401 3951 "https://my.kibana.url/app/kibana" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"

Any additional context:
This can be temporarily solved by removing authz for the /translations folder, but it's not a good workaround because it leaks the existence of Kibana (which is what using mod_authz is meant to prevent)

[elasticmachine]

Pinging @elastic/kibana-platform

[zepheiryan]

To fix this while waiting for 6.7.1 to come out - and this is not for the faint of heart, so rolling back or waiting is probably better - edit your equivalent of /usr/share/kibana/built_assets/dlls/vendors.bundle.dll.js with the patch. It's an enormous optimized file, so you'll have to do some hunting; try searching for translationsUrl. Once you're in the right function, just add the argument ,{credentials:'same-origin'} to the fetch call and refresh your browser. It seems the build_assets directory is new and intended to bypass the optimize/bundles directory, so I wasn't clear on how to generate anything in build_assets instead of spelunking in optimized Javascript.

[flyingstar16]

@zepheiryan thanks for the suggestion; I'll stick with the whitelisting for now, I don't mind waiting for 6.7.1 (although I acknowledge someone might actually need it).

For reference if someone stumbles across this while running 6.7.0, and doesn't mind [temporarily] allowing anyone to read /translations/*.json files, this is what I did (Apache 2.4.25)

<Location />
  AuthType Basic
  AuthName "Restricted Area"
  AuthBasicProvider file
  AuthUserFile /my/passwords/file
  Require valid-user
</Location>
<Location /translations>
  Require all granted
</Location>

I will remove the Location /translations Require all granted once 6.7.1 is released.

[MaxCCC]

same issue on amazon with reverse proxy in front. AWS version is 6.7. Is this 6.7.0?

[flyingstar16]

If by "Is this 6.7.0" you mean "does this affect 6.7.0" then yep, see the title of this bug.
If you mean "does AWS ship 6.7.0", you should ask Amazon (but considering it's happening to you, most likely).
The workaround in the comment just above yours should work on whatever reverse proxy AWS is using, as long as they allow whitelisting; you just need to use their config instead of my Apache syntax.