Intranet site using "File://" to browse shared folder

[Bedders]

Hi all, this is a strange and irritating one that I am hoping someone else on here has some experience with or might be able to shine some light around.

 

We've moved to Windows 10 Pro x64 and on our Intranet we have the ability to browse a directory. This directory is shared in a central location, and the user 'Everyone' has Read Only access to it. This file browser is simply an iFrame with the 'src' set to "file://SERVER-NAME/SHARED-DIRECTORY". We can now no longer open PDF or Excel documents from this page.

 

I've outlined below the behaviour on different operating systems & browsers.

 

Many thanks

 

[table=width: 1200, class: outer_border]

[tr]

[td]Operating System[/td]

[td]Google Chrome[/td]

[td]Internet Explorer 11[/td]

[td]Microsoft Edge[/td]

[/tr]

[tr]

[td]Windows 7[/td]

[td]Does not display directory, just a blank space[/td]

[td]Opens directory fine, allows traversal, opens PDF/XLS(X)/DOC(X) files fine[/td]

[td]N/A[/td]

[/tr]

[tr]

[td]Windows 10[/td]

[td]Does not display directory, just a blank space.[/td]

[td]Opens directory fine, allows traversal, opens DOC(X) fine. Nothing happens when I try to open PDF files with Adobe Reader. Right-Click -> Open with Word successfully converts and opens. XLS(X) files open Excel but not the actual document.[/td]

[td]The directory gets opened in Windows Explorer, allows traversal, opens all files (as expected).[/td]

[/tr]

[/table]

Edited May 16, 2018 by Bedders

[Bedders]

Just to add that I've also posted this on Experts-Exchange. I've been unable to find anything out using my GoogleFu, so having this in the public domain in a couple of places might be useful to anyone else experiencing the issue. (INTERNAL VOICE) If there is anyone else...

[themightymrp]

I can tell you that Chrome removed the ability to open file:// links a while ago which messed up our intranet page, forcing a redesign. I think there is an add-on to enable it but I had little joy with this.

 

Could it be something to do with adding it to trusted sites? You know how they like to mess things about at Microsoft, they've probably added a security feature to prevent accidental malware launching.

[Bedders]

Hmm @themightmrp that's an interesting point. I did try adding the intranet page to Trusted Sites, but it's recognised as a Local Intranet page anyway I'm not sure if it will make a difference.

[Arthur]

This might be a stupid question, but is there any reason you couldn't do the directory listing through http:// or https:// rather than file://? e.g.

 

SimpleHTTPServer: a quick way to serve a directory

[Mako]

This might be a stupid question, but is there any reason you couldn't do the directory listing through http:// or https:// rather than file://? e.g.

 

SimpleHTTPServer: a quick way to serve a directory

 

This.

 

You say you have an intranet site, this could be hosted on an internal web server or merely be an index.html file in a shared folder, naturally iframe'ing just another shared folder.

 

If it's on a web server, then use appropriate URL's to embed the content. Chrome will display the folder if it's been referenced to appropriately. If you have a mix of the two (your intranet runs on a local web server but is referencing a file/folder elsewhere on the network) then you'll need to copy the folder to the web server and reference it locally. (i.e rather than )

Edited May 17, 2018 by Mako

[Bedders]

We actually have the Telerik addons for Visual Studio, including something that will do this https://www.telerik.com/products/aspnet-ajax/fileexplorer.aspx. However I suspect the intranet site itself would require republishing, and as it was created using old versions of Visual Studio and accompanying modules it would involve extensive re-testing (most of our reports are on there).

 

I did come to the conclusion last night to just redo that page and hope for the best. I'm hoping it doesn't come to that.

[Marci]

See Same Origin policy introduced in (decent) browsers quite some time ago: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

 

You have to disable that within your browser of choice (if it lets you) and then ensure that the Cross-Domain Policy is also set to allow it via CORS. Ultimately, the file URL protocol was deemed a security risk, hence these measures being put in place. Best bet: serve all files to a browser appropriately over http(s).

[Bedders]

Thanks for your help all, especially @Marci - you've guided me to the right answer.

 

For some reason it appears as though we have Protected Mode enabled for our Local Intranet zone. Once this is disabled, we get a security warning when opening the files but they do open. Why this makes a difference on Windows 10 when it worked on Windows 7 I do not know.

 

Cheers