I'm working on a React web app where a user can create an account, which would contain the user's contact info (phone, email, address). When a user signs in, their account info should be accessible to them.
How is this information typically acquired/stored on the client side in React? Here's what I'm thinking:
Once the user logs in, the application fetches the user's account
info (using the fetch API, for instance)
That account info can then be saved
in the app's state, perhaps using Redux.
Is it up to the app to fetch the account info after login, or is it up to the server to automatically send that data to the client? And is Redux an appropriate tool for storing this sort of data, or is this something that localStorage is supposed to handle?
The data fetching happens on the client side (React). You generally keep track if the user signed in or not in your local state or redux. Let's say you're using firebase as your backend service then the method below (generally should be placed inside the component which requires user authentication info ) automatically keeps track of auth status change.
firebase.auth().onAuthStateChanged(function(user) {
if (user) { // you can pass this info to local state or redux
// User is signed in.
} else {
// No user is signed in.
}
});
https://firebase.google.com/docs/auth/web/manage-users
One way to tackle your case is that, once you get the user info from the backend, you store that in the local state or send it to action creator to store in redux.
Resource: https://blog.logrocket.com/getting-started-react-redux-firebase/
Is it up to the app to fetch the account info after login, or is it up to the server to automatically send that data to the client?
Yes the app should fetch this after logging in.
is Redux an appropriate tool for storing this sort of data, or is this something that localStorage is supposed to handle?
Yes definitely Redux instead of localStorage, or just use react's global state management.
Related
My app renders components and layout based on user permissions. Permissions are created dynamically. (permissions are basically what are the modules and actions that a user can do.
e.g: The user can delete records, update records, can view settings tab, etc
Permission Keys are coming from the backend. when the user hit the login API.
Should I use context to pass through the component tree?
What if the page refreshes? Then I need to call the API again to get permissions? should I need to store it in the session/local but a user can update and change the data in session/local storage also it is not secure. What should I do?
I would like to store the payload of REST API calls made by a user in frontend and be able to make the calls to recreate what the user did (like a replay button)
I have the following scenario:
User opens website.
User picks a product and configures it.
How can I store the REST API calls payload from frontend: Is there a framework that does that? Which database should I use?
You can implements it by state management.
I think the user data shoud be stored firstly in some state in front-end by using a Redux library for example.
Finally you can send the data for a data base (MongoDb for example) to persist the data stored in Redux state.
So, in terms of Data base use, that depends on if you need that data, even when the user close the browser.
I want your advice on the best practice for storing and reusing user data in my application.
I created two apps:
the first is an API to recover data
the second is a Vue.js application for the front-end part
I am using a JWT for authentication.
When I am authenticated, I save two elements in the cookies:
token
userId
In the Vue.js application, as long as the token exists in the cookie, the user remains authenticated, the verification is done on each new route for the front-end.
In the back-end each route waits for a valid token.
I want to create a navbar with the name of the person connected at the top right, and their profile photo for example.
This navbar appears on all pages.
For the moment in my "navbar" component I have set up an api request with the userId present in the cookie to retrieve user information.
I don't think it's a good practice to do this on all pages? Perhaps the best will be to store this information directly in cookies to retrieve it more easily?
I'm having trouble knowing what to store and what not to store cookies.
For example I will not store a user object containing its creation date, email address, etc.
I currently have a React-Redux Application.
I want to create an admin user in React-Redux.
If I create a state with userAdmin true or false will users be able to access the state and change this value? That is to say, is this a secure method of creating such access?
I am using webpack to create a bundle.js, and have a node.js server for serving data that is secured using JWTs.
Furthermore, is there a standard or semi-standard pattern for creating an admin user in a react-redux application?
My thoughts on this are:
Create a separate app for admin user management.
Create a state for the admin user and if that state is true then query the serverAPI for any admin action. But show the admin capability only if that state is true eg. delete other users, view details of users, but do not serve that data without an authorised API call. Then if the state is changed surreptitiously the user can only see the actions but is not able to access the API without the required authorisation.
tldr: your thoughts are correct
You are right in the assumption that the user could manipulate the state of the client side app to escalate her privileges. However, that shouldn't give any useful benefits if your architecture is done right.
Data that only admins should have access to shouldn't be transmitted to a regular user in the first place and changes that only admins should be able to do should only be accepted with JWTs that identify admin users.
Right management is something that has to happen server side. The client app just reflects that in the UI.
I am writing a web app with Backbone.js and require.js that needs to store user information to use throughout the app when the user login. Currently, when the user submits there credentials a web service authenticates the user and returns data about that user. Traditionally I could then store that information in a session. How can I accomplish this using Backbone?
You might want to use HTML5 SessionStorage for that. Have a look at this SessionStorageAdpater for backbone integration.
Typically one stores authentication information in an encrypted cookie that is sent to the server on each request. This is essentially a value that correlates the logged in user to the web server's identity store.
You are probably more interested in profile data (i.e. metadata about the user - firstname, birthday, etc). Once the user has logged in, when the page loads, fetch the profile data about the current user via an ajax call to the server (the request would include the auth cookie, which the web framework would use to find the currently logged in user). So you should expose a route on your web app that returns a json data structure containing the profile data your app requires about the current user.
I am currently in the process of writing a large Backbone / Marionette application. I'm storing the user information (not password or another like that) in a model called user. I then use this model to first validate the user by checking the sessionid.
// before every request
if (app.Core.models.user.get('sessionid') != "") {
// then I run the code. Authentication can still fail on the server.
} else {
// trigger the event to bring up the sign in page
app.vent.trigger('App:Core:Login');
}
After the user logs into the application, I save the information I received from the authentication inside the app.Core.models.user model. Since my authentication does not return a full user name, I make a separate ajax call to retrieve this information and store that information in the model too. I then tie the model to a section of my page that automatically updates the user name in the header of the page.
The browser automatically stores an encrypted cookie so I don't have to send any of this information back to the server.