On 15/06/11 13:12, peasth...@shaw.ca wrote: > From: Scott Ferguson <prettyfly.producti...@gmail.com> > Date: Mon, 13 Jun 2011 15:30:27 +1000 >> To clarify - is it only you that needs to be able to use this file link?? > > Yes, only me. The objective is to simplify my testing procedure. > Of course, the time I've spent to understand it probably outweighs > the time that will be saved. > >> If so - would you only be accessing it from Dalton (or where)?? > > Yes, only from Dalton.
OK - so there's no security concerns from the link while in the page while its on the public server. And the same page when copied locally isn't publicly accessible.... So basically what you want is:- A page on the public web server with an absolute file:/// link that points to a non-existent location (relative to the web server) The same page saved locally means the same link will then point to a local location.... (relative to the localhost) If I try the same thing here on this network (Class C) I can reach machines on the same subnet - but not the filesystem. That has nothing to do with weblinks though - just simple authentication. The same problem doesn't occur when I use a terminal because the remote machine sees the connection user, and authenticates the user - but a connection from the browser, well, it's not a user. And your problem is that Iceweasel is stopping you from loading a file that the user running Iceweasel has permission to read and is on the same machine?? Does it work with Lynx - Konqueror, Opera, Chrome, or any other web browser?? Wouldn't this whole process be simpler if you just had a local copy of the website - test there and then push the changes up to the production server? That's the process I use - when I'm happy with the changes I just upload and additional or modified files, remotely connect to the mysql server and update the database. As you are only serving static files you might even be able to use rsync or sftp/fish to achieve the same thing. > >> Yes - that is as it should be. A web page should only be able to load a >> file from within it's *purview*. So a http link should point to >> somewhere within the root of the web server (eg. /var/www or >> ~/public_html), and a file link should point to somewhere on the same >> machine the link is served from (think of the authentication). > > Sorry to say, I have an argument. Consider the principle of user > centrism. "http://en.wikipedia.org/wiki/User_centered_design"; > Suppose user X sits in front of the console showing the Iceweasel interface > and sees the text "file:///"<path>. Is that file URI any different > whether it came from a remote machine or was typed in by X or was pasted > to the URI bar from the clipboard. No. That is my understanding. Consider what happens from a user point of view User sitting at Dalton wishes to open a file on Dalton.... permissions allowing it's possible, which implies authentication (ok?) If the html file is on Dalton and the file link (file:///home/peter/test.html) points to /home/peter/test.html the same process happens - and you should be able to load that file. Additionally if that link is http://test.html it should fail (no web server) > In all cases it is still that > same text residing in a buffer used by Iceweasel. Furthermore, that file > URI always refers the local filesystem; even if the "file:///"<path> > was retrieved from a remote system. Therefore the browser should open > the file URI equally well, regardless of origin. If a remotely originated > file URI, or any URI, can be blocked from opening, OK; but the blockage > should be configurable. Not hard coded. > >> So a http link should point to somewhere within the root of the web server >> ... Poorly put. Let me re-phrase that - if it directly links to a file (using http://path), that file *should* reside within the root of the webserver. (not must). That's distinct from http://server/path Additionally if your webserver root is /home/peter/public_html (on shaw.ca) you could have a page (eg.index.html) with a link http://../category1.html Even if /home/peter/catergory1.html exists the link should fail - not due to a restriction in Iceweasel - just sane webserver settings. That's not to say the server can't be misconfigured. Also as I'm sure you realise there's no way a file served on shaw.ca can link to Dalton without you setting up portforwarding and a web server (on Dalton) - even with insane firewall rules. > > Many Web pages contain links to pages on remote servers. Yes - that's completely different, and, it's one of the solutions I proposed. > >> ... a file link should point to somewhere on the same machine the link is >> served from ... > > "file:///"<path> is equivalent to "file://localhost/"<path>. This should be > true regardless of the origin of the URI text. Where a file URI poses a > significant threat, block it. The circumstance of viewing a file URI > doesn't change its meaning. Yes. I've never disputed that. Oh course a file link (file:///) in a web page can't link outside of the machine on which the page is viewed - unless the browser has the ability to support the files system (eg. sftp, nfs, cifs etc) and can be authenticated when authentication is required (most sane networking setups require authentication). With the following proviso:- If the page with the file link (file:///) is being served by a *remote* webserver - you need to turn off the restriction in the browser (as you have already done). Understanding that file link will actually point to a location on the viewing machine. Back before Firefox it used to be considered amusing to put a link in a publicly accessible web page like file:///C:/autoexec.bat and tell the visitor the world can view their file system (each person loading the page sees their own file system). That is what the default setting in Iceweasel prevents. > As I undertand http://kb.mozillazine.org/Security_Policies , Iceweasel with > the correct > settings in /etc/iceweasel/pref/iceweasel.js should open the file URI as I > describe. Does Iceweasel have a problem not existing in Mozilla? A Mozilla > forum or mailing list might help. Also I can file a bug report against > Iceweasel > and see what the maintainers say. That would be "maintainer" singular (Mike Hommey) - the man whose wish list is "more developer, more developers, and more developers". Before doing that - perhaps you could try with Firefox, Konqueror, Chrome, Lynx before you ask for a fix - just in case it's not brokenam. :-) The following works on my machines - no modification of browsers required:- <html> <head> <title>Category2</title> </head> <body> <p><a href="file:///home/scott/Category3.html">file</a></p> </body> </html> > > Thanks for the extensive discussion, > > ... Peter E. > And thank you for the semantic and mental exercise! Cheers -- We all pay for life with death, so everything in between should be free. ~ Bill Hicks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df8afdb.4060...@gmail.com
