Embedded iframe Kibana Login Loop on Mobile Browsers

Elastic Stack Kibana
1

Hi there,

As described in Kibana stuck in login loop, Google Chrome will no longer store non-secure cookies as of Release 84, which results in an authentication loop if Kibana is embedded in an iframe on an HTTP website. Per @majagrubic, the solution is to utilize HTTPS as well as modify kibana.yml by adding xpack.security.sameSiteCookies=None (on versions 7.8.1+).

While this resolved my issue on the desktop version of Chrome, I'm now seeing the issue on iPhone devices despite using HTTPS. The screen goes back and forth between "Welcome to Elastic / Authenticating..." and "Loading Elastic". I've also tried "View Desktop Site" on mobile with no luck. I'm testing with Chrome 92.0.4515.90 on iOS and Firefox Daylight 35.0 (5448) on iOS. I'm using Elastic Cloud version 7.14.

Of note, I've enabled Kibana's anonymous authentication access (using an API Key). My use case is to display a public, read-only Kibana dashboard on an external website. To re-iterate, this set-up works perfectly on desktop browsers, but not on mobile browsers for some reason.

Update: It appears to work on Android-based browsers. Perhaps this is related to the Safari iframe issue? Safari by default discards cookies set in an iframe unless the host that's serving the iframe has set a cookie before, outside the iframe. Is iOS requiring the same of any third-party browsers installed on iPhone?

Any ideas?

2

Can you share what your embed code and kibana config look like?

There's an article here that explains how to embed content in iframes when using anonymous access but would be good to look at your specific situation in case you've already followed the steps: Authentication in Kibana | Kibana Guide [7.14] | Elastic

3

Yes, I think I've followed all of the necessary steps from that article, but here's what I've got:

kibana.yml:

xpack.security.sameSiteCookies: None
xpack.security.authc.providers:
  anonymous.anonymous1:
    order: 0
    credentials:
      apiKey: "A1234..."
  basic.basic1:
    order: 1

index.html: (I've truncated the src attribute for readability)

<body style="margin:0px;padding:0px;overflow:hidden">
<iframe frameborder="0" style="overflow:hidden;height:100%;width:100%" src="https://my-site.aws.found.io:9243/app/dashboards?auth_provider_hint=anonymous1#/view/.............height="100%" width="100%"></iframe>
</body>

Let me know if you need any more detail. I'll message you a link to the actual hosted version that you can feel free to check out as well.

Thanks!

4

Thanks so much for all the details. I was able to reproduce this locally. This issue is caused by Apple's "Prevent Cross-Site Tracking" feature which prevents iframes from setting cookies. This is why you see that infinite redirect. Kibana logs in as the anonymous user but the session cookie never gets set so it tries again when the authentication call fails. This also happens on desktop when using the latest version of Safari.

There's an existing bug report here: Embedded Kibana fails to authenticate with Safari · Issue #97200 · elastic/kibana · GitHub

I would suggest to follow that for updates but for now my only recommendation is to share the direct URL to the dashboard instead of embedding it in an iframe or alternatively disable "Prevent Cross-Site Tracking".

5

Thanks for looking into this. I’ll continue to monitor the issue you referenced.

In the meantime, if providing the dashboard link directly, might it be possible to somehow disable the initial login page containing the “Continue as Guest” as an option? Or generate some sort of separate dashboard URL that defaults to the anonymous user?

The only other workaround I can think of is trying to add a reverse proxy server in front of my dashboard that can automatically authenticate with an anonymous user, but I’m trying to stay as serverless as possible.

I’ll also look at the Canvas workpad (beta) shareables feature for use cases where I need to embed visualizations in public-facing web articles.

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.