I'm not sure if this is a bug or if i'm doing something wrong.
I looked out on the open issues and didn't see anything like this.
I'm trying to secure my web app using jwt, and i'm having trouble after my app redirect to login when i try to access a path that requires auth and the token is not valid.
The router does the redirection to login and after the authentication the redirection to the secured page also works fine, but then the router dies, no other route works, no errors or anything on the console either, the weird thing is that after a browser refresh everything works normal again.
It only happens after a redirect like this one: { path: '/', redirect: '/app' }, but /app requires authorization, so next('/login'); is executed (check my code below), then if the login is successful i execute self.$router.push('/app'); and that's that, i have to refresh in order to continue.
In firefox over windows64 it happens when i enter the app the first time if there is no token (when it has to do the redirection to login), if i delete the token and close/open the browser it happens again.
In chrome over windows64 happens sometimes, also after a redirect, if go directly to the login page it works normally.
Im using this:
router.beforeEach(function(to, from, next) {
if(to.matched.some(function(record) {
return record.meta.authorization || false;
})) {
var token = jwt.getToken();
if(token && token.valid) {
next();
} else {
next('/login');
}
} else {
next();
}
});
my routes look like:
[
{ path: '/login', component: loader('login') },
{
path: '/app',
component: loader('main'),
children: [
{ path: '', component: loader('dashboard') },
{ path: 'areas', component: loader('administration/areas') },
{ path: 'macro-processes', component: loader('administration/macro-processes') },
{ path: 'processes', component: loader('administration/processes') },
{ path: 'products', component: loader('administration/products') },
{ path: 'documents', component: loader('documentation/documents') },
//Lot of routes
],
meta: {
authorization: true
}
},
{ path: '/', redirect: '/app' },
{ path: '*', redirect: '/app' }
]
loader is a function that concatenates the full path of te component an returns a function to use resolve
function loader(component) {
return function(resolve) {
require(['js/components/' + component + '-component'], resolve);
}
}
and in my app.js i have this:
Vue.http.interceptors.push(function(request, next) {
var token = jwt.getToken();
if(token) {
if(token.valid) {
request.headers.set('Authorization', 'Bearer ' + jwt.getRawToken());
}
}
next();
});
Thanks.
I have the same problem now.I have found that adding query query: { redirect: 'test' } can fix it temporarily.
Hi, thanks for filling this issue. Please follow the Issue Reporting Guidelines and provide a live reproduction on jsfiddle, codepen etc. Thanks!
It seems that te problem happens only when i using <a href="#/...."> on the template or $router.push('/...'); on the component. the links made with<router-link> work fine and after i click any <router-link>, $router.push('/...') works again.
I started the app with vue 1.0 using another router, so i'm just beginning to change the <a> to <router-link>.
As @Yiiu said using $router.push({path: '/app', query: {redirect: 'test'}}); also works.
I'll try to create a jsfiddle asap to reproduce the problem.
I am able to produce the steps, please see below.
2.1.0
2.0.3 - using hash mode
https://jsfiddle.net/starkhorn/pz56e342/4/
The issue happens when the current browser hash is different from the one being redirected to (using a navigation guard). After the redirect, vue-router will not work when the browser hash changes.
I tried stepping through the code, it seems that, for some reason, the callback function that should add an event listener to window's hashchange event is skipped -- the transitionTo() gets called though.
history.transitionTo(getHash(), function () {
window.addEventListener('hashchange', function () {
history.onHashChange()
})
})
In the JSFiddle provided, if you change the initial hash to '#/login', vue-router will correctly listen to window's hashchange event.
Note: navigation using router-link still works though.
Seems to be a bug.