MozillaZine

Talk:Links to local pages do not work

From MozillaZine Knowledge Base

Contents

Obsolete

The capability.policy.policynames , capability.policy.localfilelinks.sites and capability.policy.localfilelinks.checkloaduri.enabled settings are not defined by default in Thunderbird 10 and don't appear to be needed anymore. See http://forums.mozillazine.org/viewtopic.php?f=39&t=2429315

Could somebody update the article accordingly, with an explanation of when (if ever) they are needed? Tanstaafl 19:11, 17 February 2012 (UTC)


Security policy doesn't work

Maybe a good idea to rename/move this to Links to local pages do not work. The URL-encoded apostrophe makes links posted in forums look silly. Thoughts? Jonnyq

I would not be opposed to that. The reason a contraction was used in the first place was to mirror Image tooltips don't work. --Unarmed 15:15, 29 August 2005 (PDT)

I'm using Firefox 1.5 beta 1 but the solution provided here doesn't work for me. Does is work for anyone? --Agusmba 08:52, 26 September 2005 (PDT)

_______________________
I have gotten this to work for links to local files on my "C" drive...for example:
file:///C:/test.doc

...but I cannot get it to open files that are stored on a network drive. I have tried the following:
file:///H:/test.doc
file://///myservername/mysharename/test.doc
When I click on one of the links above, nothing happens. The formats are correct, however: if I right-click on the link, select "Copy link location", and paste it into a new tab, the file opens correctly.

All of this worked in Firefox 1.0.7 just fine.

So...it looks like the security policy capability in FF 1.5 isn't quite working correctly. --Steve66 08:25, 01 December 2005 (PDT)

I managed to get user_pref("capability.policy.default.checkloaduri.enabled", "allAccess"); to work, which I think is equivalent to the old way of doing it, which was user_pref("security.checkloaduri", false);
I couldn't get the policynames approach to work at all, not with local files nor with network shares. Steve66 can you describe exactly what you did to get it to work with local file names. I must be missing something.
BTW deletions are not managed gracefully. Once I had added user_pref("capability.policy.default.checkloaduri.enabled", "allAccess"); to user.js then I had to remove it both from user.js and from prefs.js to get it to go away. 80n 21:13, 1 December 2005 (UTC)
If you can get the default policy to work, you should be able to get the site-specific version working. Setting a default policy to ignore checkloaduri is a really bad idea when the alternative is available. --Unarmed 02:14, 2 December 2005 (UTC)
It is a bad idea but I don't have a better one - the alternative is broken - it doesn't work. 80n 08:43, 2 December 2005 (UTC)

New style doesn't work for me either... :(

With v1.5 (on windows), links like file://///server/directory/file.ext just don't work any more (they did in previous versions). I have the following lines in user.js:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://server");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

But it has no effect. Contrary to this article, the security.checkloaduri setting is still there, but again has no effect.

I actually also need links formated like file:\\server\directory\file.ext to work, as my company intranet uses MediaWiki, which can only create links in this style.

This change really breaks my company intranet.. :( -Sprintstar 11:27, 7 December 2005 (UTC)

security.checloaduri is only "still there" if you upgraded from an old profile. Your syntax is correct, but I suggest closing the browser and looking in prefs.js to make sure the new preferences were applied there and, if they were, that there isn't any cruft from previous attempts in there. The other problem may be that you've put user.js in the wrong place; in that case, just use the ChromEdit extension to do your editing. --Unarmed 17:56, 7 December 2005 (UTC)
Thanks for your reply. You're right, I did upgrade from an old profile. My settings have been copied to prefs.js, and they're correct. I put user.js in the same place as prefs.js (C:\Documents and Settings\user\Application Data\Mozilla\Firefox\Profiles\t663obzx.default. I will uninstall Firefox completely and re-install it, that might help. -Sprintstar 08:39, 8 December 2005 (UTC)
I uninstalled Firefox, removed all the profile information, and re-installed it and now file://///server/directory/file.ext style links work, but file:\\server\directory\file.ext still don't work. Would it be possible to to allow links like this in future builds? -Sprintstar 09:23, 8 December 2005 (UTC)
Why not try setting $wgUrlProtocols to include file:\/\/\/\/\/ in MediaWiki?--Unarmed 00:13, 9 December 2005 (UTC)
Oh yeah, that allows me to use file://///server/directory/file.ext type links, which will do. Thank you.. :) -Sprintstar 10:43, 12 December 2005 (UTC)

I have a brand new install of 1.5.0.1, and the link do nothing

If I have a link file://///servername/share/test.doc, and click on the link, nothing happens, but like above, if I copy link location and paste in new window it does work.

I have not upgraded from an old profile. This is a fresh install of 1.5.0.1. I desperately need this to work.

You need to set the preferences as described in the article. --Unarmed 16:54, 8 March 2006 (UTC)


But checloaduri setting is still there and it is set ot false. Is this a dummy setting now?
As mentioned in the article, Firefox 1.5 uses a different preference than 1.0.x did, so if you're setting security.checkloaduri in Firefox 1.5 it's not going to do anything. --Unarmed 20:56, 8 March 2006 (UTC)

UNC Folders still not accessible in 2.0.0.1

I have tried various combinations, and the success scenarios are extremely limited. You can get HTTP-type access to UNC files if All of the following things are true:

  • You use a "5-slash" URL, e.g. file://///uncserver/something.fil
  • The thing you are linking to is a file, not a folder, AND
  • You put the link into an HTML file or type it in directly.

The 5-slash URLs still don't work when included in more on-the-fly documents, such as XML or a wiki. We've had to set up HTTP servers on several systems in part because of this limitation.

However, nothing works the way it needs to -- to simply provide a link to some UNC folders. At our site, we need users to visit folders via UNC, so they can navigate and use files without having to download copies of everything to their own systems. A certain other web browser, which shall remain nameless, handles 5-slash and 2-slash UNC links exactly the way we need them to.

If UNC creates some security vulnerability, Firefox should let the end-user know about it, and let them decide if they want to take the risk.

-- Miles Duke 17:52, 9 February 2007 (UTC)

I've just tried a UNC folder and it works fine.--Np 18:05, 9 February 2007 (UTC)