I have created a Java program which takes some command line arguments to run. I need to make a browser extension to the program so that the program can be opened with data from the browser.
I know Javascript does not allow any local file access, but there are programs which doing the task I needed.
Examples are Internet Download Manager which has the browser extension for running it receiving command line arguments from the browser. Obviously extensions for most of the browsers including Chrome and Firefox are made using Javascript? Is there any way to do local program execution via JavaScript (I think there's a way surely)?
You can't directly run anything from your JS sandbox on client PC (just think about security risks!) There's other method however: Make your application register itself as protocol handler when it installs and use links with this protocol on your pages (think how e-mail clients serve mailto: or torrent clients serve magnet: links). Since you control both sending and receiving side, you can pass pretty much any information in those. You can find Windows example for registering a handle at MSDN. Should you need it for any other system, I'm pretty sure searching for "system_or_gui_name register protocol handler" will show you desired result among the first.
Related
What is the fundamental difference running a file using a server in localhost, and opening a file such as file:///Users/$user_name/$your_directory/index.html, assuming no backend is used, and it is only frontend and contains html/css/js
How does this also affect interactions with other server ie. ajax requests?
I am sorry if this is too broad, but I haven't found a solid answer to these underlying questions.
Fundamentally, assuming at some point you're going to host the result on an actual web server, the former matches the target environment while the latter doesn't. Browsers treat local files and files served from web servers (even localhost web servers) differently, although very similarly. One aspect of this is the encoding: When you retrieve a file from a web server, the process of determine what encoding the data is in is different from opening a local file.
How does this also affect interactions with other server ie. ajax requests?
This is one of the primary ways in which they're handled differently, and it even varies from browser to browser. A page loaded from a file:// URL has origin null from a Same Origin Policy standpoint. Some browsers (like Chrome) disallow Cross-Origin Resource Sharing entirely for origin null, even when the server you're trying to talk to has a wide-open CORS policy (*). Others (like Firefox) allow origin null to match the wildcard.
In general, for best results, ensure that your development environment matches your deployment environment in the important ways. That means doing your development using a web server process rather than local files. Most IDEs will happily provide that process for you; if not, Apache or Nginx aren't hard to install.
answer is simple,
if u don't have made active backend yet for "index.html" then it would not effect.e.g.-"localhost" and "index.html" will be same this time.
but when u start working with the backend,then most of the backend processes need an active server (need localhost).
e.g.-
1.
fetch('local.json')... //fetch json or any file would not work for local files.
2.
u may not ineract with mysql/django etc. databases.
means it cause errors in signup/login , store any image/video/docs at database etc.
so better is work in localhost, it's most easy way is :-
VScode(IDE) >> extenctions >> live server (just need to click a button to make
localhost and click again to stop localhost)
https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
It won't make any difference, I think.
But there is an exception when using Chrome! Sometimes I have seen if a html file is added with some CDN link, then it doesn't loaded into html specifically in Chrome but if you try the same file in Firefox or Internet Explorer, it works.
I have faced this problem and hence I always put it under local IIS default website.
I'm trying to create a chrome extension which scans a local directory for new files ...
However, if I add the file://* permission to the manifest I can access the internal file browser of chrome with
xmlhttp.open("GET","file://C:/Users/username/Desktop/",false);
xmlhttp.send();
console.log(xmlhttp.response);
From the response I could extract the file URLs and use them in my extension.
My question is now: Are there other approaches? The above way seems more like a workaround and easily breaks if chrome's file browser is changed ...
Any time I've had to do something on the local machine from a Chrome extension, I've always created a small program that accepts connections via HTTP, and does the work as a normal program, taking commands with JSON over POST. This gives you great flexibility, as it essentially allows you to write a Chrome extension that can do anything a desktop program can do.
However, there are great downsides to this, and you should only do it if absolutely necessary. For instance:
You can't do this for all operating systems, unless you're going to write an agent for every OS.
The extension cannot be installed from Google's extension hosting.
You must write your own installation program that registers the extension.
There are very real security considerations to worry about with this. You will be opening up a web service that executes commands. Be very sure that you are not exposing the user. In all reality, if you are making a file browser, you probably are exposing the user. It will be up to you to fix this security hole, as if you were creating any other web service.
in a simple html file opened locally via firefox I need some javascript code to execute a command (maybe "ls") and get it's result in a string I can use in js/jquery to alter the page contents.
I already know this is a generally bad idea, but I have to make this little local html file capable of running several scripts without a server and without cgi.
In the past I've used to install a plugin in TiddlyWiki (www.tiddlywiki.com) to execute external commands (firefox requested authorization for every operation), so javascript can do it, but how to get command result in js after execution?
I don't believe there's any way to do this without a cooperating browser plug-in. The browser plug-in would be told what command to execute via javascript, it would go execute that command and then call you back with a callback when the results were available. This could be very dangerous as giving the browser access to your local system in almost anyway opens you up to lots of types of attacks (which is why browsers don't offer this capability).
This has been asked a lot of times already: I need to get the full file path via a web-page. The use case is an application running on the same machine as the browser (i.e. the application starts a local HTTP server and fires up the browser.) File-paths are of course valid and the same for both client/server now. The use case it that the user selects a file and then the server process does some computation on it, and the input files are typically large (read: several GiB in size.)
The easiest thing would be to directly access the path using , but for security reasons, this is disabled. I'm looking now for the least intrusive workaround to this problem. The target browser in question is Chrome. I'm fine if the user has to click "accept" once on some security warning, as long as I can ensure that it won't appear again.
Do I have to write an extension, NSPlugin, can I use some special header magic to mark my page as "local", is there some security setting I can set? The less the client has to do the better, and I would prefer some "click here to allow access ..." solution above everything else. Can I directly install an extension from the server process that would do this (after the user clicks accept?)
Is it possible to do this with a Java applet/Flash? That would be the easiest solution, and clients are guaranteed to have Flash installed (as it is bundled in Chrome...)
You can create Java applet for tasks like this and self-sign it. User will have to allow it to run, but then you will be able to access applet's function that will return file path string via Javascript.
Clearly file io on the client's system is forbidden from JavaScript. If this wasn't the case it would be absolutely trivial to hack every web browser that visits your website.
Battlefiled 3 is controlled though the browser. To do this EA wrote a browser extension for the top three browsers. But that's resource intensive. If you just care about chrome you can use an addon, and for that i suggest using the NPAPI.
And as MOleYArd said, Java is a good solution and probably more common than an extension or addon.
Problem definition:
Server is an embedded system with no access to Internet.
Each server is managed by web interface which uses JavaScript.
Each server has a local copy of JQuery library.
Clients (browsers) are connected to embedded systems (servers) via a very slow connection.
Clients have the latest browsers (HTML5, CSS3, JavaScript 1.8.5)
Clients are not connected to Internet either.
Clients can't access multiple servers at the same time (servers are in distant locations and most probably a client can only access one server and nothing else, but later that day the client may go to another location and connect to another server).
Each server has an IP address (not necessarily in the same range) and no DNS name.
Every time the client connects to an embedded server, it fetches all the files including the huge JQuery library (huge=~90KB)
Question:
The JQuery library is too big for this slow connection but one-time download is acceptable. However, we don't want the clients to download it every time they connect to each new server. The JQuery on all these devices is the same. But apparently the browser cache is domain based. How can we cache the JQuery library so that the client doesn't have to download the JQuery every time it connects to a new server?
just link to it in one place...
for example, if you have a single server, http://1.2.3.4/ that you want to designate as your CDN, put jQuery on it, and link to it in your scripts using <script src="http://1.2.3.4/jquery.min.js"></script>
you could link it to the ip in your link tag. The server does not have to have access to that access or anything, and so all the clients will geht the jquery from the same server all the time and so it is cached.
Here is a simple solution: All your customers must edit their /etc/hosts file (Google for where you can find it on Windows) and put a line like this in their config:
1.2.3.4 jquery-from-closest-server.com
Each client must figure out the closest server which has jQuery and replace 1.2.3.4 with its IP address.
In your HTML code, always use the link http://jquery-from-closest-server.com/jquery.js
To be safe, you may want to register jquery-from-closest-server.com for those customers which do have Internet access.
When the browser asks for the file, it will use /etc/hosts to resolve the IP address. Since the domain name will be the same for all your embedded devices (changes in the IP address are ignored by the browser), the script will be downloaded once for all clients.
Note that this means you can never upgrade to a newer version of jQuery. The problem is that you'd have to replace it on all embedded devices at the same time because there is no telling from which server the customers are downloading it from.
If that bothers you (and it will in about four months after you discovered the first serious bug), here is another solution: Instead of serving the HTML from your embedded device, distribute a static web app (a set of HTML files and JavaScript) which customer can install in their desktop. Use AJAX and iframes to replace parts of the static web app with data from your embedded device.
Advantages:
very fast (no downloads at all)
only little code on the embedded device
easy upgrade strategy
No deadlocks when you need to upgrade either the embedded devices or your controller app.
[EDIT] PS: Consider to compress jQuery with gzip. That leaves you with a 33KB file. All HTML5 browsers can decode compressed files, you just have to tell them by setting the necessary HTTP headers.
Apparently there is no standard way to include JQuery in our project so we chose to replace JQuery with a smaller similar library. These are the options:
JQuery mobile is a better fit for our project since it has a smaller size and can do almost everything we need from JQuery.
Zepto.js is also another suitable replacement.
JQuip is a stripped down version of JQuery that can help our specific project.