Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 207
  • Last Modified:

file URLs not responding

I have a Drupal 6 intranet site.  We have numerous hyperlinks to files stored on our file server.  These links are "file" links - e.g. "file://server/shared/myfile.doc"
They had been working fine for months and then suddenly they stopped working.  When the user clicks on the URL, nothing happens.  Pointing at the URL makes the cursor switch to the pointer finger - indicating it's clickable - and the path appears in the status bar, but nothing happens when you click on it.
This behavior occurs in IE, Firefox, and Chrome.
No updates have been made to Drupal.
If I do a View Source on the page, copy the HTML to a blank HTML file, save it, and then open that file, the links work fine!  If I save the original page directly, it is saved as an mht file and then I open that, the links do not work.
I am at a loss of where to look to identify the source of this problem.
Any ideas would be MUCH appreciated.
Dale
0
dalevv
Asked:
dalevv
  • 6
  • 4
2 Solutions
 
dalevvAuthor Commented:
I should add that I did try switching to the standard Garland theme in Drupal and it didn't affect the problem either.
0
 
Dave BaldwinFixer of ProblemsCommented:
You probably had a change in persmissions on the server or a Windows update on the server that changed permissions.  Maybe someone 'helped' you by tightening security on the server.
0
 
dalevvAuthor Commented:
Thanks Dave, but I don't see how this would be an issue.  The exact same file links work fine on a saved HTML page - so there is no permission problem accessing the files from the server.  They just don't seem to work as presented by the CMS.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Dave BaldwinFixer of ProblemsCommented:
Where is the HTML page saved?  On your computer where you are logged in or on the server?  Those are different permissions.
0
 
dalevvAuthor Commented:
I don't see where any permissions come into play other than those necessary to access the file referenced in the URL - which are fine as evidenced by the fact that if I copy the HTML containing the links to a plain HTML file (as opposed to the page served up by the CMS and web server), the links work fine.  And, actually, if I save the page directly from the browser, it saves as an "mht" file on my local drive and the links do not work then either.  Only if I copy the HTML code from a View Source screen and save that as an html file do the links work.
It seems like there must be some content in that page that is disabling or intercepting those links.  But if so, why wouldn't I see that in View Source.
0
 
Dave BaldwinFixer of ProblemsCommented:
Firefox has always blocked access to 'file://' URLs http://kb.mozillazine.org/Links_to_local_pages_don%27t_work so if you were accessing them, you had implemented one of the workarounds.  Chrome and Safari also block 'file://' access under normal conditions.  And IE8 did that for IE http://stackoverflow.com/questions/2762819/how-do-you-get-the-file-protocol-to-work-in-ie8 .

Also, access to a web server is normally under an 'anonymous' user with limited privileges which are quite different from your privileges on files you have created under your user privileges.

And if you say "I don't see" again, I'll have to conclude that you are not looking at anything.
0
 
dalevvAuthor Commented:
When you click on a "file" link the request doesn't go back to the web server, so your "anonymous" rights are irrelevant.  Your rights as whatever user you are logged in as are relevant because your browser is the one trying to open the file directly.  As I've established, my logged in user can open the links because the exact same link works properly from a regular html page.
However, your link to the stackoverflow article was helpful since it mentions that the browser DOES differentiate between a page downloaded via HTTP and one just opened as a file...in that some browsers automatically disable file URLs on downloaded pages.  So I'm thinking that is what's happening.  The strange part is why did it show up all of the sudden.  There have been no web server changes (it's apache, so no auto-updates), and I've got machines running IE7,IE8,and IE9 and they all have the same issue, so it's not a browser version issue.....unless there was a security update to all the browswers...
0
 
dalevvAuthor Commented:
Well, it's solved.  The stackoverflow article that DaveBaldwin gave me started me down the right track - that the browser was the issue.   I've been using IE - so others may have different resolutions.  My problem, it turns out, was that because of referencing our Intranet site using the fully qualified name - e.g. intranet.myplace.abc, instead of just using "intranet", IE saw it as a site from  the "Internet" security zone.  So when a page from that site tried to reference a page in the "Local Intranet" or "Trusted Sites" zone, it rejected those attempts.   So I think the change that occurred may have been in how we referenced the site.
Here's an article about this: http://windowsxp.mvps.org/ie/elevlocalfile.htm
So, the fix is to add the Intranet site to the "Local Intranet" zone or trusted sites.
0
 
dalevvAuthor Commented:
Dave's post identified the root cause of the issue, I found the resolution for my specific problem, so that's why I'm splitting it.
0
 
Dave BaldwinFixer of ProblemsCommented:
Thanks and that's good to know.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now