I'm developing an application and, at certain point, I need to store information that requires to be persistent between multiple pages, more probably, it will only be 2 pages.
The amount of information varies between just a few bytes and about 15KB (It will never be more than 20KB, ever). I can't really properly predict beforehand how much it will be.
For that I decided to use localStorage.
For now I'm only working on localhost:8080.
The pages, for now have only generic names: pageA.php and pageB.php.
The pages reside on the root of the domain. I.e.
http://localhost:8080/pageA.php
http://localhost:8080/pageB.php
...
At certain times, I store data on localStorage, on pageA.php (I do use the setItem() method).
When the user moves to pageB.php, pageB.php's script then tries to get the data that was stored in pageA.php.
The problem is that getItem() always returns null on pageB.php
I did check the keys I'm using and they are the same, so there should be no problems there.
I've checked, data stored is persisting between page loads as long as the url does not change.
What am I doing wrong here?
Note: tested only on Firefox 19 and on chrome 24
The problem here was that the editor I was using had been changed such that it was searching with case sensitivity.
When I changed the string i was using for the key, the replacer didn't match all the strings due to case sensivity.
I solved it by searching and adapting each key such that all keys had the same characters with the same case, not the same characters regardless of case.
In the in the end, it was just lack of attention. As expected, strings in javascript are case sensitive and that also applies to the key for localStorage and sessionStorage
Related
I'm using LaunchDarkly in a web app and am playing around with using the 'localStorage' bootstrap option on initialization.
With this option I clearly see my flags in localStorage and they look to be under a key formed with my clientId and then some long, base64 string - I'm curious if there is a clear pattern I can use to access the flag values in localStorage with getItem or if I'm perhaps completely misinterpreting the use case?
What I tried was adding the optional bootstrap option and then logging out my localStorage to see what key the flag values were being stored in, and they appear to be mapped to a key that includes my LD client ID and then some long, seemingly random string.
What I expected was for my keys to be stored under a key of maybe just my LD client ID or some other, easily found property name.
Thank you for any and all insight!
Best,
Zach
The JavaScript client SDK already caches flags in localstorage for you. When the SDK initializes, the flag values for the context (i.e. user) you provide are pulled and cached in localStorage. From that point on, LaunchDarkly's SDK uses localStorage for getting flag values, speeding up flag evaluations and ensuring that flags can be evaluated in the circumstance where LaunchDarkly is temporarily unavailable. Updates to this localStorage cache are streamed by default (though you an configure this for polling).
My point is, there may be no need for bootstrapping off localStorage. Bootstrapping on the client-side is useful for situations where you are writing these values prior to the response hitting the client's browser (for example, you are writing bootstrapped values at the edge).
I'm using PouchDB to store values that come from a database (values sent by the server) but also for some values that are only set by the user from front-side (and so should stay local).
Those front-side values should persist accross multiple connections to the app. That's why I store them in PouchDB.
Since I don't care about the revision system (only one user can modify them from one location - its browser), I'm wondering if there is a way to tell PouchDB to say so. I know there is a force parameter for calls, but there is still a need for _rev property in those cases...
Is there a way to get rid of the notion of revision and conflict for one table ?
Cheers
Are there any patterns for cases when something (in my case it's a filters) is stored on client (e.g. localStorage) and you need to run a script once per user/version to migrate data you store. For example, initially there is a filter saved in localStorage with a key myFilter after some time you decide that you need to separate filters per environment, so you need separate dev-myFilter, train-myFilter, etc. You update your code to work with environment-dependant filters, but there are users who have old myFilter and you want with next deployed version to run script which will update the key of saved filter if there is one.
Question is - what are patterns/best practices for that?
I don't know about "best practices", but the obvious technical solution, just like with any API or storage format, is to store a version number alongside the data. If you didn't do so from the start, assume version == 1 when absent.
You may be able to avoid this if the data structure is so unique between versions that the version can be determined simply by examining it.
Either way, you simply perform the translation whenever you spot that the user's data is in the old format.
The downside of this is that you have to keep checking; for a web application this is unlikely to be a bottleneck, but if you can make your data forward-compatible from the outset then you may save a bit of processing time on each request. But for the data to be useful you've got to read it anyway, so a little branching for as long as you wish to maintain backward-compatibility is, again, unlikely to be a big problem.
I am writing an application that derives a lot of image data, and doing that takes qutie some time, and during that time the user is waiting.
When I have derived the data I would like to store it in case the user wants to see it again anytime soon. I have been going through some local storage methods in html5 and the most promising for my case seems to be localStorage.
A downside to localstorage is that it tends to not allow that much data to be stored, 5Mb in most cases, and my thoughts are to every time i derive some data, to store it in localStorage. The problem arises when those poor little 5MB get filled up, and then I would like to delete the oldest element from the memory, bu there seems to be no easy way of doing that as everything is just stored in key-value pairs.
So I'm not quite sure how to proceed with using localStorage in this case.
Is there any module or something that can make using localStorage in the manner described above easier?
You can use
1) IndexedDB to store huge data but it will only work in latest browser except Opera mini.
2) OR, store your data in memory and later on to localstorage or vice versa.
3) You can always put your time tag with each key you are storing. you can traverse through keys having specific format to get the oldest key in store and you can delete it easily.
4) you can also put your time stamp in data with your image data, in this case you will not have to extract all keys but complete data objects from the store.
I would suggest you IndexedDB option to overcome your size limitaions.
Hope this will help.
In the end i used this module: https://gist.github.com/ragnar-johannsson/10509331.
Using it the oldest values get deleted if there isnt enough memory to add a new one.
Let's say I'm making an HTML5 game using JavaScript and the <canvas> The varaibles are stored in the DOM such as level, exp, current_map, and the like.
Obviously, they can be edited client-side using Firebug. What would I have to do to maximize security, so it would be really hard to edit (and cheat)?
Don't store the variables in the DOM if you wish a reasonable level of security. JavaScript, even if obfuscated, can easily be reverse engineered. That defeats any local encryption mechanisms.
Store key variables server-side and use https to maximize security. Even so, the client code (JavaScript) is quite vulnerable to hacking.
You can use Object.freeze or a polyfill or a framework which does the hiding for you.
Check out http://netjs.codeplex.com/
You could also optionally implement some type of signing system but nothing is really impenetrable. For instance objects locked with Object.freeze or Object.watch can still be manually modified in memory.
What are you really trying to accomplish in the end?
What you could do is send a representation of the matrix of the game or the game itself or a special hash or a combination of both and tally the score at the server... causing the user to not only have to modify the score but to correctly modify the state of the game.
Server-side game logic
You need to keep the sensitive data on the server and a local copy on the browser for display purposes only. Then for every action that changes these values the server should be the one responsible for verifying them. For example if the player needs to solve a puzzle you should never verify the solution client side, but take for example the hash value of the ordered pieces represented as a string and send it to the server to verify that the hash value is correct. Then increase the xp/level of the player and send the information back to the client.
Anything that is living in the client can be modified. That is because in MMORPG the character's data is living on the server, so players can't hack their characters using any memory tools, hex editor, etc (they actually "can", but because the server keep the correct version of the character's data is useless).
A good example was Diablo 2: you have actually two different characters: one for single player (and Network playing with other players where one was the server), and one for Battle.net. In the first case, people could "hack" the character's level and points just editing the memory on the fly or the character file with an hex editor. But that wasn't possible with the character you was using on Battle.net.
Another simple example could be a quiz where you have a limited time to answer. If you handle everything on client side, players could hack it and modify the elapsed time and always get the best score: so you need to store the timestamp on the server as well, and use that value as comparison when you get the answer.
To sum up, it doesn't matter if it's JavaScript, C++ or Assembly: the rule is always "Don't rely on client". If you need security for you game data, you have to use something where the clients have no access: the server.