I'm currently using cookies to store my employee_id. This employee_id is needed as a params to one of my list in the navigation menu that will redirect them to a private page /private/:id. I read that users can edit browser cookies, thus can see other employee's private page.
I also tried vuex and sessions storage.
Does session storage have an expiration time?
Is it better to just store the id in the vuex store and call the setEmployeeID function in created() so even if the user refreshes, the data won't disappear since it is always using axios call to get the id?
Everything that gets to the client can be edited / viewed, including cookies, storage, etc.
If you have some info that you don't want to be exposed to another users - store it on server and do authentication. Do it using Vuex and you will be fine.
Session storage - is per tab and destroyed when the tab destroyed
Cookies - here is explanation regarding cookies securing: https://blog.dareboost.com/en/2019/03/secure-cookies-secure-httponly-flags/
Related
We have a Vue app that creates and manages user access to an API. We create API keys and display to the user, asking them to save it somewhere before leaving the page, since we only store the hashed version of it ourselves in our backend.
My question is: Since it is an API key that the user is allowed to have access to, is it ok to save the API key in the Vue store (until the next refresh), or could it somehow be accessed by a third party from there?
I know that if this were a JWT token it would be fine, but that has a
time limit which puts me more at ease.
I also know that generally a single page app should never store API keys anywhere, but I wonder whether that rule applies here since we don't have to hide it from the user, only 3rd parties
i have an old asp.net web-form based application, which i want to convert to Vuejs based front-end and Asp.Net Core base api as back-end.
The current application has a login page, where the user inputs his credentials, once the credentials got verified, user is taken to application home page, which has side menu bar.
The side menu bar is loaded based on the current users role/privilege. Say for example, a user with role of admin may have 10 menu items, while a normal user may have only 5 menu items.
I'm very new VUE, so pls guide me, how to set up the vue application and routing for above scenario.
Thanks in advance.
There are many ways to go about this, your goal is to load data about your user into your application.
One way to solve this is to create an API function that returns information about the currently logged on user.
The authentication of the request can be done through cookies, jwt header or something else.
The api call to get the authenticated user data will also help you figure out if the user is already logged on when the app starts up.
Putting aside how you make the network request, lets say you now have the data in your application.
There are a few choices on how to store it, this is an architecture choice as the results of this will likely have effect on many other parts of your application.
The common solution to storing application-wide (global) state is to use Vuex.
This will also play well together with vue-router.
Lets say that in Vuex you will make a field roles that will hold an array of strings, indicating the roles the user has.
In a vue component you can reach the vuex store from the $store property (this.$store in the code, $store in templates).
The state of the store is then reachable via $store.state, and your roles array would exist over at $store.state.roles.
To set the roles you will have to setup mutations that will let you save the roles, and the api call would be part of an action. You can read more about that on the vuex documentation on how to update the state.
I'm building my first 'bigger' web-app (only for learning purposes & my portfolio) with the vue.js-framework. I want to implement (for the fist ever time) the possibility to login using Google's API. My question is: where would I 'store' the user-obj? It should contain information like the user-id, name, email, ... . Would I store that obj in a Vuex store in my case? Or do I not even need to store such an object as the API provide all these information?
Well, it totally depends on the needs of your project and the information that is being stored.
If the information being returned in your user object doesn't contain any sensitive information that can be used by potential hijackers to steal other information then you could always store it in local storage, cookies or runtime variables in your code. Normally, vuex store is used for manipulating the local storage. This really helps when you are accessing the data from local storage via multiple components or nested components.
But if you have sensitive information being returned from the authentication authority, like the user id or user hash string then you might not want to store them in your local storage.
Additionally, you should only use this when:
You want to keep a track of user details even when the user closes and re-opens the browser
Passing the data set from one component to all other components is not really feasible
You need to keep the state of the data set synced in all components, so if it changes in one place, it will auto-reflect in the other place.
You need to frequently access the same dataset and it doesn't really change often, so as to avoid multiple api calls to back end server.
One scenario, I can think of is of the JWT token authentication. If you're not familiar with this approach, we usually authenticate the user and store his token in the local storage via vuex and all the api calls in all the components and views start using this same token as bearer token in the requests. When the token expires a new token is fetched and updated in local storage and the change is automatically reflected in all other places.
So it makes sense to check the needs of your project/code. If your project demands the use of the returned user object and it's safe to store it, please go ahead by all means!
I am managing performing a login and the login state using Vuex. It is a standard procedure of:
User submits their login details on a form
The form dispatches a Vuex action to make an axios API call to a Node/Express endpoint /api/login with the credentials
The response from the API if successful will send back the user's data which is stored in the state.user object through a setUser mutation. A flag of state.user.isLoggedIn is also set to true.
A JWT access token is sent to the user's browser and stored in a secure cookie to use over and over again until it expires. If it expires, a refresh token is used to generate a new JWT access token.
The site's header displays the user's login information .e.g name
The above all works as expected. However if the user refreshes their browser, then Vuex state gets emptied and the site header no longer shows the user information. To overcome this I stored state.user into localStorage in the browser as persisted data and repopulate the Vuex store using the data in localStorage on page refresh. If the user logs out, the localStorage is cleared.
There are many routes that require checking if the user is logged in. I cannot rely on localStorage because it can be manipulated by the user. If the user deletes their cookies which contains a JWT, then localStorage is not being emptied and the site header still displays their log-in information. Therefore I need to do an API call on almost every page to check if the user is logged in and if not then to delete the localStorage as well.
My question is:
Where do I perform a log-in check every time a page/view is accessed? Is it whenever the Vue app is mounted or within vue-router using the beforeEach navigation guard?
If I use beforeEach in vue-router, is it going to crash the site by making an API call to /api/login every time a user changes route? Is it normal practice to do this on every route?
Are there any other alternative patterns to keeping track of if the user is logged in or not?
Application decisions like this tend to be subjective because every application is different, with different requirements and different architectures. It sounds like this is a single page application, so I'll go from there.
First, the fact that your JWT is set up and working is great - that can be a lot of hard work, so be proud that you made it that far.
If your application has certain pages that are accessible without first being logged in (like a login page, or an access denied page, etc.), then you have to consider that in the design as well. In this case, a beforeEach route guard is the perfect solution to keep a route from loading or to catch those not-logged-in users before they attempt to request content that will likely just give them an error.
You probably shouldn't have to make an API call to the server each time the user navigates to a new page. That would probably be a little slow. Because your application uses JWT, complete with refresh tokens, you should be able to rely on them, so that if a user is logged in, they will continue to be logged in until they close their browser and walk away.
This is why you should not use localStorage. When a tab closes or even after a reboot, the user will still appear to be logged in. Instead of using localStorage, use sessionStorage - Helpful MDN link.
Now, the login event to retrieve the user object should only happen once per browser tab, but stay active during the visit.
I wonder why you don't just request a new user object from the server when the browser is refreshed. It's not strange to force a re-check to the server for a full page load. Doing that would mean you wouldn't have to use anything outside of Vuex to store the user's state
Next, is there a way to check the validity of their JWT during the navigation event? Depending on the way you handle the JWT, you may have access to it, and can possibly decode it (like through the oidc-client-js library), and that way determine for yourself if the token is expired. However, if the token is expired, your token refresh system may just refresh it and not tell you about it.
You can also watch your HTTP requests and look out for 401 or 403 responses (however your back-end handles logged-out users), and direct the user back to the login screen if you see one of those. You can use Axios' global interceptors to catch them, or do it yourself if you centralized the location from where Axios is called.
Overall, you're on your way, and clearly have a good grasp on this. Great progress so far, having done probably 90% of the heavy lifting already.
So i was thinking, what is the best practices when it comes to building front end that need to talk alot to an api backend.
My scenario, iam building frontend with vue that consumes a node, express api as backend. A simple todo app.
Right now i do this.
User log in and all todos, categories, and userinfo is fetched and saved in my vuex store
if user close page and open it again or reloads the page the vuex store resets ofc so i check if the user is still loggedin then i fetch all data again and save it in my vuex store the same way as i do when a user logging in.
user can now browse around the app and no need to call api because the store has all data the frontend needs. this saves a lot of API calls ofc.
if user creates a new or edit some todo, category or userinfo i send it to the api and once again fetching all data again like i do when user logging in.
So this way the store always has the correct data. And it works ofc, but iam thinking that it only works good for small applications. So if my user starts adding 10000s of todos and categories it would be a lot of data to fetch and save in the store.
So is the best practice to only fetch data from api when user needs it in the frontend like showing todos or categories but that would also require a lot more api calls?