On an intranet site, let's say I want to link to a file on a share using UNC, at:
\\servername\foldername\filename.rtf
It seems the correct way to do this is with markup like this:
filename.rtf
That's five slashes - two for the protocol, one to indicate the root of the file system, then two more to indicate the start of the server name.
This works fine in IE7, but in Firefox 3.6 it will only work if the html is from a local file. I can't get it to work when the file comes from a web server. The link is "dead" - clicking on it does nothing.
Is there a workaround for this in Firefox? Those two browsers should be all I need to worry about for now.
Since this is obviously a feature of Firefox, not a bug, can someone explain what the benefit is to preventing this type of link?
This question has been asked at least twice before, but I was unable to find those posts before posting my own (sorry):
Open a direct file on the hard drive from firefox (file:///)
Firefox Links to local or network pages do not work
Here is a summary of answers from all three posts:
Use WebDAV — this is the best solution for me, although much more involved than I had anticipated.
Use http:// instead of file:///// — this will serve up a copy of the document that the user cannot edit and save.
Edit user.js on the client as described here — this worked for me in Firefox 3.6.15, but without access to client machines, it's not a solution.
In Firefox, use about:config, change the Security.fileuri.strict_origin_policy setting to false — this doesn't work for me in 3.6.15. Other users on [SO] have also reported that it doesn't work.
Use the locallinks Firefox extension — this sets the Security.fileuri.strict_origin_policy to true for you, and appears to have no other effect.
Read the file server-side and send it as the response — this presents the same problem as simply configuring your web server to use http://.
Browsers like Firefox refuse to open the file:// link when the parent HTML page itself is served using a different protocol like http://.
Your best bet is to configure your webserver to provide the network mapped file as a web resource so that it can be accessed by http:// from the same server instead of by file://.
Since it's unclear which webserver you're using, I can't go in detail as to how to achieve this.
In Firefox to Open File:\\\\\yourFileServer\docs\doc.txt for example you need to turn on some options in Firefox configuration:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://yourServer1.companyname.com http://yourServer2.companyname.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
As it turns out, I was unaware that Firefox had this limitation/feature. I can sympathize with the feature, as it prevents a user from unwittingly accessing the local file system. Fortunately, there are useful alternatives that can provide a similar user experience while sticking to the HTTP protocol.
One alternative to accessing content via UNC paths is to publish your content using the WebDAV protocol. Some content managements systems, such as MS SharePoint, use WebDAV to provide access to documents and pages. As far as the end-user experience is concerned, it looks and feels just like accessing network files with a UNC path; however, all file interactions are performed over HTTP.
It might require a modest change in your file access philosophy, so I suggest you read about the WebDAV protocol, configuration, and permission management as it relates to your specific server technology.
Here are a few links that may be helpful if you are interested in learning more about configuring and using WebDAV on a few leading HTTP servers:
Apache Module mod_dav
IIS 7.0 WebDAV Extension
Configuring WebDAV Server in IIS 7, 6, 5
Add your own policy, open configuration "about:config" in the location bar and add three new entries:
capability.policy.policynames MyPolicy
capability.policy.MyPolicy.sites http://localhost
capability.policy.MyPolicy.checkloaduri.enabled allAccess
Replace http://localhost with your website.
Works with Firefox 70.0.
I don't know if this will work, but give it a shot! Old article, but potentially still useful.
http://www.techlifeweb.com/firefox/2006/07/how-to-open-file-links-in-firefox-15.html
Related
I'd like to have an html file that organizes certain files scattered throughout my hard drive. For example, I have two files that I would link to:
C:\Programs\sort.mw
C:\Videos\lecture.mp4
The problem is that I'd like the links to function as a shortcut to the file. I've tried the following:
Link 1
Link 2
... but the first link does nothing and the second link opens the file in Chrome, not VLC.
My questions are:
Is there a way to adjust my HTML to treat the links as shortcuts to the files?
If there isn't a way to adjust the HTML, are there any other ways to neatly link to files scattered throughout the hard drive?
My computer runs Windows 7 and my web browser is Chrome.
You need to use the file:/// protocol (yes, that's three slashes) if you want to link to local files.
Link 1
Link 2
These will never open the file in your local applications automatically. That's for security reasons which I'll cover in the last section. If it opens, it will only ever open in the browser. If your browser can display the file, it will, otherwise it will probably ask you if you want to download the file.
You cannot cross from http(s) to the file protocol
Modern versions of many browsers (e.g. Firefox and Chrome) will refuse to cross from the http(s) protocol to the file protocol to prevent malicious behaviour.
This means a webpage hosted on a website somewhere will never be able to link to files on your hard drive. You'll need to open your webpage locally using the file protocol if you want to do this stuff at all.
Why does it get stuck without file:///?
The first part of a URL is the protocol. A protocol is a few letters, then a colon and two slashes. HTTP:// and FTP:// are valid protocols; C:/ isn't and I'm pretty sure it doesn't even properly resemble one.
C:/ also isn't a valid web address. The browser could assume it's meant to be http://c/ with a blank port specified, but that's going to fail.
Your browser may not assume it's referring to a local file. It has little reason to make that assumption because webpages generally don't try to link to peoples' local files.
So if you want to access local files: tell it to use the file protocol.
Why three slashes?
Because it's part of the File URI scheme. You have the option of specifying a host after the first two slashes. If you skip specifying a host it will just assume you're referring to a file on your own PC. This means file:///C:/etc is a shortcut for file://localhost/C:/etc.
These files will still open in your browser and that is good
Your browser will respond to these files the same way they'd respond to the same file anywhere on the internet. These files will not open in your default file handler (e.g. MS Word or VLC Media Player), and you will not be able to do anything like ask File Explorer to open the file's location.
This is an extremely good thing for your security.
Sites in your browser cannot interact with your operating system very well. If a good site could tell your machine to open lecture.mp4 in VLC.exe, a malicious site could tell it to open virus.bat in CMD.exe. Or it could just tell your machine to run a few Uninstall.exe files or open File Explorer a million times.
This may not be convenient for you, but HTML and browser security weren't really designed for what you're doing. If you want to be able to open lecture.mp4 in VLC.exe consider writing a desktop application instead.
If you are running IIS on your PC you can add the directory that you are trying to reach as a Virtual Directory.
To do this you right-click on your Site in ISS and press "Add Virtual Directory".
Name the virtual folder. Point the virtual folder to your folder location on your local PC.
You also have to supply credentials that has privileges to access the specific folder eg. HOSTNAME\username and password.
After that you can access the file in the virtual folder as any other file on your site.
http://sitename.com/virtual_folder_name/filename.fileextension
By the way, this also works with Chrome that otherwise does not accept the file-protocol file://
Hope this helps someone :)
Janky at best
right click </td>
and then right click, select "copy location" option, and then paste into url.
back to 2017:
use URL.createObjectURL( file ) to create local link to file system that user select;
don't forgot to free memory by using URL.revokeObjectURL()
I've a way and work like this:
<'a href="FOLDER_PATH" target="_explorer.exe">Link Text<'/a>
Does using Chrome v.63 force use of https?
I am running Apache 2.4.27 on a Windows 10 desktop as a sandbox where I can experiment and do some tutorials. I have a virtual host setup called www.tutorial.dev with an alias of tutorial.dev. In the Windows 10 hosts file I have set up www.tutorial.dev and tutorial.dev to point to localhost.
As of yesterday the url http://tutorial.dev/Bootstrap4FromScratch/ was working normally. In this case providing a directory listing as a jump off point into various examples and exercises. Today, when I type in the url Chrome changes it to https and I get a connection refused message.
I understand the connection refused message. There are no certificates setup.
The only change I can find is that Chrome changed from v.62.x to v.63.x. What in Chrome 63 could be forcing http to https?
I don't have this problem with MS Edge. I tested another similar configuration on a different machine that was in the process of downloading Chrome 63.x. It already had 62.x installed. It worked until the 63.x upgrade was complete then the same problem occurred.
Additional information: If I use http://localhost to bring up the index.html or version.php in the htdocs directory the switch from http to https does not happen. The virtual host www.tutorial.dev resides in another directory outside of htdocs.
If this has been asked and answered please point me to the question/answer thread.
Thanks in advance,
Barry
Google owns the .dev TLD and with Chrome 63 they are forcing HTTPS on all requests to anything.dev
I went through my local dev setup and replaced all references to .dev with .local, works fine now.
Your other option is to use Firefox for local development. .dev now triggers https in FF (since before FF61) with a workaround
Edit (asside):
I have switched to using .localhost for dev as browsers allow navigator.geolocation.getCurrentPosition() (blocked if site is not HTTPS).
Google Chrome 63 update, out December 2017, places .dev domains in the preloaded HSTS list with a rule enforcing HTTPS, no workarounds.
{ "name": "dev", "include_subdomains": true, "mode": "force-https" }
The "only" way is to switch .dev with something else, like .localhost
IETF states a few reserved TLDs for development:
TLDs for Testing, & Documentation Examples
There is a need for top level domain (TLD) names that can be used
for creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.
For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
The ".localhost" TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
PS: .foo is also in the preloaded HSTS list
Thanks everyone for the advice. I ended up going with .tst for now. I have a feeling I'l be switching over (forced?) to .localhost at some point. But for now .tst is less typing.
I have finished an extension for my company and I want to put it on the company wiki so that in order to get it on everyone's machine all I have to do is go around and click the link.
First, I HAVE READ all the documentation from http://developer.chrome.com/extensions/hosting.html about hosting and autoupdating and all that. Part of it confuses me and I can't find any more information about this:
Google Chrome considers a file to be installable if either of the following is true:
The file has the content type application/x-chrome-extension
The file suffix is .crx and both of the following are true:
The file is not served with the HTTP header X-Content-Type-Options: nosniff
The file is served with one of the following content types:
empty string
"text/plain"
"application/octet-stream"
"unknown/unknown"
"application/unknown"
"*/*"
This looks like it wants a MIME style setup? but I have never done anything with this. I have the ability to change what I want to the Locally hosted Wiki, all I need is to understand what need to change to make the link installable. I will keep looking for examples.
Note: The reason it is not going on the app store is that there is really no reason to. It is branded for our company, and communication with our specific servers is hard-coded into it.
In version 21 (or so), Chrome disabled the ability to do a simple link-click install of off-store extensions. There is a discussion of the change in this bug report:
You are no longer supposed to be able to install extensions off-store in Chrome... In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.
There is, therefore, no longer any way to install an extension simply by clicking a link, except by hosting it in the Web Store. You will need to download the file and then drop it into chrome://extensions.
The documentation you reference looks out of date (that's Google's fault, not yours). It definitely fails to mention the new drag-and-drop requirement. It also talks about the file's "content type" and the X-Content-Type-Options HTTP header required to make the CRX installable; however, when you install an extension by dropping it into chrome://extensions, I doubt very much that Chrome remembers what HTTP headers were set when you first downloaded the file.
EDIT: You can also use the --enable-easy-off-store-extension-install command line flag to restore the old instalation behavior.
You can do an "inline install" of an app hosted on the web store. The new changes are forcing people to move our extensions to the web store, but the inline installation should allow your users to not need to leave your page to install.
Okay, so I'm a student programmer in my college's IT department, and I'm doing browser compatibility for a web form my boss wrote. I need the user to be able to open a local file from a shared drive with a single click.
The problem is that Firefox and Chrome don't allow that for security reasons. Thus, I'm trying to write a custom protocol of my own to open an address in Internet Explorer regardless of the browser being used.
Can anyone help me with this? I'd also be willing to try an alternative solution to the problem.
The below worked for me, is this what you mean?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo]
#="URL: foo Protocol"
"URL Protocol"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\DefaultIcon]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open\command]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe \"%1\""
Just to note, I'm running Win7Pro, so you may have to move around file path(s) to conform to your environment.
And if that doesn't work, create a proxy between the protocol and the browser, pass the argument(s) from foo:// to that, parse what's necessary, then hand it off to IE using start iexplorer.exe "args".
I'm unsure whether I understand your question, if it is how do I open local files using chrome/firefox, this is your anwser:
First a disclaimer, I have never done this and cannot vouch for the accuracy of my response
IE
Microsoft's security model is pretty fail so you can go right ahead and open these files
FireFox
Some quick googling found that Firefox can do this after either editing prefs.js as outlined here or installing an addon called LocalLink
Chrome
Practically impossible due to its security, until now when locallink was ported to chrome.
Maybe some of you could have ran into the same problem i did.
Imagine you have a file on your machine: file:///c:\test.html
And you have an IFrame inside of this file. You need to indicate whether the IFrame contents are loaded or no.
Bacically, what we have here:
1. location, href, or any other property is inaccessible from file:/// to http:///, or backwards.
2. you can't fire event from the browser window in iframe, or in opposite direction, unfortunately.
Does this problem have a solution?
P.S.: that's not a hack. it's a real problem. making some interaction from local machine with website integration.
UPD: I kinda figure out why it's forbidden. ANY interaction with local files should be forbidden from the web page. It's kinda cool, i do agree. But isn't a # hashtag something that can't harm anyone? :(
You may find some of these techniques useful: http://softwareas.com/cross-domain-communication-with-iframes
Edit: Per comments below, these techniques don't seem to work when accessing file:///c:\<path>\test.html, whereas they do when accessing http://localhost/test.html.
I think that's because the file protocol is even more restricted by the browser than the http protocol. The MSDN page on the file protocol states:
Internet Explorer 6 Service Pack 1 (SP1) no longer allows browsing a
local machine from the Internet zone. For instance, if an Internet site
contains a link to a local file, Internet Explorer 6 SP1 displays a
blank page when a user clicks on the link. Previous versions of Windows
Internet Explorer followed the link to the local file.
Whatever technique you were using to get some cross-domain communication was probably blocked by the browser because you were using the file protocol.