Recently, I am working with Meteor.js and the problem arise from my development is how to use persist session for Meteor.js.
I have worked with Meteor session and it removed when I am refresh the site. So I realized I need to do something for my session.
I have worked with google and all of them I found out about the persist session is using localStorage.
If I use localStorage, my session should not been working on IE because IE doesn't support localStorage.
Is there any suggestion for my problem?
Thanks for your kind attention.
You can use ground db which also allows you client side offline content and thus makes your session data persistent on your users devices. This comes in handy if you want to have your clients manage the persistence storage while still being able to manage complex sets of data caching.
If this does not suit your needs, you could create a collection that acts as your session. The advantage is here that persistence is kept beyond client influence on the server. The hurdle is, that you need to implement a steady session-get-set mechanism with lots of Method calls and data updates.
A schema for this session could be:
{
userId:String,
state:{
type:Object,
backbox:true,
}
}
The blackbox attribute allows you to bypass validation and make this collection very flexible for use as session storage. Disadvantage is that it can create a security flaw because the incoming data is not validated by collection2-core (if you use it). You have to validate your variables yourself then.
I would prefer #Jankapunkt's approach, but just to put it out there, there is this unsupported package that does the job of persisting session variables over browser refreshes.
Eg: Session.set(key, value)
Related
Creating a project with JS and .net. which needs to work even in offline mode.
As I can see service worker can be used to cache static assets and can work offline, but we
can't save data to Database. Please let me know if the service worker can save data also.
Is there any better approach to making the website work in offline mode and save data somewhere and pass it to the database when online? The saved data should not be cleared when the user closes the browser
In theory you can use a localstorage to permanently save data. I suggest that you do not save sensitive information within it or that could, in the wrong hands allow unwanted access to your services and create problems for you.
You can find information about how it works here. You will find simple examples for its full use.
https://it.javascript.info/localstorage
However, making an app work fully without an Internet connection can be complex and should be analyzed in each precise circumstance. Any change operations to the database could be parked in the localstorage and provide for a worker to make the calls when the network returns. It is not simple what you asked and I cannot help you further.
You also need to understand how to handle getting information from a Database if you have no connection. Some functionality will have to be suppressed while for "static" obtainments you might think about caching (as also said by you).
You can use localStorage to save data to the browser even when in offline mode.
See MDN reference
Offline persistence in Firestore enables the browser to store records that were not uploaded to the server (offline) even after the session was closed (Browser exit)
Please see: https://firebase.google.com/docs/firestore/manage-data/enable-offline
However, firestore does not offer any officially supported way to clear the Chace when a user logs out from his session. Please refer to: https://youtu.be/qGAIimfrBB4?t=257
Recently they released the function clearPersistence, but they clearly state that is not meant for security reasons and recommend to disable Persistence if security is an important factor for you. Please see: https://firebase.google.com/docs/reference/android/com/google/firebase/firestore/FirebaseFirestore#clearPersistence()
Note: clearPersistence() is primarily intended to help write reliable
tests that use Cloud Firestore. It uses an efficient mechanism for
dropping existing data but does not attempt to securely overwrite or
otherwise make cached data unrecoverable. For applications that are
sensitive to the disclosure of cached data in between user sessions,
we strongly recommend not enabling persistence at all.
I want to understand better what's the security hole with using "ClearPersistence" on logout of the user.
Anyone experienced with that? Any other working solution that enables you to remove all the Firestore cache after a logout?
There is no guarantee that your code will run in the browser (or any other client). For example: a malicious user can take the configuration data from your application, and call the API to get access to the same data in your project, but then store it wherever they want.
Another malicious user might prevent the app from clearing the local cache, or quickly copy the local cache file to another location to have a copy before it is cleared.
And these are just two if the simplest examples. The simple fact is that you should assume that any data that exists/persists on the client can be seen by any user who has access to that client.
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.
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.
In our application, we are painting navigation component using JavaScript/jQuery and because of authorization, this involves complex logic.
Navigation component is required on almost all authenticated pages, hence whenever user navigates from one page to another, the complex logic is repeated on every page.
I am sure that under particular conditions the results of such complex calculations will not change for a certain period, hence I feel recalculation is unnecessary under those conditions.
So I want to store/cache the results at browser/client side. One of the solution I feel would be creating a cookie with the results.
I need suggestions if it is a good approach. If not, what else can I do here?
If you can rely on modern browsers HTML 5 web strorage options are a good bet.
http://www.html5rocks.com/en/features/storage
Quote from above
There are several reasons to use client-side storage. First, you can
make your app work when the user is offline, possibly sync'ing data
back once the network is connected again. Second, it's a performance
booster; you can show a large corpus of data as soon as the user
clicks on to your site, instead of waiting for it to download again.
Third, it's an easier programming model, with no server infrastructure
required. Of course, the data is more vulnerable and the user can't
access it from multiple clients, so you should only use it for
non-critical data, in particular cached versions of data that's also
"in the cloud". See "Offline": What does it mean and why should I
care? for a general discussion of offline technologies, of which
client-side storage is one component.
if(typeof(Storage)!=="undefined")
{
// this will store and retrieve key / value for the browser session
sessionStorage.setItem('your_key', 'your_value');
sessionStorage.getItem('your_key');
// this will store and retrieve key / value permanently for the domain
localStorage.setItem('your_key', 'your_value');
localStorage.getItem('your_key');
}
Better you can try HTML 5 Local Storage or Web SQL, you can have more options in it.Web SQL support is very less when compared to Local Storage. Have a look on this http://diveintohtml5.info/storage.html