I use the application cache to make my webapp work without internet access. When a new version of the app is ready, the manifest file is changed to trigger a re-download of the app.
The app uses a lot of json data, and what I've done is have the app download the json data though an ajax call at boot, and put it in the localStorage before using it. If the user is offline, the app fetches the data from localStorage instead of the network.
However, quite a lot of things in the app are using localStorage, so to avoid hitting the storage quota ceiling I want to try to move that json data out of there. My idea was to make the data available offline though the application cache, just like the app code.
The behavior I want is that whenever the user has internet access they fetch the json data freshly from the server, while whenever the user is offline they get served the last cached version of the json data.
I was thinking I could do this by simply putting the json data's url under the NETWORK: section, and then put a FALLBACK: clause for the same url that redirects to a cached version, so that if the url is unreachable the user gets served by the fallback instead.
However, this way is flawed because as the user regains his internet access and fetches fresh data from the server, the data cached in the FALLBACK: url will not be updated to match the newest. That is, unless I change the manifest file and force the entire webapp to be re-downloaded, which I don't want to do. My json data changes frequently, so I want to avoid this problem.
From my googling there is no way to programmatically invalidate a single file in the application cache. Is there any way to work around this issue?
Or is there no way to just make the application cache behave on the principle of "always use the online version if available"?
Related
so I have seen a lot of people using local storage to store certain parts of a web page but not an entire web page is it possible? , if so how? , if not is there a way to store an entire web pages data so the user can come back to it how they left it?
This can be done if you use javascript to save document.body.innerHTML into the webstorage and you use javascript to load it back from the storage when the page is loaded next time. If the web page is not in the webstorage, you could redirect the user to the web page.
But this depends on the design of your web page and if there is session index etc in the body of the web page.
You should also think of some way to handle versions. You dont want your users only use the cached version of your web page, but it should be updated once you update your web page.
The session storage is ~5mbit, so you cant save very much, especially not pictures.
Since LocalStorage allows you to store about 5MB~ you can store a full webpage there and then just call it into a document.write().
The following code does it:
Storing it:
var HTML = ""; //html of the page goes here
localStorage.setItem("content", HTML);
Retrieving it:
document.write(localStorage['content']);
Although this is possible it is common practice you only save settings and load them up into the right elements rather than the entire web page.
This is not really answering your question, but, if you are only curious how this can be done and don't need to have wide browser support, I suggest you look into Service Workers, as making websites offline is something that they solve very well.
One of their many capabilities is that they can act as a proxy for any request your website makes, and respond with locally saved data, instead of going to the server.
This allows you to write your application code exactly the same way as you would normally, with the exception of initializing the ServiceWorker (this is done only once)
https://developers.google.com/web/fundamentals/getting-started/primers/service-workers
https://jakearchibald.github.io/isserviceworkerready/
Local storage it's actually just an endpoint: has an IP address and can be accessed from the web.
First of all, you need to make sure that you're DNS service points on your Index page.
For example, if your Local-storage's ip is 10.10.10.10 and the files on that local-storage is organized like:
contants:
pages:
index.html
page2.html
images:
welcome.png
So you can point your DNS like:
10.10.10.10/index -> /contants/pages/index.html
In most of the web frameworks (web framework it's a library that provide built in tools that enable you to build your web site with more functionality and more easily) their is a built in module called 'route' that provide more functionality like this.
In that way, from you index.html file you can import the entire web site, for example:
and in your routes you define for example:
For all the files with the .html extension, route to -> 10.10.10.10/contants/pages/
For all the files with the .png/.jpg extension, route to -> 10.10.10.10/contants/images/
Local storage is usually for storing key and value pairs, storing a whole page will be a ridiculous idea. Try instead a Ajax call which Returns an partial view. Use that for the purpose of manipulation in DOM
So I am creating an offline web app using appcache.
I need to pass a variable between client and server.
POST is not an option because the server could be offline and appcache will not pull from the cache with a POST request (Explicit or fallback)
GET is not an option because it cannot be cached by appcache because URL is different for each request (?id=n).
Added: I was looking for a way to adapt already created HTML forms (that use POST or GET) for offline use, so a way to store the actual request. Since I could not find a way around the appcache limitations, I ended up rewriting the code to use Indexeddb for storage and service worker fetch interception and background sync methods...much slicker...so long appcache.
According to https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
Deprecated
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Try using sessionStorage.
Whenever you want to save data on a page you use the syntax
sessionStorage.setItem('name',value);
This saves the data offline
and can then be retrieved on any webpage using
sessionStorage.getItem('name');
This of course only saves the data till the tab is closed / session is ended.. A more permanent method is
localStorage
... They both use the same format but the latter stores the data even after the browser is closed.
I have an app that runs in the client browser and doesn't have any server side (http/js is served, but nothing posts to the server). the app is redeployed on many servers (iis, apache, nginx, sometimes localhost, sometimes on an intranet) and are served using http (not https). My app generates files such as zip files and pdf's in the clients browser as blobs BEFORE I want to save, so having them navigate away on the same page then back to the app defeats the purpose; and I can't post the generated data to dropbox anymore, since they have to start over... I want to be able to send these blobs directly to files in the end users dropbox (and later google drive).
https://www.dropbox.com/developers-v1/dropins/saver performs exactly as I would like. It pops up. It lets the user authenticate in the popup. It lets the user choose where they want to put my file. But I can't send it a data uri, or base64-encoded data, or a bytearray, or whatever. It only works with files previously saved somewhere accessible on the net. So it does not work for me.
https://www.newfangled.com/direct-javascript-dropbox-api-usage/ shows how I could embed the oauth data, which I don't have.
https://blogs.dropbox.com/developers/2013/12/writing-a-file-with-the-dropbox-javascript-sdk/ seems like it should work, except that it's trying to perform an oauth session and it uses the same window as my app (which is undesired).
My current tabs I'm looking at (includes entries from a few years ago, so things might have since changed). Some articles indicate that it isn't possible. Other articles incidate that it IS possible - i mean this particular comment https://github.com/dropbox/dropbox-js/issues/144# doesn't help me much. Neither does "I'll be sure to pass this along as feedback" - was it passed along? To whom?
https://github.com/dropbox/dropbox-js/issues/144
https://stackoverflow.com/questions/30094403/save-input-text-to-dropbox
https://blogs.dropbox.com/developers/2015/06/programmatically-saving-a-url-to-dropbox/
How can I upload files to dropbox using JavaScript?
upload file to dropBox using /files_put javascript
https://github.com/morrishopkins/DropBox-Uploader/blob/master/js/reader.js
https://www.dropbox.com/developers/saver
https://www.dropboxforum.com/hc/en-us/community/posts/202339309-Can-I-save-a-JSON-stream-object-to-Dropbox-file-with-Dropbox-Post-Rest-API-
https://github.com/smarx/othw
Can Dropbox Saver accept data from createObjectURL()?
It sounds like the code from https://blogs.dropbox.com/developers/2013/12/writing-a-file-with-the-dropbox-javascript-sdk/ works fine for you, but you want to do the auth in a separate browser window/tab.
If so, I'd suggest just changing that code to use the Popup auth driver instead.
I'm using Javascript SDK to access Dropbox Datastore API. I noticed that each time i call open(Default)Datastore(...) whole datastore is downloaded to browser using (...)/datastores/get_snapshot endpoint. Is there any way to store records in localStorage and download only those that have changed since some time (simply sync them instead of download them all)? Imagine that user has 10MB in its Datastore. Now - each time when he/she refresh page with my javascript app 10MB will be downloaded? How can implement it?
Regards.
No, local caching isn't something that's supported with the current JavaScript SDK. It's a feature we're already considering adding in the future.
I would like to import data that the user had entered into his profile on a website that I do not control. I don't want the user to hand me his login credentials to grab the data from the server-side (connecting directly to aforementioned website). I would rather prefer the login data to stay on the client's machine: It makes my service more trustworthy and I don't have to process sensitive data.
I thought that this can probably done with javascript without greater hassle. However, given the security risks, it seems to be blocked by browsers. See How to get data with JavaScript from another server?
So I think my question is already answered and can be closed/deleted.
I'm not sure I understand what you're trying to do, but there is no secure way to verify login credentials in a browser client. If you want to check login credentials, you will have to involve a server.
Some data can be stored on the client side, but then a user is tied to a particular browser on a particular computer and can't use the service from anywhere else. In older browsers data is generally limited to what can be stored in a cookie and cookies are not guaranteed to survive for any particular long lasting time frame. In the latest browsers, data can be stored in HTML5 local storage which allows for a little more structured way of storing data, but even then you're still stuck in one particular browser on one particular computer.
Based on your comments, it sounds you're trying to "cache" a copy of the data from web-site A that you can access from client-side code on web-site B on multiple visits to your website. If that's the case, then it sounds like HTML5 local storage may work to serve as a cache storage mechanism. You will have to figure out how to get the data from web-site A into the cache as the cache will be subject to same-origin access (domain X can only access the data that was put into HTML5 local storage by domain X), but if you can get manage to get the data from web-site A into your web-site B client-side page (perhaps using JSONP), then you could cache it using HTML5 local storage. You will need to realize that even HTML5 local storage is not guaranteed forever (so you need to be able to fetch it again from web-site A if required).
You said this
I don't want the user to hand me his login credentials to grab the
data from the server-side (connecting directly to aforementioned
website).
If you do that, anyone would be able to access any User's data, since you don't restrict access to data.
You also said this
I would rather prefer the login data to stay on the client's machine:
It makes my service more trustworthy and I don't have to process
sensitive data.
I'm really not sure that's a good idea. You still need to lock down personal information. But anyway, if you really want to, you can use localstorage -- modern webbrowsers support this.
Check out this link for a primer on local storage.
Storing Objects in HTML5 localStorage
Note that the user can clear the browsers local storage, so you still need to have a form to enter credentials.
EDIT -- if you want to save a user's profile information on the client, you can do that with local storage. But you still need to save the data to the server, else if the user goes to a different machine or even browser, they won't have their data. Plus, your server side model probably needs to associate a user's content with their profile in some way. I don't think there is any way around it.