Re: Re (4): Configuring Iceweasel security policies.
On 16/06/11 12:29, peasthope@shaw.ca wrote:
> From: Scott Ferguson <prettyfly.productions@gmail.com>
> Date: Wed, 15 Jun 2011 23:12:59 +1000
<snipped>
>
>> Does it work with Lynx - Konqueror, Opera, Chrome, or any other web
>> browser??
>
> Dalton's address is 142.103.107.137. In these tests, file:///Category2.xhtml
> and file://142.103.107.137/Category2.xhtml should have the same meaning.
>
> When these file URI are retrieved from the remote server,
> elinks opens file://142.103.107.137/Category2.xhtml and file:///Category2.html,
> lynx and w3m open file:///Category2.html but not file://142.103.107.137/Category2.xhtml
My understanding is that lynx doesn't support xhtml by default - it can
though:-
http://www.kolpackov.net/projects/lynx/xhtml.xhtml
w3m only support xhtml 1.0
Try not using an xhtml file - I suspect you are complicating your tests.
I'm not understanding why you are using the ip address - even localhost
is redundant... with file:/// links localhost is the default root....
> and Iceweasel, Chromium and Opera open neither. Have yet to try Firefox and Konqueror.
Hmm - do you mean that you are using a local copy or the page served by
shaw.ca??
If it's the latter, then they (sic) are displaying safe behaviour. You
*did* change the restrictions in Iceweasel (about:config) didn't you?
(sorry if you've previously clarified that - I haven't had time this
evening to reread all the previous threads/posts.)
>
>> 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?
>
> Web page editing is done at home and also at work. A local copy would have
> to be kept at both sites. That introduces the problem of site consistency.
It's a very common scenario. I'd hesitate to describe it as a problem.
More a feature of sane, standard, site development.
The usual procedure is to test on a non-public development server - only
migrating the changes to the productions server when proven.
I generally test changes on a server in a virtualbox machine before
pushing them to the development server (belt and suspenders).
For a static site such as yours I suggest you just tar.bzip
/home/peter/public_html (on shaw.ca). Call it public_htmlxxxx.tar.bz2
where xxx is the date and time.
Change control can be as simple as creating a file without contents
using the date and time as a name before archiving.
eg.:-
$ touch `date | sed 's/ //g'`
A later dated archive always replaces an earlier dated archive. And a
changes text file can be used to keep track of versions.
On my development and vb machines I just use mc for creating archives
(they are headless and accessed with ssh). eg. from inside public_html
select the menu (F2) in mc and choose "Compress the current subdirectory
tar.bz2" you'll be prompted for a filename - the default will be
"public_html" - just change it include the date and time.
You'll wind up with /home/peter/public_html_instance.tar.bz2
> The simplest solution is to keep just one copy on flash storage and carry
> it with me from one site to the other. There is already a CF card used
> this way on the ETHNO systems. So I would be adding a second flash store.
> Then I would have the primary copy of some files on the CF card and other
> files on the flash used in the Debian systems. I prefer to avoid that.
Good idea (avoiding that) - it robs you of a history of changes, and
it's to easy to fail to include files, include files not needed.
> Another possibility is to jettison the ETHNO systems and
> use only a Debian system at each site. I have trouble jettisoning a simple
> and reliable system which is really efficient for most elementary tasks.
If it ain't broken....
> The file URI would be helpful if it worked. A compromise is to first open
> the testing copy of Category2.xhtml on Dalton, using the Iceweasel or Chromium
> application menu. As long as the window remains open, the file can be
> retested with the refresh button. One click.
Yes. You'll still retain the last but one change (~)
>
> Meanwhile, I'll pursue fixing the response to the file URI.
>
>> As you are only serving static files you might
>> even be able to use rsync or sftp/fish to achieve the same thing.
>
> ftp is good for home to shaw.ca. By extension through the VPN tunnel,
> ftp also works from the "work" site to shaw.ca. FTP is fast!
Even faster when it's only moving a tar.bz2!
<snipped>
>
>> 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.
>
> Exactly the feature appearing not to work as it should according to Mozilla
> Security Policy.
You may have found a difference between Firefox and Iceweasel....
>
>> 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.
>
> Yes, "each person loading the page sees their own file system".
> "the world can view" implies public access; I'm fairly sure you didn't
> mean that.
I meant the viewer is fooled into thinking the world can see their files
- at the time there was stories that said it did. A bit like the story
that mobile phones cause explosions - if 15 million idiots believe a
stupid thing - it's still stupid. But if 5 journalist repeat it.... :-(
>
> No objection to the default setting. My complaint is that the instructions
> in Mozillazine Security Policy are not working.
Check and correct. Otherwise people may cease to RTFM :-D
<snipped>
>
>> The following works on my machines - no modification of browsers required:-
>
> That is your own Category2.html file? You get the link from my primary page
> or your's? If the second case, where does it reside?
It's my creation (but you welcome to it!) - both Category2.html and
Category3.html reside in the same location. I did try numerous
variations in an attempt to see your perspective.
>
> Thanks, ... Peter E.
>
>
Cheers
--
We all pay for life with death, so everything in between should be free.
~ Bill Hicks
Reply to: