Users are redirected to /app/kibana#/discover

[canasdiaz]

First time a user logs in the analytics.mozilla.community service the browser is redirected to the URL /app/kibana#/discover instead to /app/kibana#/dashboard/Overview. When the session of the user is created, this no longer happens (until the session expires).

This is not urgent but must be fixed.

[hmitsch]

Rising urgency because this is more and more of a pain point for people who are new to Community Analytics.

[canasdiaz]

We are working on it this week.

[canasdiaz]

We did not start working on it yet. Sorry for this.

[canasdiaz]

Work in progress. Waiting feedback from Mozilla staff (via Slack)

[canasdiaz]

We are blocked. Waiting feedback from Mozilla staff.

Should we move it to any other column @hmitsch so you folks have it in your radar? In any case this is not critical so no worries :nerd_face:

[johngian]

I spend some time doing debugging that issue and I think that the root cause is the following:

What we have already configured

• We use OIDC proxy to proxy requests and enforce authentication
• The proxy by default redirects ^/$ to /app/kibana#/dashboard/Overview
• This used to work fine

What is the problem

The first time you authenticate requests are proxied (as expected) and after successful authentication Kibana sends the user to /app/kibana instead of /. This means that the rule above won't redirect properly to the dashboard. The reason behind that is the server.defaultRoute config entry which by default is configured to /app/kibana.

From kibana docs:

Default: "/app/kibana" This setting specifies the default route when opening Kibana. You can use this setting to modify the landing page when opening Kibana. 

Solutions

1. proxy level: We either redirect /app/kibana to the dashboard page like we do with / (which i haven't done because i am not sure if its breaking the rest of kibana).
2. kibana level: Or we set the server.defaultRoute config to redirect to / and then the proxy is going to work as expected.

@sanacl thoughts ?

[canasdiaz]

@johngian I would go for option 2. I'm discussing this with @dpose today. Thank you!

[johngian]

Sounds good, let me know if you need any help.

[dpose]

@johngian

You are right, the first time you authenticate requests are proxied and after the authentication process you are redirected to "/app/kibana". But that doesn't happen if you access to the dashboard again, I mean if you were previously logged in using the Mozilla's SSO.

We tested both solutions you proposed with no luck. Using the variable called 'server.defaultRoute' we didn't see any difference in the behaviour. Updating the rule to be redirected to the Overview dashboard neither fix the issue.

We noticed the issue is concerning not only to the '/' or '/app/kibana' path but also to any path ('/app/kibana#/dashboard/IRC' for example). It seems the SSO is always redirecting to the same url instead of keeping the requested url. Could you please confirm whether it is the expected behaviour?

We will continue working on it to find a way to fix it but we'd like you to check if the SSO output is the requested url or it is a fixed one.

[johngian]

Hey @dpose I think its probably better to avoid any other changes to the proxy because it increase the complexity of just doing authentication.

What about changing this kibana configuration? kibana.defaultAppId: | Default: "discover" The default application to load.

I did some research and changing it to dashboard/Overview might do the trick. This way we fix the default dashboard in the kibana level. (we can even remove the proxy level redirect).

[canasdiaz]

Hi @nemo @hmitsch , if you guys want to avoid modifying the proxy we would have to do what it is suggested in the previous comment. The result would be something like this the first time you log in:

According to my first test, the Overview panel won't be loaded by default (using the solution suggested in the previous comment). There are more disadvantages, sharing an URL will not be very useful unless you are logged in, because you'll be redirected to the page above.

Said that, I think it improves what we had. What do u think @hmitsch?

[hmitsch]

If we have to choose between these two options:

A) Initial login to /edit mode with URL Sharing working all the time B) Initial login to Overview with URL Sharing only working in logged in mode

In that case I would prefer Option B over Option A.

Best regards, Henrik

[canasdiaz]

I've applied the change @johngian suggested and it is working better I initially thought. This is the behavior we have now:

• first time visiting our URL user is redirected to Overview
• once user is logged in it will be redirected if no dashboard is found in the URL
• first time visiting a shared URL user is redirected to the shared URL but due to a configuration error (it must be in NGINX or in the Proxy) the filters are not displayed on top. Data appears, widget loads and if the user clicks on any dashboard everything works (filters included).

The third point is the only one that concerns me. It is a strange behavior but I think it is a minor bug. The way to reproduce this third point is simply clicking on a shared URL such as: https://analytics.mozilla.community/goto/57e2fa285303d08034f6b6b4e276d1c1

What do u think @hmitsch @johngian ?

[johngian]

About the third point how do you pass the filters from the URL to the backend? I would say that given the initial scope this is good enough but i will defer to @hmitsch for accepting it.

[hmitsch]

@sanacl sorry for being difficult here ... seeing the filters is important. Here's the use case:

• Person A creates a filtered view. That person is stuck and frustrated because they don't get the data from the dashboard they are looking for.
• They create a short URL, share the view with us (you, Daniel, me).
• We look at their filters and suggest a fix.

Step 3 won't work, right?

Best regards, Henrik

[canasdiaz]

@hmitsch you are right but I was not.

I'm not sure why this is working now (it didn't yesterday with the same setup) so I have to review a couple of files, but the thing is shared links are correctly working now. Sorry for this confusing message and no, I haven't been replaced by a Monty Python bot :nerd_face:

[hmitsch]

I confirm, things work now:

• A fresh login brings up the overview
• A shared link also works

It's strange, I am happy, and of course it would be great to understand WHY all of a sudden things work as we desired.

-Henrik

[canasdiaz]

I'm reviewing this and just a couple of comments.

@hmitsch the view after going to /edit is not the one I included at https://github.com/mozilla/participation-metrics-org/issues/162#issuecomment-394389309 , it will be: We had a bug related to the kibanas and the proxy so it was redirecting to the public kibana (which is the one with the menu).

My next comment if about the configuration error / bug :)

@johngian I've seen the behavior is not predictable when the kibanas are restarted/rebuild and it is not that strange as the proxy link them, we should have this in a docker-compose file so every time a linked container is modified the proxy is restarted. We can talk about this via slack if you want.