People keep doing this, and it's frankly a poor decision every way round. We now have the ability to disable checkloaduri per-site, so let's get rid of the terrible global pref.
We should probably updated whatever documentation we have accordingly, too. And update the Mozillazine knowledge base.
Created attachment 195361 [details] [diff] [review] Er, the real thing
Created attachment 195362 [details] [diff] [review] Same as diff -w
12 years ago
Comment on attachment 195362 [details] [diff] [review] Same as diff -w yup, sr=dveditz
12 years ago
Fixed on trunk. So do we want this on the 1.8 branch? I'm tempted to say "yes"...
(In reply to comment #6) > Fixed on trunk. So do we want this on the 1.8 branch? I'm tempted to say "yes"... me too. a=me, but the 1.8 branch needs more than one driver at this point.
Comment on attachment 195362 [details] [diff] [review] Same as diff -w Well, let's go for approval and I'll see about writing up some docs for this.
Fixed on 1.8 branch.
Where is the UI to whitelist sites to access file:// URIs? I will need to be able to configure this in order to use my company's intranet. Do I whitelist the sites serving the HTML pages containing the file links, or the systems from which file URIs can be loaded?
there is no UI (other than about:config). you configure the sites that serve the HTML files with the links.
Thanks. I've just found http://kb.mozillazine.org/Links_to_local_pages_don%27t_work. <facetious> Do I understand that "capability.policy.default.checkloaduri" is an equivalent preference, and that this change is more about annoying corporate users than increasing security? </facetious> Really, I have no problem with removing support for cruft, and I guess this has forced me to learn about the policy system. Tell me, can that mechanism control when referer headers are sent?
> this change is more about annoying corporate users than increasing security? ... Obviously this change is not about annoying people. It is to make people only enable it for specific sites that require it, it is too much of a security problem to allow it to be enabled for every site.
This change was made because people were advising everyone in sight to set the old pref, which makes users vulnerable. By forcing people to use the new setup, which has existed for a while now, we make it so they have to enable access on a per-site basis (unless they mess with the "default" policy, of course, but we plan to not document that).
If its not annoying corporate users, its not making their lives any easier. bug 231529 added a pref that allowed enabling unprompted NTLM on intranet links using the pref: network.automatic-ntlm-auth.trusted-uris Now this requires another list at: capability.policy.localfilelinks.sites How about adding a global list of intranet sites at something like: network.intranet.uris which would be included at both places - to allow NTLM authentication, allow use of file:// links (which is primarily for windows based servers, not local hdd). PS: Wasnt aware of the new prefs when I made that blog post.
Feel free to file a followup bug on that. Patches accepted...
i use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 i edited the user.js: user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "http://intranetserver"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); i used the correct path, eg: file:///D:/images/blank.gif but the browser does not show the image. what did i wrong?
No idea; using those exact preferences works for me.
And how can the new scheme be used to link from mails to local content ? That worked with security.checkloaduri=false, but I cannot see how to enable it with the new scheme for all mails in all my mailboxes. Should it be mailbox://.... (I tried that once, but it didn't work) ? In our institute, this feature is heavily used to prevent sending huge papers locally to everyone (where it is saved then multiple times), instead providing a link from the mail to the local home directory of the respective user, which saves a lot of disk space and network bandwidth. If the new scheme cannot provide the access, I request the old switch be reintroduced for local content link from mails only until it is integrated in the current scheme (which is, btw, an *excellent* solution!).
> And how can the new scheme be used to link from mails to local content ? See bug 84128 comment 214 and bug 84128 comment 211. If nothing else, I suspect that "mailbox:" will work (unlike "mailbox://"). Compare http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#291
Bingo! It works with Seamonkey 1.0 and 'mailbox://' (but not mailbox: or mailnews://) . Thanks for that hint ! It should be documented somewhere, maybe at <http://kb.mozillazine.org/Links_to_local_pages_don%27t_work> where most of the related bugs point to.