I need to link from local server to multiple computers. It works if I save the page locally on each machine but does not when launched from the web server.
I've looked around and read that Chrome or other broswers is blocking access by default and i get the about:blank#blocked error
the link I am using is
a href="file://server/fileshare/Public/ProductionPDF/M511%20&%20M115IND/E511-11.pdf
file://server/fileshare/Public/ProductionPDF/M511%20&%20M115IND/E511-11.pdf
tried with IE, chrome, firefox and they do nothing. Chrome says about:blank#blocked error - IS there a workaround for this? I've searched a lot of other threads and just cant seem to find one with correct info.
This seems the reason: you need to use three lashes protocol for URI scheme.
For example :
Link
See this answer here: https://stackoverflow.com/a/18246357/11794267
Related
I found the following issue here in stackoverflow however cannot comment as yet. I have a similar issue and wonder if there is anyone out there that has solved it.
https://stackoverflow.com/questions/40917501/tfs-2015-web-portal-code-viewer-not-working#
I am encountering similar here. In house TFS 2015, can't view code in the web portal using Google Chrome however IE is fine. I, however, am not using HTTPS so may be experiencing something slightly different.
When I do try to view a file in Chrome, the window where the code listing should be is simply blank. I did note too that the button for creating a new build definition appears to be indicating a broken image link.
This has not always been an issue. Around 4 months ago I could get the code view fine in Chrome and, to my knowledge as I have no access to the servers, nothing has changed apart from Chrome updates.
I've tried getting to previous versions of Chrome to no avail, though I wouldn't know which version I was on when this did work.
Interestingly, I have one or two .MD files around and these display perfectly well. They are simple text files. However when saved with .TXT extension (or anything else I've tried), they do not show. Curious.
Update
As you will see from the screenshot below, when selection on a file has been made, in this case a .SQL file, where I would expect the view to populate nothing at all appears.
As for the F12, I do get 5 of these:
Failed to load resource: net::ERR_CONNECTION_REFUSED
plus associated paths of course. We use Webroot internally here which has recently dropped in a Chrome extension however even when Webroot is disabled in its entirety (including removal of extension) I get the same behaviour.
All other Chrome extensions have been removed too at varying times to try to give a clean browser.
I have no other pop up blockers, ad blockers, etc installed on the workstation.
Problem solved thanks to the F12 key suggestion.
After some grovelling I was granted domain admin privs to have a dig around everything. It turns out that TFS was installed on ServerA with a URL port of 8080, this I knew from the original install and obviously the path I follow to get to my TFS web interface. What had also been done subsequently, with no consultation of the Dev user group, was that a second TFS application tier had been installed on ServerB, the port here was 8088.
I had not noticed the difference in path initially, assuming it was Chrome or workstation related. Anyway, I altered the port on ServerB to 8080 and everything jumped into life. I should not have made assumptions and should have paid more attention to the path in the error!
It seems the second application tier was set up on a non-production environment to allow senior Dev users access to the TFS Management Console rather than allowing them access to the original app tier which was on a production box. Our IT Operations just forgot to tell anyone.
Try to update your chrome to latest version of (55.0.2883.87 m (64-bit)).
Also clear the cache of chrome. I have also encountered similar issues. The solution is clear cache and connect to the web portal use another ID, then connect back use the original ID. I have no idea which one solved the problem. You could try both.
This problem should only be an individual phenomenon, since TFS2015 has been released for a long time.
I'm trying to follow this procedure on Chrome's documentation:
http://www.chromium.org/administrators/linux-quick-start
Yet no policy is loaded by chrome. I tried to create the policies/managed and policies/recomended in /opt/google/chrome also but couldn't load the policies.
Is there any special configuration I have to make in order to load Chrome's policies ?
How can I know for sure what is the right place to put the policy file ?
This is part of a WIP trying to solve this question: Chrome Certificate Selection appears multiple times
It should be some cache or wrong parameter problem. As I discovered in Chrome discussion forum here: https://groups.google.com/a/chromium.org/forum/#!forum/chromium-discuss
in linux, Chrome and Chromiun have the same dir for policies, which is:
/etc/opt/chrome/policies/managed
if you put a valid file there it will load it. Double check the commas and parameters.
I am having the same issue. I placed my setting in
/etc/opt/chrome/policies/managed/managed_policies.json
The contents look like this:
{
“ExternalProtocolDialogShowAlwaysOpenCheckbox”: true
}
The file and all parent directories are readable by all users.
I tried reloading Chrome's policies via the url chrome://policy/ as well as restarting the browser and even the entire machine, but to no avail.
I am on Chrome 80 and Centos 7
What am I missing?
Thanks,
frank
/etc/chromium/policies/managed
this path worked for Chromium
I have a Web application that is hosted locally on Websphere. In the application there is a link to a .doc file located on a windows server.
CIT
The link was been working for years, but suddenly stopped working on all computers on the network. When I click the link, nothing happens. I checked the files path and name, and nothing has changed. The interface is viewed using IE8.
Does anyone have any clues onto why this isnt working or where I can look to resolve this?
edit: i have just noticed that the file (CIT_.doc) has been saved in the same directory, could this have an effect on it?
I'd imagine one of the following has occured:
The file has been moved or renamed
The K: drive has been re-mapped or other wise modified to a different location
A popup blocker is tampering with the link (because target="_blank")
In other words you need to manually check that file location within explorer, you also need to try a different browser.
Also you need to change the link to:
CIT
See here for the reason, you may also need to URLEncode it.
It probably has something to do with security settings that your network administrator has recently setup, seeing as the m.edmondson's answer does not work. Try it in another browser besides IE.
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
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.