Mitchell had commented that domain based exceptions to this feature might be a good idea, and I could not find an RFE on that feature, so I'm creating it here... I propose the following: A preference that accepts some kind of paired URL prefix. The first part describes URLs allowed to make an exception to get file: URL access to the second expression. For example: http://www.packetgram/push/* + file:/usr/local/push/* (Someone can probably come up with saner syntax, but you get the idea). The pref could be in the UI, or via the next-gen Mission Control, or hacking prefs.js, this should be discussed. Interestingly, this would be much more secure if you used https: in the first pair, because it would prevent spoofing of references to the local filesystem.
Ben and I discussed this. I may do it if there's a huge demand. In the meantime, we have the binary "security.checkloaduri" pref.
This would probably be the most direct way of giving people what they want in bug 84128. Right now, if you turn off checkloaduri, it is all-or-nothing.
Finally I found it! Yes, you need something like this to allow mozilla to be used as a replacement for IE in intranets. Perhaps you need three columns: ALLOW: remote protocol domain local protocol http *.math.clemson.edu file://///* https *.clemson.edu file://///* DISALLOW: remote protocol domain local protocol: https *.students.clemson.edu file:* and I think this should default to: ALLOW remote protocol domain local protocol: https <local domain determined by IP address> file:///*
How would this work for file:// links within emails?
If so then bug 135830 should probably be marked as a dupe
You could have the sending domain of mail be assumed to be the domain of the base, but this is too easy to forge. People should not be sending file URL's in documents they create, even though MailNews does this all the time in "Send Page" (bug 136782).
Unless of course it's internal email within a company where everyone has access to a shared network drive. At which point file:// links make perfect sense as it means people aren't clogging up the email system with lots of attachments.
We in our institute are DAILY sending file URL's in mail because we don't want to have our people have to save or to download papers to which they have local access anyway. So the typical thing we do is to send a mail with a file URL where to find the document. I think this is a perfectly legitimate and space and network traffic saving habit.
(coming here from bug 233108 comment 21) A configured site+directory pair would be perfect to solve my case in bug 264968 comment 11 too: something like 'http://www.battle-arenas.net/* <-> file:///W:/Progs/@Battle-Arenas/ba_pack/*'.
This is my situation. I have been fighting this bug/issue since Netscape 4 days, and I have seen many bugs and comments about it. This problem is still there in FireFox 1.0. It is reproducible at will. If the CheckLoadURI problem can't be fixed, can we at least have a totally insane and unsecure option that will allow us to link to file://f:/some.file bypassing ALL security? Please! I thought the CheckLoadURI setting was supposed to allow this, but it doesn't. It never did, as far as I can tell. The only thing that works right now is to load IE 5.5 and make it my default browser, or force my users to right-click and open in a new window which launches IE as well. Then I can email a link to a file on my server and have it work. Thank you. (In reply to comment #8) > We in our institute are DAILY sending file URL's in mail because we don't > want to have our people have to save or to download papers to which they > have local access anyway. So the typical thing we do is to send a mail > with a file URL where to find the document. I think this is a perfectly > legitimate and space and network traffic saving habit.
(In reply to comment #1) > In the meantime, > we have the binary "security.checkloaduri" pref. This works, and bug 233108 improved this recently :-) Usage examples: see bug 84128 comment 194 and 199 ! (In reply to comment #10) > A configured site+directory pair would be perfect to solve my case in bug 264968 > comment 11 too: > something like 'http://www.battle-arenas.net/* <-> > file:///W:/Progs/@Battle-Arenas/ba_pack/*'. What we still miss is the "file path" part: this bug !
(In reply to comment #13) > See bug 84128 comment 264 For those who want to read that comment (or not): it is about "Suggestion: Track security level of operations requesting opening URL, modeling after the Java privileged block API.".
Is this the same as Bug 233108 ?
What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it works untill Firefox 1.0.x . In version 1.5 this old security violation message popup in the java-console-view, but the file isn't loaded. In about:config my parameter is still set to "security.checkloaduri=false".
(In reply to comment #17) > What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it > works untill Firefox 1.0.x . In version 1.5 this old security violation message I guess you should try the |user_pref("capability.policy.xyz", "xxyyzz");| preferences after "Gecko/Trunk" v1.8a5. Probably, this bug should be morphed to take this into account !!?
It's been almost 7 years since this enhancement request has been opened and 2.5 years since the last comment. I've been tracking the related bug #84128 (which is even older than this one), and just came across this item. A solution to this enhancement request would be better than just the user-visible warning bug #84128 is asking for, so... any updates? And, no, asking users to install "IE Tab" or edit their prefs.js, etc, is not acceptable. We have GUIs (of a sort) to allow users to allow blocked pop-ups from certain sites. Why can't we have the same type of notification & override for "blocked" file:// URLs? I don't see why blocked file:// URLs should be treated any differently than pop-ups from the USER'S point-of-view. They are both things that are annoying and/or dangerous, but there are times & sites for which you NEED those things (esp. if it's something that you explicitly clicked on!). Thanks, Jim