I am building a Vuejs app with authentication.
When the page is loaded and I initialise the app Vuejs instance, I am using beforeCreate hook to set up the user object. I load a JWT from localStorage and send it to the backend for verification.
The issue is that this is an async call, and the components of this app object (the navbar, the views etc.) are being initialised with the empty user data before the call returns the result of the verification.
What is the best practice to delay the initialisation of child components until a promise object resolves?
Here is what I have in my Vue app object:
beforeCreate: function(){
// If token or name is not set, unset user client
var userToken = localStorage.userToken;
var userName = localStorage.userName;
if (userToken == undefined || userName == undefined) {
StoreInstance.commit('unsetUserClient');
// I WANT TO RESOLVE HERE
return;
}
// If token and name is set, verify token
// This one makes an HTTP request
StoreInstance.dispatch({type: 'verifyToken', token: userToken}).then((response) => {
// I WANT TO RESOLVE HERE
}, (fail) => {
// I WANT TO RESOLVE HERE
})
}
The current lifecycle callbacks are functions without any promises/async behaviour. Unfortunately, there does not appear to be a way to cause the app to "pause" while you load data. Instead, you might want to start the load in the beforeCreate function and set a flag, display a loading screen/skeleton with empty data, flip the flag when the data has loaded, and then render the appropriate component.
Related
I'm building a Vue 3 app which uses Vue Router and Pinia for state management.
In my global state I'm defining a property which tells me if a user is logged in so the user can navigate through the app. However, the login process is being handled by Cognito, so once I enter the app, I click on the login button, it takes me to a Cognito screen which handles the login process and then redirects me back to my app's home page.
So after the redirect I extract some params from the resulting URL and I want to save them in the global state, for this I was using the beforeEach guard to parse the URL, check for the params, update the store and then reading from it to check the valid session.
But my issue was that the navigation continued even before the state was updated. I ended up using setTimeout just to see if waiting for a bit solved the issue and it did
router.beforeEach((to) => {
const mainStore = useMainStore();
if (to.name === 'Login') {
return;
}
if (to.hash !== '') {
const queryParams = window.location.href.split('&');
const paramValues = queryParams.map(param => {
})
const payload = {
id_token: paramValues.find(param => param.name === 'id_token').value,
access_token: paramValues.find(param => param.name === 'access_token').value,
token_type: paramValues.find(param => param.name === 'token_type').value,
isAuthenticated: true
}
//Here I'm trying to update my global state
mainStore.updateTokens(payload);
}
// Here I use timeout, but before I just had the check for the property
setTimeout(() => {
if (!mainStore.isAuthenticated) return '/login';
}, 3000)
});
How should I handled this case? I've read about the beforeResolve guard but I'm not sure on how to use it; basically I just need to know how should I go about performing some async operation (like fetching data from server) during the navigation, not inside components.
We've got a SaaS app that's PWA capable and we're using Workbox for the grunt work. Up to now we've been following the tried and trusted recipe of displaying an update is available banner to the users, prompting them to update their web app.
Viewing usage data (via Sentry.io) we've noticed that most users simply seem to ignore the update banner and continue with the version they're on.
So we're looking at trying something different. This is to perform the update automatically when they change the route in the web app (when we know there's an update available).
Testing this shows that it does work. However there's a side-effect, and that is if they've got web app open in multiple tabs, then all the tabs get updated. This could be problematic for users' if they've got an un-saved form open in one of the tabs in the background - they'll potentially loose their work.
This happens during this piece of code:
// app shell page, created lifecycle hook
document.addEventListener('swUpdated', this.SetPwaRegistration, { once: true })
navigator.serviceWorker.addEventListener('controllerchange', () => {
if (this.refreshing) {
return
}
this.refreshing = true
window.location.reload()
})
// app shell page, method in methods collection
SetPwaRegistration (event) {
// call mutation to pass the registration object to Vuex
this.PWA_REGISTRATION_SET({ pwaRegistration: event.detail })
}
// main.js
router.afterEach((to, from) => {
// retrieve the registration object from Vuex
const pwaRegistration = app.$store.getters.pwaRegistration
if (pwaRegistration) {
pwaRegistration.waiting.postMessage('skipWaiting')
}
})
the above code is from our Vue.js app code-base, the this.refreshing is set to false by default in the data property collection.
What I'd like to know if whether it is possible to determine if the Service Worker has only one client under it's control (i.e. the web app is only open in 1 browser tab), and if this is the case, the auto-update can happen without potential issues. If there's more than one client, then we'll display the update banner as usual.
As a brief update to this, I've come across code examples similar to this:
self.clients.matchAll().then(clients => {
const clientCount = clients.length
// store count of client in Vuex
})
Which looks like an option (i.e. count how many clients there are, store this in Vuex store), I'm just not sure where it should be used.
If you want to orchestrate the reload from entirely within the service worker, you can effectively do that by using the WindowClient interface to programmatically navigate to whatever the current URL is, which is roughly equivalent to a reload.
The two things to keep in in mind that navigate() will only work on WindowClients (not Workers) and that you can only call it if the service worker controls the WindowClient.
Putting that together, here's something to try:
// This can be run, e.g., in a `message` handler in your SW:
self.clients.matchAll({
// These options are actually the defaults, but just
// to be explicit:
includeUncontrolled: false,
type: 'window',
}).then((clients) => {
if (clients.length === 1) {
clients[0].navigate(clients[0].url);
}
})
I am trying to set up an authentication on my web application in React using firebase and Context API.
I am using Context API since as long as I understood I cannot save my jwt token in local storage in order to not be vulnerable to XSS attack and at the moment I do not want to use Redux.
in my App.js I have:
const {setUserInfo} = useContext(userInfoContext);
useEffect(() => {
auth.onAuthStateChanged(user => {
if (user) {
setUserInfo({jwtToken: user.za});
} else {
setUserInfo({jwtToken: null});
}
console.log(user);
});
}, [setUserInfo]);
The methos "auth.onAuthStateChanged" is triggered every time I logged in or I logged out using firebase.auth.
The compiler tell me that to eliminate the warning I should have "[setUserInfo]" instead of "[]". However, doing as he say, the method setUserInfo is executed twice. There is a better way to achieve the result without a warning?
Your problem is that you don't clean up your effect when it is recomputed. As soon as you add setUserInfo to the dependency array, the effect is executed whenever its value changes. This means that you could potentially register many auth.onAuthStateChanged if the value of setUserInfo changes.
auth.onAuthStateChanged returns an unsubscribe function. You can simply return this function inside your effect, which will make react execute the unsubscribe function whenever the hook is executed again and prevent you from having multiple active listeners. I suggest you read more about this topic here.
I have a cart page written with VueJs and Vuex. I have an api file that acts as a wrapper around axios.
In my vuex action, I call the API and if it was successful I commit data into my mutation.
async await mounted () {
const result = this.getStatus()
if (result === "locked") {
this.$router.push({name: "LockedPage"}
}
else if (result === "expired") {
this.$router.push({name: "SessionExpiredPage"}
}
doSomething(result)
},
methods: {
function doSomething(res) {
// does something with result
}
}
The getStatus function here is from my vuex action.
const {authid, authpwd} = router.history.current.params
if (!authid || !authpwd) {
router.push({name: "SomethingWrong"})
return
}
const res = await api.getStatus
commit("SET_STATUS", res.status)
if (res.otherLogic) {
//commit or trigger other actions
}
return status
}
What's the ideal way to handle these kind of API errors? If you look you'll see that I'm routing inside the Outer component's mounted hook as well as inside the vuex action itself. Should all the routing for this status function just happen inside the vuex action?
I think how it is currently set up, when theSomethingWrong page get's routed. It'll return execution back to the mounted function still. So technically the doSomething function can still be called but I guess with undefined values. This seems kind of bad. Is there a way to stop code execution after we route the user to the error page? Would it be better to throw an error after routing the page?
Should I use Vue.config.errorHandler = function (err, vm, info) to catch these custom route erorrs I throw from the vuex action?
For general errors like expired session I would recommend handle it low at axios level, using interceptor. https://github.com/axios/axios#interceptors
Interceptors can be defined eg. in plugins. Adding Nuxt plugin as example (Vue without Nuxt will use little bit different plugin definition, but still it should be useful as inspiration) (Also window is access because snippet is from SPA application - no server side rendering)
export default ({ $axios, redirect }) => {
$axios.onError((error) => {
const code = parseInt(error.response && error.response.status)
if (code === 401) {
// don't use route path, because error is happending before transition is completed
if (!window.localStorage.getItem('auth.redirect')) {
window.localStorage.setItem('auth.redirect', window.location.pathname)
}
redirect('/login-page')
}
})
}
I have a Vue SPA based on one of Auth0's quickstart apps (https://github.com/auth0-samples/auth0-vue-samples). Everything works fine out of the box, but as soon as I try using the Auth0 client in my component code I run into problems. I followed the "Calling an API" tutorial (https://auth0.com/docs/quickstart/spa/vuejs/02-calling-an-api), which unhelpfully only shows how to call an API using a button. What I want to do is trigger an authenticated call to my API on initial page load so that I can ensure certain data exists in my own API (or create it if it does not). This seems like it should be pretty straightforward. I just throw this code in my created hook of my Vue component:
await this.$auth.getTokenSilently().then((authToken) => {
// reach out to my API using authToken
});
This actually works fine if the app hot reloads from my npm dev server, it reaches out to my API, which authorizes the request using the token, and sends back the correct data. The problem is when I manually reload the page, which causes this:
Uncaught (in promise) TypeError: Cannot read property 'getTokenSilently' of null
at Vue.getTokenSilently (authWrapper.js?de49:65)
at _callee$ (App.vue?234e:49)
Inside the authWrapper.js file (where the Auth0 client lives), the function call is here:
getTokenSilently(o) {
return this.auth0Client.getTokenSilently(o);
}
When I debug the call, "auth0Client" doesn't exist, which is why it's failing. What I can't understand is the correct way to ensure it does exist before I attempt to make the call. There's nothing in the samples that indicates the right way to do this. I tried putting my component code in different components and different Vue lifecycle hooks (created, beforeMount, mounted, etc), all with the same result. The client becomes available after 800 ms or so, but not when this code executes.
This is clearly a timing problem, but it's not clear to me how to tell my component code to sit and wait until this.auth0Client is non-null without doing something horrible and hacky like a setInterval.
I figured out a workaround for now, which I'll add as an answer in case anyone else has this issue, although it's not really the answer I want. Per the authGuard, you can use the exported "instance" from the authWrapper and watch its "loading" flag before executing your code that depends on the auth0Client being ready, like this:
import { getInstance } from "./auth/authWrapper";
// ... Vue component:
created() {
this.init(this.doSomethingWithAuth0Client);
},
methods: {
init(fn) {
// have to do this nonsense to make sure auth0Client is ready
var instance = getInstance();
instance.$watch("loading", loading => {
if (loading === false) {
fn(instance);
}
});
},
async doSomethingWithAuth0Client(instance) {
await instance.getTokenSilently().then((authToken) => {
// do authorized API calls with auth0 authToken here
});
}
}
It's hardly ideal, but it does work.