Is there any client-side script that would be able to make changes to a file on the hosts computer? (Intention stated below)
I am creating a packaged app for chrome which can show some online data, and make it available even when offline.
There is a certain thing, for e.g. 'a webpage' i want to show/store (but i cannot get/read its contents due to it being on different origin). To show when online, i can use iframe, but am unable to preserve it for offline.
So i thought i could make an appcache (manifest within the application package) which will cache the file, and on press of an update button a script would run which would make some change to the manifest which would force the cached resource to be reloaded.
I searched a lot, but no results.
Any suggestions as to how it can be done. Or any other way to get it to work?
I don't think so. This could be a huge security problem if it existed.
If you had to, you could send an ajax request to the server to create a file it creates with the current prices, and add it to the appcache file.
Here is a link to another SO quesitob that has a list of APIs you could use to get your stock price.
Webservice to get stock quotes?
Related
I have a component which lazy loads the images.For the first time when my page loads then at that time the images are displayed using lazy loading but if I refresh or reload or close and then open the tab then my images are pre loaded because it is now fetched from cache.Is there any way i can stop caching of my component in angular 7?
The cache is not being done by Angular but your browser. Once you load an image (and depending on the headers of the response) your browser will cache it to be able to load it faster the next time. This is usually a good approach.
Not sure why you don't want them to be cached but you have different options. Here you have a good read about HTTP caching: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching This cache configurations for static assets are usually done by your web server and they depend on which webserver you are using (nginx, Apache, IIS, node, ...).
Another option is to append a random query string to your image URL. This HTTP cache system works by using the image URL as a resource key to identify it. Because of this reason you can do something like:
<img src="./yourimagefolder/yourimage.jpg?r=putherearandomstring">
In this way your image resource 'Id' will be different in each request. (You will need to change the 'putherearandomstring' string in the example with a different random string each time the page is loaded.
If this is just for development purposes, you can disable the cache in developer tools. I don't see a reason you would want to do this for a live site though? As you would be forcing the user to grab the images everytime they load the component which will reduce performance.
The problem with cache in an environment where custom software is updated frequently and some users are less savvy is that they will not automatically get critical client-side changes unless they are told specifically to refresh their cache. With all of the decorations in the index.html I have not yet found a reliable solution.
I remember several years ago that I was able to save a remote JavaScript file from a website onto my local in Chrome Debugger, make a few code adjustments, and refresh the page so Chrome will be reading the local copy of the JS file. I am wondering if this feature is still available, and if so how am I able to use it?
I know that I can add breakpoints to achieve something similar. I have followed a few guides, but none of them was able to achieve what I want:
https://developers.google.com/web/tools/setup/setup-workflow?hl=en
https://www.sitepoint.com/edit-source-files-in-chrome/
It looks as though you can only achieve this when you are using a local server. According to the Stage persisted changes section of the API:
If you are mapping files from a remote server instead of a local server, when you refresh the page, Chrome reloads the page from the remote server. Your changes still persist to disk and are reapplied if you continue editing in Workspaces.
It seems you could achieve what you want if you use Fiddler AutoResponder:
Fiddler's AutoResponder tab allows you to return files from your local disk instead of transmitting the request to the server.
Background:
I have built an offline HTML5 application that stores some data into the local browser db using pouchdb.
Now the requirements have changed and I have to store large pdf documents(around 200 of them, each with 5mb - 8mb size) into the local browser so the user can view it offline when required.
Issue:
I don't think that it is a good idea to put these large documents received from server into my in browser database using pouchdb.
I would like to know if there is a way to put these documents into my device some how and then get a url reference pointing to the location within the local device ?.
Include the PDFs in your offline manifest, so that they're cached with the rest of the application. Then you just use your normal URL to refer to it, and it's satisfied from the offline app cache.
Re your question below:
When the application is loaded in the browser then i store the details of the associated pages into the browser via a manifest file. And when the user clicks on a 'SYNC' button then I communicate with the server and fetches all the pdfs associated with the user. If I have to persist these pdfs using the manifest then how can I do it ?.....the manifest is already stored
The way we do something similar is this: We have separate pages for the things that the user has taken offline (a day's worth of appointments, for instance), and a list page driven entirely by client-side data that lists those pages. Here's how it works:
When the user wants to take something they're looking at offline, they click a button which opens a URL with the information telling the server what they want (say, example.com/offline/stuff-saying-what-they-want-here/), and the server generates a page with that data embedded in it along with a manifest for the page and any assets it requires. So at that point, that information is available offline on that URL. When it loads, the page registers itself in a list in localStorage, giving a description of the page and its URL.
The list page (say, example.com/offline/list/) has its own manifest and assets, which don't change often because it's driven entirely by that localStorage information. It shows the list of things they have offline with links to them. It's primarily a convenience for users, in case they forget to bookmark the individual things they take offline; e.g., the idea is that they'll bookmark the list once, and never have to worry about bookmarking individual pages. (They could go hunting through their history, but it's a pain.) The list page keeps itself up-to-date by getting the list of known pages from localStorage when it loads, and subscribing to the storage event so if you load other pages in other tabs while the list is open, it sees them arrive and updates its list.
So without knowing anything about your app, it sounds like perhaps your main page could be like or list page, and clicking "sync" could open a page for the PDF, generating the manifest on the fly, and that page could register the PDF in localStorage the way we do with our offline pages so the main page can show their status correctly.
Obviously, there's potential there for the actual appcache and our localStorage list to get out of sync; we can't help it if a user clears appcache (which would make us list things that can't really be viewed offline) or clears localStorage (which would make is not list things they could view offline), but there we are. Users mostly don't do that, all that often.
In the future, you'll get much more granularity and control with service workers, but for now since service worker support is very thin on the ground so far, we're stuck with appcache and its fairly stodgy way of defining offline assets.
T.J. Crowder is right: if your PDFs are static and known in advance, then AppCache is the way to go. Unfortunately it does mean that each and every PDF will be saved in the user's browser when they first load the site, but maybe that's what you want.
Else if the PDFs are dynamic and not known in advance, then yeah, you may see performance problems from PouchDB with 5MB attachments. But if you want to try it out, then check out PouchDB attachments and blob-util. blobUtil.createObjectURL() is exactly what you're looking for in terms of a "local URL."
The Context:
You have a web server which has to provide an exclusive content only if your client has your specific Chrome extension installed.
You have two possibilities to provide the Chrome extension package:
From the Chrome Web Store
From your own server
The problem:
There is a plethora of solutions allowing to know that a Chrome extension is installed:
Inserting an element when a web page is loaded by using Content Scripts.
Sending specific headers to the server by using Web Requests.
Etc.
But there seems to be no solution to check if the Chrome extension which is interacting with your web page is genuine.
Indeed, as the source code of the Chrome extension can be viewed and copied by anyone who want to, there seems to be no way to know if the current Chrome extension interacting with your web page is the one you have published or a cloned version (and maybe somewhat altered) by another person.
It seems that you are only able to know that some Chrome extension is interacting with your web page in an "expected way" but you cannot verify its authenticity.
The solution?
One solution may consist in using information contained in the Chrome extension package and which cannot be altered or copied by anyone else:
Sending the Chrome extension's ID to the server? But how?
The ID has to be sent by you and your JavaScript code and there seems to be no way to do it with an "internal" Chrome function.
So if someone else just send the same ID to your server (some kind of Chrome extension's ID spoofing) then your server will consider his Chrome extension as a genuine one!
Using the private key which served when you packaged the application? But how?
There seems to be no way to access or use in any way this key programmatically!
One other solution my consist in using NPAPI Plugins and embed authentication methods like GPG, etc. But this solution is not desirable mostly because of the big "Warning" section of its API's doc.
Is there any other solution?
Notes
This question attempts to raise a real security problem in the Chrome extension's API: How to check the authenticity of your Chrome extension when it comes to interact with your services.
If there are any missing possibilities, or any misunderstandings please feel free to ask me in comments.
I'm sorry to say but this problem as posed by you is in essence unsolvable because of one simple problem: You can't trust the client. And since the client can see the code then you can't solve the problem.
Any information coming from the client side can be replicated by other means. It is essentially the same problem as trying to prove that when a user logs into their account it is actually the user not somebody else who found out or was given their username and password.
The internet security models are built around 2 parties trying to communicate without a third party being able to imitate one, modify or listen the conversation. Without hiding the source code of the extension the client becomes indistinguishable from the third party (A file among copies - no way to determine which is which).
If the source code is hidden it becomes a whole other story. Now the user or malicious party doesn't have access to the secrets the real client knows and all the regular security models apply. However it is doubtful that Chrome will allow hidden source code in extensions, because it would produce other security issues.
Some source code can be hidden using NPAPI Plugins as you stated, but it comes with a price as you already know.
Coming back to the current state of things:
Now it becomes a question of what is meant by interaction.
If interaction means that while the user is on the page you want to know if it is your extension or some other then the closest you can get is to list your page in the extensions manifest under app section as documented here
This will allow you to ask on the page if the app is installed by using
chrome.app.isInstalled
This will return boolean showing wether your app is installed or not. The command is documented here
However this does not really solve the problem, since the extension may be installed, but not enabled and there is another extension mocking the communication with your site.
Furthermore the validation is on the client side so any function that uses that validation can be overwritten to ignore the result of this variable.
If however the interaction means making XMLHttpRequests then you are out of luck. Can't be done using current methods because of the visibility of source code as discussed above.
However if it is limiting your sites usability to authorized entities I suggest using regular means of authentication: having the user log in will allow you to create a session. This session will be propagated to all requests made by the extension so you are down to regular client log in trust issues like account sharing etc. These can of course be managed by making the user log in say via their Google account, which most are reluctant to share and further mitigated by blocking accounts that seem to be misused.
I would suggest to do something similar to what Git utilises(have a look at http://git-scm.com/book/en/Git-Internals-Git-Objects to understand how git implements it), i.e.
Creating SHA1 values of the content of every file in your
chrome-extension and then re-create another SHA1 value of the
concatenated SHA1 values obtained earlier.
In this way, you can share the SHA1 value with your server and authenticate your extension, as the SHA1 value will change just in case any person, changes any of your file.
Explaining it in more detail with some pseudo code:
function get_authentication_key(){
var files = get_all_files_in_extension,
concatenated_sha_values = '',
authentication_key;
for(file in files){
concatenated_sha_values += Digest::SHA1.hexdigest(get_file_content(file));
}
$.ajax({
url: 'http://example.com/getauthkey',
type: 'post'
async: false,
success:function(data){
authentication_key = data;
}
})
//You may return either SHA value of concatenated values or return the concatenated SHA values
return authentication_key;
}
// Server side code
get('/getauthkey') do
// One can apply several type of encryption algos on the string passed, to make it unbreakable
authentication_key = Digest::<encryption>.hexdigest($_GET['string']);
return authentication_key;
end
This method allows you to check if any kind of file has been changed maybe an image file or a video file or any other file. Would be glad to know if this thing can be broken as well.
Lets say for example i have an google search results page opened in a window or a tab in firefox.Is there a way i can retrieve the html code of that tab or window using javascript?
I suppose that the webpage html is saved temporarily somewhere in computer memory.
Can i load the webpage using memory saved address?
Is there a way for javascript to read html files saved in the same folder as the original?For example i have saved the webpage in a folder on my computer.If i create an html file inside the same folder does javascript consider the saved webpage as the same domain?
No, you most certainly can't do that unless you control both pages. This would be a huge security hole.
There is a custom search API which may help if you specifically want to do Google searches. It appears to have a JSONP implementation which should let you make a cross-domain request, but I haven't tried it out so I'm not sure how well it works.