Skip to content
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

Support for non-fragment-URLs (pushState) #6219

Closed
Roguelazer opened this issue Feb 12, 2016 · 5 comments
Closed

Support for non-fragment-URLs (pushState) #6219

Roguelazer opened this issue Feb 12, 2016 · 5 comments
Labels
enhancement New value added to drive a business result stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@Roguelazer
Copy link

Kibana, like the other internal applications here, is set to be deployed behind an authenticating SSO proxy that issues redirects as part of authentication. This means that the first load for any user for Kibana is extremely frustrating to use, since Kibana puts everything in a fragment URL -- even things like the dashboard or saved-search name, which don't really have any reason to go in a fragment URL. We've gotten just about every other JS app moved over to pushState (html5Mode for the angular apps, pushState: true for backbone apps, probably similar nomenclature in other Single-Page-Site frameworks). Are there any branches under-way to make kibana send real URLs to the server side? It'd be great not just for the redirects-lose-the-dashboard-name issue, but also for better server-side access logging and a host of other neat things.

@rashidkpc
Copy link
Contributor

No current plans to use non-hash-based state, but I'd be interested in the discussion. We only support newer browsers anyway

@spalger
Copy link
Contributor

spalger commented Feb 12, 2016

the server is ready for the update, the only issue in my mind would be the parts of the code that read read the raw url. It would probably be a worthwhile adventure though, would also allow us to have better server-side redirects.

@epixa
Copy link
Contributor

epixa commented May 23, 2016

Complexity of the work aside, I can't think of any technical reason not to go forward with this. All supported browsers handle pushState, angular has baked-in support for it, hapi should have no trouble with it, and it opens up multiple new workflows for people including proper SSO redirects and request logging.

Not to discount the work involved, but after only a few minutes of looking around and 2 lines of code, I was able to get Kibana to load properly with pushState enabled. There were still lots of problems and Kibana was mostly unusable if you tried to navigate, but it seemed like the issues I encountered were due to how we were constructing links on the client rather than something fundamental to our setup.

I'll keep poking at this to see if I can weed out any truly insidious problems with going down this route.

@w4
Copy link

w4 commented Mar 1, 2018

any update on this? would the move to react make this easier? we have to have a big ugly notification banner telling our users to use short urls (and the share button doesn't even show on half of kibana's pages!)

@epixa epixa added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Mar 10, 2018
@epixa
Copy link
Contributor

epixa commented Mar 10, 2018

No update here, though this is still something we want to do. I'm not sure if it'll be any easier with react.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

6 participants