Pitfalls of accessing a webserver on 127.0.0.1 from js with a public site

Question

I'm thinking about exploring the idea of having our client software run as a service on a high port and listen for simple http GET requests from 127.0.0.1. The theory is that I would be able to access this service via js from a web page that is served from my site.

1) User installs client software that installs itself as a service and waits for authenticated requests on 127.0.0.1:8080

2) When the user hits my home page js on the page makes an xhtml request to 127.0.0.1:8080 and asks for the status

3) The home page then makes another js request back to my web server sending the status that it received.

This would allow my users to upload/download and edit files on a USB attached device in real-time from a browser. Polling could be the fallback method which is close to what we do today.

Has anyone done this and what potential pitfalls are there? Will this even work?

Answer 1

I can't see any potential pitfalls. I do have a couple of points however.

1/ You probably want to make sure your service only accepts incoming connection from the local machine (127.0.0.1). Otherwise, anyone could look at your JavaScript and figure out that it's talking to [your-ip]:8080. They could then try that themselves from a remote site (security hole).

2/ I wouldn't use port 8080 as it's commonly used for other things (alternate HTTP servers, etc.). Make it configurable and choose a nice high random-type value.

3/ I'm not sure what you're trying to do with point 3 but I think you're trying to send the status back to the user. In which case, why wouldn't the JavaScript on your home page just get the status in a single session and output/update the HTML to be presented to the user? Your "another js request back to my web server" doesn't make sense to me.

Answer 2

You may not be able to do a xml http request to 127.0.0.1 as XMLHTTPRequest is usually limited to the same domain as the main content is being served from. I'm not sure if this restriction applies if the server is on the client's machine. That being said, you could still create a <script> tag that had the src pointing to 127.0.0.1, and have the web server return some Javascript to run. If you only need a simple response, this could work well.

Answer 3

I think it is much better for you to avoid implementation of application logic in JavaScript and html. Once user clicks button on a web page JavaScript should send request to your service and allow it do the rest of the work.

Answer 4

You could have problems with step 1 (Client installs itself) depending on your target user base.

You will need a customised install for each supported environment (Win2K, Vista, Linux, MAC OS 9.0/10.0 etc.).

If your user is on a locked down at work PC this simply wont be allowed.

To some users this might look distressingly similar to a trojan unless you explicitly point out you will be installing software that runs as a service.

You didnt mention an unistall procedure. Users resent "Adobe" like software which installs itself and provides no sensible un-install options

Ohterwise the approach is sound, and, there are are couple of commercial products out there that use exactly this approach!