I am using Angular2 & Auth0 to Authenticate a user.
Currently, according to their "best-practice" , the user profile is saved to localStorage , and once you need to pull information, take it from there.
This sounds like a bad practice to me, is there a better way to keep logged in profile for local query (name, photo etc.)? maybe using an Angular2 service?
The problem is if you want to keep the user profile for later use (if the user close the window and reopen it later) without having to make request to a server. Then you need to store it somewhere.
And storage facilities in the browser are quite limited: IndexedDB for database storage with query capabilities, indexes, etc, localStorage for simple key=>value storage,or even cookie for a limited amount of data as plain-text.
but if you don't need the data for a later use, you can keep it in memory (in a service, for example).
You can also combine both in-memory and offline-storage in a service.
You can combine both ways.
Storing it in localstorage to get that infos without request them anytime and wrapping a Service around it to not address the storage from everywhere.
Related
Is there any rule regarding when to use local storage or not to store state information if I have redux?
For example if I have some online form, then
Q1. should I have its state (currently filled values) persisted to localstorage say when user closes tab or browser, so that I can reload the state in redux from localstorage when user revisits the webpage? Is there any well know / documented security consideration for storing redux state in local storage?
Q2. Or should I always send last saved redux state from the server (and not save and load from localstorage) when user visits the website first time after opening the browser. If that is the case
Q3. If the answer to Q2 is YES, then what about JWT? Should we store JWT in localstorage avoiding forcing user to re-login?
Q1
In terms of OAuth Best Current Practice I would avoid storing anything like this in local storage:
Credit card numbers
Passwords
Access tokens
Personally identifiable information, eg name, email
Use browser storage for simple data such as the application path before an OAuth redirect, or simple boolean preferences. Prefer session storage over local storage, unless you need settings across multiple browser tabs.
Q2
Using the server is safest for anything sensitive, so it is worth investing in an API driven save and load option.
Q3
Avoid JWTs in local storage, since there are more attack vectors that could result in stolen data. If you are migrating from this model then start by storing a refresh token in an encrypted HTTP Only SameSite=strict cookie, and store access tokens only in memory.
This will enable you to avoid logins on page reloads or when the user opens a new browser tab, and is easy to implement by routing token requests via a utility API. You could then go further to take access tokens out of the browser completely. See the SPA Best Practices article for further related details.
It depends.
Q1. If it's non-updating data and you don't need to make request to backend for it. You can use localstorage.
Security Issue with localstorage is that user can access it and alter or delete the data. In that case you again need to hit your api for data.
Q2. If the data is updating (eg - posts,likes in blog app). Then you need to make a request to server to fetch the latest data.
Q3. Yes, mostly jwt is stored in localStorage which avoid user to re-login. If the user try to alter the jwt, the backend has methods to check it. read How jwt works
I am trying to keep values for a page over user interaction. I know I can do it using cookie and local storage. But I am curious to know that is there any way to do it without using cookie and local storage. If it is possible then how?
Actually I am asking to do it without any storage.
Update url for each action made by user so you can retain the parameters you want on page reload, I don't think we have any other way
IndexedDB is another option for client-side storage. Its API is a bit complex though, so to use it, you might want a library like localForage instead.
Another option is to save the values by saving them in a database on the server, though for reliable retrieval without storing any information client-side, the user will have to be able to input something unique to them (such as username/password - the server checking their IP addresses likely won't be enough, since IP addresses are often shared)
i want my all check boxes checked whenever i come back from other pages, i want to maintain their states across pages using javascript.
I think you are asking how to store state for an individual session between requests. In this case, that state is checkbox values.
You have a choice to make first: do you want to store the data on the client (in the browser) or on your server?
Server Side
You can store this state on the server side with or without a "database" depending on how pedantic you want to be about the term.
If what you want is to avoid configuring an SQL RDBMS, you might find that the built-in storage options from most Java Servlet containers will work. In Tomcat, you can just use your Session objects as normal, but configure a "File Based Store" instead of a "JDBC Based Store." This will store session data to disk in files. Alternatively you can use StandardManager which uses in-memory storage, but does not persist session state across restarts.
Put simply, these will create a Java Map for each JSESSIONID issued by your server, and then keep the maps in memory, on disk, or in a JDBC database. For more information see: https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html
Client Side
Here you have a few options as well. The driving factor is what level of browser you wish to support. If you can tolerate restricting your users to those who use a browser with HTML5 web storage and JavaScript enabled, things are pretty easy. If not, you can accomplish the same thing with a cookie.
The big downside to client-side storage is trust. Users (or software on their computer) can modify client-side storage. This goes for cookies, localStorage, and sessionStorage. Many developers forget this and introduce security vulnerabilities because of it. If this is for a real production web application, you'll want to wrap your state in an authenticator.
Here's a the first in a three article series on a way to convince your servlet container to put session state into cookies in a way that is transparent to your servlets. It is missing authentication, but you can add it by following guidance such as this bit from Rob Winch.
Now What?
Ok. You've decided to use client- or server-side storage for your checkbox values. Now what?
A simple (usually wrong) option is to store the checkbox input names and values in a map:
{"boxFoo": true,"BarBox":false}
The reason this is usually wrong is that it fails to distinguish which form your user was visiting. It means that if you apply this strategy to more than one form on your site, you'll have to worry about name collisions.
The next evolution is to have a structure keyed by form name and then field name. This would be a map like the following:
{ "formA": {"boxFoo": true,"BarBox":false},
"formQ": {"checkAlpha":true,"BetaCheck":false } }
This works, but will have annoying behavior when your users use multiple tabs. You can make that behavior more predictable for your users by using per-tab identifiers -- at the expense of space in your session object -- or by using AJAX to keep the fields in sync -- which has its own perils. Or you can do what most people do an just assume that the last submitted form overwrites the state from all previous ones, tabs be damned. That's much simpler to code, but more annoying to users.
I can propose some ways :
send http params (in hidden field) with check boxes flags which must stay checked in each new page requested by your application . You can factorize it with a function but it stays cumbersome to do.
store the check boxes marker flag in the http session. If the check boxes must stay checked in all the life of your user, it may be a suitable solution. Use may use a backing bean session for it as you use JSF.
Nevertheless, store the minimum of information in it.
store the information in a shared applicative cache to retrieve it. In this way, you stay stateless and you have not the drawback of the session if you use clustering in your servers.
There is maybe better as alternative.
You have to bind the value with a backing bean. As long as the backing bean is having the appropriate scope it will be retained on the page when you navigate to it.
I'm trying to make a basic social networking application following Write Modern Web Apps with the MEAN Stack book.
The end result should be: https://mean-sample.herokuapp.com/
I got through to getting user accounts set up, having a user log in and create a personalized post. But as soon as I refresh, the user gets logged out.
What am I doing wrong? And how do I fix this?
In the client side we cant maintain the session, we need the server support to it. There are many ways to maintain the session
1 Token based, for each request to the server, the server will check whether token exists or not.
2 We can store in the localstorage while refresh the rootscope will be, at that time we can take from local store and populate the page objects.
Maintaining in server side is secured and advisable.
use localstorage, it will help you in maintaining the session and also store user details temporarily.
Refer this for more details
https://github.com/grevory/angular-local-storage
In javascript, is there a clear and concise substitute for cookies? I am currently storing game saves in cookies, and looking for a way to make them harder to accidentally (or purposely) delete.
There are really not that many places to store data. You can really store it in two places:
The client's machine: There are other options besides cookies, but they are just as likely to be cleared if the user wishes. Cookies are probably still the easiest way to go about this.
Your server: You could create some login system or other to store the data locally and then determine what saved data corresponds to which client.
I still think your best option here is to use cookies. Most games rely on cookies or browser saved data anyways and clearing that within the browser deletes progress.
If you really do not like cookies:
With the introduction of HTML5 you can now save data within the browser, for more information see here: http://www.sitepoint.com/html5-web-storage/. This could allow for more data to be saved and speed up the requests, but also will probably get cleared if the user clears their cookies.