Using Safari as a renderer of Reports/data, read in from XML files.


If you know some html, a little bit of xml, and how to write xml files from AppleScript, then it is pretty easy, to get good looking reports (especially when you know some css), shown up in Safari, or any other web browser you are used to on OS X. You kan even view the raw XML file now adays, with the ability to collapse nodes.

There is a great example over at w3schools. The only thing you have to modify is the path of the note.xml file, in the example shown in the link above (in the statement): Use a full path, on the form “file:///Users/you/…/note.xml” and you’ll quickly discover that you have a server/daemon up and running already, that can serve your webpage an xml file, no need for Apache for such small tasks! :slight_smile:


Just out of curiosity: do anybody know which daemon/agent it is that serves the http request, is it launchd?


If Safari is doing this without asking permission from the user you didn’t discover a feature but a huge bug with high security issues. According to the File API of HTML 5 (chapter 12) the browser should always ask the user to point the file (open dialog) or give permission to read the file. If not, I would submit a bug report to Apple.

It is Launch Services that handles URLs to be opened.

Well, IMHO it isn’t a bug, but a huge feature and it doesn’t reduce security:

  • You can’t do this from another protocol: There is no way somone from a http://, or other protocol different than file:// can read your files.
  • There is no way you can write with the xmlHttpRequest object. (I have tried really hard! :slight_smile: )
    It is a feature, because with this you can create pretty dynamic sites. (Write out xml with AppleScript or other technologies, and have it more prettilly presented in html, in a table or such using Safari as a “database browser”. (My homepages will never be the same again.)

(It is a shame though, that things that were possible before with Safari and some javascript now doesn’t work anymore though. Like having an applet installed with its own protocol, and send parameters to the applet from javascripts residing in bookmarks in the browser.)

Thanks for that, I was really wondering, since it was opened by the xmlHttpRequest object. I was wondering how it was delegated.

The way I interpreted your first post it seemed like I could run a local proxy site and could read file from the disk. If I could do that, any malicious website, or worse, malicious advertisements on a regular site could screen my hard drive. The new File API in HTML 5 can access local files but normally not by hard coded paths, only by prompting the user with an open panel and letting the user decide what file to open. So I was surprised seeing that you were able to make it work. If I understand it correctly it’s only allowed when the site is a local file and not even allowed running a local proxy server.


I haven’t tried it out that and maybe that scenario will work. But it isn’t that easy to first start up a local proxy site, which would have to be opened with the file:// protocol b[/b] , because the xmlHttpRequest object will only accept a file:// protocol as long as the document it is called from is opened with the file:// protocol.

(I haven’t tried this the other way around, but I also guess that you can’t have an xmlHttpRequest object that tries to get an http, or http or other internet protocol URI, since it isn’t of the same protocol type (scheme).

And you can’t write anything except for into local storage with html5, which I haven’t tried yet. ( I hope the format is such that sqlLite, or MySQL, or something familiar (xml?) can be used to extract the data with locally from other apps than the browser in question.) If that works, then it may come in handy, because you can then use the Browser as an input device. :slight_smile:

(*) I am pretty sure that you can’t open local files with the file:// protocol from a webpage you have opened that has a http:// url or similiar. I haven’t tried this. This may be scary though, say you read in a file with an xmlHttpRequest object, then processes it and sends it back to the “Mother site” using javascript and another xmlHttpRequest object.

But: before you get that far, you’ll have to get the “proxy-site” down on the users disk, and then you’ll have to make the user open the page you have, that is, if you can read in, or open a file from a local disk into a webbrowser, when the “initiating documents origin” is across the internet.