Closed canasdiaz closed 6 years ago
Rising urgency because this is more and more of a pain point for people who are new to Community Analytics.
We are working on it this week.
We did not start working on it yet. Sorry for this.
Work in progress. Waiting feedback from Mozilla staff (via Slack)
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:
I spend some time doing debugging that issue and I think that the root cause is the following:
^/$
to /app/kibana#/dashboard/Overview
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.
/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).server.defaultRoute
config to redirect to /
and then the proxy is going to work as expected.@sanacl thoughts ?
@johngian I would go for option 2. I'm discussing this with @dpose today. Thank you!
Sounds good, let me know if you need any help.
@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.
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).
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?
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
I've applied the change @johngian suggested and it is working better I initially thought. This is the behavior we have now:
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 ?
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.
@sanacl sorry for being difficult here ... seeing the filters is important. Here's the use case:
Step 3 won't work, right?
Best regards, Henrik
@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:
I confirm, things work now:
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
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.
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.