How can i persist user details in angularjs unless user logs out of the system?
My header is using a variable called user, so when the user logs in successfully, i set the user attributes from REST response.Once , user is set then using ng:show and $scope.watch i change parts of the header and show welcome 'username'.
The issue comes when user again refreshes the page, in that case User is reset and user sees the landing page header.How can i correct it?How can i persist the User value unless user logs out of the system?Should i set user in rootScope or is there any other better way to handle this?
This is an open-ended question and to really answer it, I'd need to know what your back end looks like and what your security requirements are.
I can see a two ways forward:
(1) If can rely on and trust cookies for security, you could just log the user in with data from cookies just like you log them in via the REST response. The cool thing about this is that, to the user, it would be instantaneous (the next option won't be).
(2) Have a separate controller that handles the header that will always make a request to the server for user data (logged in or not). SEN does something like this (and it drives me crazy btw). I don't know if you have a SEN account, but if you do, you could log in/out and try it out. You'll see that when you hit the page initially, you get a loading screen, but even after that loads, the header even has a little "Signing in..." loading widget itself.
You can use the local storage (a key-value pair HTML5 storage) to store the information and retrieve it on page load. There is a very simple library for this, if you don't want to write javascript yourself, called Lawnchair. Otherwise google for html5 local storage tutorials.
Related
I built an app with authentication, and upon navigation to private route, I'm checking in the redux store if user object exist. when reloading the page, obviously the store clears. I thought of persist-state solution with redux-storage , but I see that the data is being stored in the LocalStorage.
is it safe that all data is being shown there? information like user id, name, email, etc..
Thanks
Do not store plaintext values (user name, id, password etc.) in localstorage. Assume the following:
Someone with access to the physical machine: he can either grab the Chrome profile files, containing my localstorage, or he can open Dev Tools in my browser and see stuff he shouldn't.
A malicious browser (or app with a browser control) can gain access, by getting you to browse to the site and copying the values.
Never rely in your app on info you got back from localstorage. Assume someone manipulated it. Crass, imaginary example: if you store my cart total in localstorage, to save time on recalculating it later, assume I changed it to a lower number on the client.
Finally, assume some of your users will use a private tab to browse to your site, at which point you wont be able to utilize localstorage. So why not design to work without it?
In a regular web app, when someone logs into the system they simply save an encrypted cookie that gets send on each request and the backend decrypts the cookie and uses the e.g. user_id/guid to lookup the user.
How do things differ when authenticating with a angular app?
Is there anything else to consider or it is basically the same process?
We use more or less the same mechanism.
Access to the application as a whole requires authentication - that is unless you're logged in, you don't get any of the javascript experience at all. This could make the login / login failure much less wizzy for the user, but in our authentication provider it's fine.
Part of our auth mechanism means the list of roles that the user has is a data object available within the browser. The javascript code uses this to decide which buttons / menus etc. are displayed. I checked with our security guy and he said something like "Well, it's a kind of direct object reference issue, but as long as each action is authorised properly, you're probably ok." So it's possible that a user could hack data values and change what they can see, but because of the next bit, they can't break our data (or see stuff that they shouldn't).
Each service call our javascript makes is authenticated and authorised. That is, the javascript call will fail if the auth token is missing or bad, but also, we internally match the auth token with a user and a set of permissions, and only execute that if the user is authorised to do so. (Note that this is good practice whether you're using Angular or not). Also note that this applies to GETs as well as POSTs - we don't want to give them data they should not see.
It gets much trickier if your API is hosted separately from your Angular site.
I am building an sample application that lets user store comments.
I've created the registration and login process. When the user registers, his details are stored in a MySQL database and a token is returned to the browser. Now he can access the Profile page.
When an existing user logs in he is redirected to the profile page. The profile page is accessible only when a user registers or logs in.
After logging in, I want to show all his comments if he has already added them.
My frontend is in Angular and backend use Laravel. For authentication I use Satellizer.
I want to know, what is the best approach while playing with data, considering the fact that the user will add, edit his comments. Should I use localstorage and store data in a key value pair or should I create a json file which gets updated everytime the user adds a comment or makes a change.
I wanted to know what is the most efficient way to deal with data from server so that the application is fast even when it scales to a 10000 users and lot of data for each user.
Thanks
You should be updating it on the server when changes are made rather than only relying on localstorage. You can use localstorage to cache, but it should only be for immutable data, it shouldn't really be used for data that is going to change.
So in this case you'll be adding and updating new comments via your API (ideally a RESTful one!). Once you've made a change, you could store the comments locally and only update them when the user makes a new comment, however you'll quickly run into issues where the data is invalid on different clients. (i.e. if you update the comments on a different computer, the other computer won't be aware).
Alternatively, you could cache the comments and then simply ping the server to find out if new comments have been added. This could be using a HEAD request for example to check the last modified date on your comments resource.
You can store comments data locally on user browser, but you should properly manage it.
I don't how much load your server will have and if the time invested now worths it.
You can fetch comments and store them locally
User adds a comment, then you update locally and send a request to the server
You need to track the request response, if requests fail so notify user and remove comments from local.
if request was successful so you can continue on your way.
** facebook uses this "success first" approach
user does an action, and he see it happens instantly, in the background it could take few seconds, only if it fails they will notify you.
** look at their commenting process, when you comment, it appears instantly, no loading... but in the BG the load happens.
I have a hotel page with information about a hotel and when you click book you go to a booking page.
When you get to the booking page you will then be asked for name details etc.
However I need to pass other data from the hotel page to it such as a summary of the hotel and the room configration as a confirmation before they book(so I need this data again).
My question is if the user refreshes the page?
Will using $state or UIrouter or having the data as a service cause the data to be lost? Like flash or non persistent data?
If so would I be better when the user clicks the button it saves it as a session cookie in which I can pick it up on the next page?
It will. You need to persist the information somewhere durable. Either send it to the server, or store it client side using localStorage or something similar.
Refreshing the browser is like restarting the app, only it (if you designed your application correctly) pick up in the same location you were at. However, all information is wiped, except for durable stores like local data, cookies, local database, and obviously it won't affect the server.
So choose the most appropriate durable store based on your application's needs.
I have an angularjs app that is on a separate domain than my backend, and the users from my backend all have roles and permissions that allow them access to various areas and elements of my frontend.
Before, I was just storing to a cookie and checking as I needed through the use of angular services and whatnot, cool.
Now the permissions datum have reached the point where they are too big to store in a cookie in the browser. And I'm avoiding Localstorage for fear of user tampering.
The Question:
How do I store the users sensitive data (or anything sensitive, really) that are too big for cookies on the client side in a manner that is safe and doesn't require API calls all the time to get?
I don't want to have to phone home every page change to get this data direct from the server when I need it, because I feel this would be really detrimental to the speed and flow of the site, not to mention the frequency at which this would need to happen would be ridiculous for my app.
Keep in mind that I do proper permission checking on the backend before carrying out any actions, but I'm more concerned about users tampering with their permissions to show certain elements that were removed on the frontside before.
What would be your solution or your advice on this?
If it ends up on the user's computer, regardless of whether it's in a cookie, in local storage, in the URL, in the browser's cache, or anywhere else on the user's computer, assume that the user can see it and mess with it. (You could encrypt it, but if your client-side logic knows how to decrypt it, you're back to step one.)
The best that you can do is exactly what you've described - be sure that the server only carries out authorized actions, and never trusts what the user tells it.