RogueAce
asked on
Images with file:/// src attribute not displaying in IE7
I have a plug-in for Internet Explorer that displays images in certain web pages. To save bandwidth, the image is stored locally (distributed with the plug-in). I dynamically write an img tag with the src attribute set to file:///x:/path/to/image.g
Am I doing something wrong? The element I'm writing looks like this:
HTML Code:
===
<IMG src="file:///C:/Documents%
===
The code to insert it looks like this:
JavaScript Code:
===
var image = doc.createElement('img'); image.setAttribute('src', getIconURL()); image.setAttribute('border
===
getIconURL just does some magic to find the current user's application data folder and then returns the url you see above (or whatever URL is appropriate for the current user's computer, of course).
Help appreciated
Nathan
Am I doing something wrong? The element I'm writing looks like this:
HTML Code:
===
<IMG src="file:///C:/Documents%
===
The code to insert it looks like this:
JavaScript Code:
===
var image = doc.createElement('img'); image.setAttribute('src', getIconURL()); image.setAttribute('border
===
getIconURL just does some magic to find the current user's application data folder and then returns the url you see above (or whatever URL is appropriate for the current user's computer, of course).
Help appreciated
Nathan
ASKER
> have you tried calling the images from a different location, just to make sure that the problem indeed lies with the file:// etc.?
I'm not sure what you mean. Like, you think I should move the image to a different directory and try again?
> I do not use IE 7 or the file:// function, but it does sound like a nasty security question...
I think it is a security issue. However, I don't see why, as it's not like the local file is being returned to the remote server. I just want to save bandwidth by displaying a cached image (that I installed myself), not do something sneaky with the user's personal data.
Thanks for the reply,
Nathan
I'm not sure what you mean. Like, you think I should move the image to a different directory and try again?
> I do not use IE 7 or the file:// function, but it does sound like a nasty security question...
I think it is a security issue. However, I don't see why, as it's not like the local file is being returned to the remote server. I just want to save bandwidth by displaying a cached image (that I installed myself), not do something sneaky with the user's personal data.
Thanks for the reply,
Nathan
> have you tried calling the images from a different location, just to make sure that the problem indeed lies with the file:// etc.?
I meant e.g. "http://example.com/image.
>it's not like the local file is being returned to the remote server
I am way out of my league, so I am not going to speculate further about possible security issues.
>not do something sneaky with the user's personal data.
Not saying that you do ;)
Hmm... I tried using file:///C:/Documents and Settings/test.gif (using img src) with FX and it worked.
Try using a different location (http or directory) I would guess that your problem may lie in the script that you use, maybe some browser compatibility issue?
I do not think I could help you more than that (if I helped you at all), sorry.
Good luck to you.
I meant e.g. "http://example.com/image.
>it's not like the local file is being returned to the remote server
I am way out of my league, so I am not going to speculate further about possible security issues.
>not do something sneaky with the user's personal data.
Not saying that you do ;)
Hmm... I tried using file:///C:/Documents and Settings/test.gif (using img src) with FX and it worked.
Try using a different location (http or directory) I would guess that your problem may lie in the script that you use, maybe some browser compatibility issue?
I do not think I could help you more than that (if I helped you at all), sorry.
Good luck to you.
ASKER
> I meant e.g. "http://example.com/image.
I loaded the image in the browser to make sure it's not an image format problem, if that's what you're getting at. And like I said, it worked in IE6.
> Try using a different location (http or directory) I would guess that your problem may lie in the script that you use, maybe some browser compatibility issue?
Well, I looked at the code generated by the script, and it looks like a valid img tag (I gave that code in my original post). I think it's almost certainly a change with the security settings, so the question is, how can I do what I want (i.e. display a file stored on the user's local disk in a webpage) without causing IE7 to balk.
Thanks for trying to help me.
Nathan
I loaded the image in the browser to make sure it's not an image format problem, if that's what you're getting at. And like I said, it worked in IE6.
> Try using a different location (http or directory) I would guess that your problem may lie in the script that you use, maybe some browser compatibility issue?
Well, I looked at the code generated by the script, and it looks like a valid img tag (I gave that code in my original post). I think it's almost certainly a change with the security settings, so the question is, how can I do what I want (i.e. display a file stored on the user's local disk in a webpage) without causing IE7 to balk.
Thanks for trying to help me.
Nathan
Please confirm that the URL for the page doesn't use the file protocol (e.g. file:) but uses http, etc (e.g. http:).
If that is the case (URL for page is http: and you are trying to use file: in an element) that was a "bug" in IE 6 and it looks like they have fixed it. Firefox browsers would have the same issue. Even if you aren't trying to do something sneaky the same method can be used to do sneaky stuff. For user security the browser prevents it.
You might fix this by having the person add the page (actually the domain) to their trusted list. Like the other expert I haven't played with this and IE7 to know for sure but that will lower some of the security. It might lower just the one you need.
The other option would be to play with your own security settings to see if you can find one that will allow this. This would allow you to tell users what setting they need. There is a big downside to this though. Users would need to manually change the setting and might not want to because it would lower the setting for all pages. Since browsers already cache and use cached web images the advantage you are looking for isn't worth the risk it creates.
I hope this helps. Let me know if you have a question.
bol
If that is the case (URL for page is http: and you are trying to use file: in an element) that was a "bug" in IE 6 and it looks like they have fixed it. Firefox browsers would have the same issue. Even if you aren't trying to do something sneaky the same method can be used to do sneaky stuff. For user security the browser prevents it.
You might fix this by having the person add the page (actually the domain) to their trusted list. Like the other expert I haven't played with this and IE7 to know for sure but that will lower some of the security. It might lower just the one you need.
The other option would be to play with your own security settings to see if you can find one that will allow this. This would allow you to tell users what setting they need. There is a big downside to this though. Users would need to manually change the setting and might not want to because it would lower the setting for all pages. Since browsers already cache and use cached web images the advantage you are looking for isn't worth the risk it creates.
I hope this helps. Let me know if you have a question.
bol
ASKER
No, the URL does use the file: protocol, not http.
Nathan
Nathan
Nathan,
Thanks for the answer. When you said URL did you mean for the page (i.e. the main "web page" that has the plugin) or the URL for the image? Based on the original post and question it seems like this is a web page (i.e. Internet). If that is the case then in the browser the URL's protocol should be http: or something like it. Is that true or did I misunderstand something?
This won't work. It is something that can cause security issues. IE6 did allow this type of action more than other browsers but it is not safe. Of course I don't mean that you are doing anything bad, just the action itself can be exploited and cause security issues.
What type of "plugin" is this? If it isn't an ActiveX object then try it in Firefox. Does it work?
Did you try changing the Security setting in IE? The settings for Trusted sites (even Internet trusted) are slightly lower. I doubt this will work but you could try it since there is a chance. If it still doesn't work then can you save the file locally and run it? If it ends with an .hta extension and is a local file then the script security and settings are very loose. Of course I don't know if this will work for this project but I suggest it as an option if the page doesn't require the web server.
Let me know if you have a question about any of this or need more info.
bol
Thanks for the answer. When you said URL did you mean for the page (i.e. the main "web page" that has the plugin) or the URL for the image? Based on the original post and question it seems like this is a web page (i.e. Internet). If that is the case then in the browser the URL's protocol should be http: or something like it. Is that true or did I misunderstand something?
This won't work. It is something that can cause security issues. IE6 did allow this type of action more than other browsers but it is not safe. Of course I don't mean that you are doing anything bad, just the action itself can be exploited and cause security issues.
What type of "plugin" is this? If it isn't an ActiveX object then try it in Firefox. Does it work?
Did you try changing the Security setting in IE? The settings for Trusted sites (even Internet trusted) are slightly lower. I doubt this will work but you could try it since there is a chance. If it still doesn't work then can you save the file locally and run it? If it ends with an .hta extension and is a local file then the script security and settings are very loose. Of course I don't know if this will work for this project but I suggest it as an option if the page doesn't require the web server.
Let me know if you have a question about any of this or need more info.
bol
ASKER
Let me try to explain more clearly.
The plugin (IE toolbar) *inserts a local image* into an arbitrary remote webpage. Here's how it plays out (as an example):
1) User visits www.example.com
2) IE parses index.html and generates a DOM tree
3) The toolbar modifies the DOM tree, inserting a new node. The new node is represented by the HTML "<img src="file:///c:/foo/bar/my
Observations:
* I can't change the security settings. They are per-page, and this image insertion could happen on any given page. Changing the settings globally is not an option, for obvious reasons.
* Obviously, I can't try it out in Firefox.
Nathan
The plugin (IE toolbar) *inserts a local image* into an arbitrary remote webpage. Here's how it plays out (as an example):
1) User visits www.example.com
2) IE parses index.html and generates a DOM tree
3) The toolbar modifies the DOM tree, inserting a new node. The new node is represented by the HTML "<img src="file:///c:/foo/bar/my
Observations:
* I can't change the security settings. They are per-page, and this image insertion could happen on any given page. Changing the settings globally is not an option, for obvious reasons.
* Obviously, I can't try it out in Firefox.
Nathan
media content such as images are not allowed to be displayed by default from a local location with IE 7. What you have to do is add the site you are running this at to your trusted sites.
Tools > Internet Options > Security > Trusted Sites (Green Check Icon) > Then click the sites button which will be enabled after you click the green check Trusted Sites.
If you were running this at www.yoursite.com, you would have to add http://www.yoursite.com to your trusted websites. If you were running it on IIS, you have to type in http://localhost or whatever your local server is. If it's not an HTTPS location, then uncheck the "Require server verification (https:) for all sites in this zone" checkbox, then you can add whatever you want. Be sure you know what you're doing though. This is not a recommended approach if you will be running this application on a client's machine. If it's a local intranet that's typically ok. After you add the domain to the trusted sites, the image will show up as intended.
Hope this helps.
Tools > Internet Options > Security > Trusted Sites (Green Check Icon) > Then click the sites button which will be enabled after you click the green check Trusted Sites.
If you were running this at www.yoursite.com, you would have to add http://www.yoursite.com to your trusted websites. If you were running it on IIS, you have to type in http://localhost or whatever your local server is. If it's not an HTTPS location, then uncheck the "Require server verification (https:) for all sites in this zone" checkbox, then you can add whatever you want. Be sure you know what you're doing though. This is not a recommended approach if you will be running this application on a client's machine. If it's a local intranet that's typically ok. After you add the domain to the trusted sites, the image will show up as intended.
Hope this helps.
ASKER
Gewgala: Actually reading the thread (or even my last post) would have told you that this won't work: the url is being inserted by a plugin into any arbitrary page. IOW, the user would have to put the entire Internet in the Trusted Sites zone...probably not a smart move.
Nathan
Nathan
I'm saying that if you can't change the security settings then it's not possible. Try this: rename the HTML document that you are testing this with to have the .hta extension. See if it works with that. I don't know if you are familiar with .HTAs or not, or even what you plan running this application on. Is it going to be an intranet or something done locally or are you trying to do this on the web?
ASKER
On the web.
Once I get a chance I'll try out the hta trick, but again--we have no control over the web page, so even if it works then it doesn't really get us anywhere (changing the security perms for one page and then trying it on that page does work as well, though we already went through why that won't work).
If it doesn't work, it doesn't work. I think we will look into using the res:// protocol to access the image compiled as a resource, and if that doesn't work then maybe write our own protocol handler to get around IE's terminal brain damage.
Nathan
Once I get a chance I'll try out the hta trick, but again--we have no control over the web page, so even if it works then it doesn't really get us anywhere (changing the security perms for one page and then trying it on that page does work as well, though we already went through why that won't work).
If it doesn't work, it doesn't work. I think we will look into using the res:// protocol to access the image compiled as a resource, and if that doesn't work then maybe write our own protocol handler to get around IE's terminal brain damage.
Nathan
I feel you, browsers in general are very difficult to work with sometimes. .HTA stands for Hypertext Application, basically what happens is the user's operating system treats it as an application that's compiled, it has full rights (read/write) on the users machine and doesn't need to step through all the security checks for activeX controls and such, it just executes everything. It can be very helpful when you put iFrames that have your pages on them inside the .HTA file. The only catch though is it's not really suitable for online purposes because when you type in a URL that points to it, a RUN / SAVE / CANCEL dialogue box shows up. If the user clicks run that it's all good and you can display local images on there just fine. It's best for intranet purposes or local things, but it doesn't mean it won't work online.
An hta file won't work based on what you said your needs are. I mentioned them briefly earlier (http:#19952246) but never pursued them for this reason. It seems like we even discussed Trusted sites and security settings too.
The basics of this are browser security is going to stop you from doing what you want. Clientside script in an Internet page won't be able use that URL. I am not sure what you mean by writing your own protocol handler but that would still need to be allowed/permitted to work. If the security settings can't be changed by the user (or you don't want to depend on it) then you are probably out of luck. Even using an ActiveX object you made would require the user to allow it to run and could be blocked out right (depending if it is signed, etc).
It seemed like you were going over some of the same things we discussed earlier so I hope this helps, even if it is saying you can't do it. Let me know if you have a question about this.
bol
The basics of this are browser security is going to stop you from doing what you want. Clientside script in an Internet page won't be able use that URL. I am not sure what you mean by writing your own protocol handler but that would still need to be allowed/permitted to work. If the security settings can't be changed by the user (or you don't want to depend on it) then you are probably out of luck. Even using an ActiveX object you made would require the user to allow it to run and could be blocked out right (depending if it is signed, etc).
It seemed like you were going over some of the same things we discussed earlier so I hope this helps, even if it is saying you can't do it. Let me know if you have a question about this.
bol
ASKER
Right, we were going over some of what we discussed earlier.
By writing our own protocol handler, I mean registering an <a href="http://msdn2.microsoft.com/en-us/library/aa767916.aspx">asynchronous pluggable protocol</a>. I believe that if we went that route, we could specify the image URL as, say, foo://ourimage.gif and the APP would know to interpret that and return the image data. I don't know for sure that it would work, but I believe it's at least an alternative to consider, given what we have determined so far (i.e. that IE is going to prevent us from doing it normally).
Another option we briefly considered was to "seed" the browser cache with the correct image. We would give the image a bogus URL, say to www.example.com/image.gif, and then insert image.gif into the cache, giving it metadata which tell the browser "don't bother checking for a new copy of this, just display it". I don't know if that would work the way we want, but discussion on this method is welcome as well.
Nathan
By writing our own protocol handler, I mean registering an <a href="http://msdn2.microsoft.com/en-us/library/aa767916.aspx">asynchronous pluggable protocol</a>. I believe that if we went that route, we could specify the image URL as, say, foo://ourimage.gif and the APP would know to interpret that and return the image data. I don't know for sure that it would work, but I believe it's at least an alternative to consider, given what we have determined so far (i.e. that IE is going to prevent us from doing it normally).
Another option we briefly considered was to "seed" the browser cache with the correct image. We would give the image a bogus URL, say to www.example.com/image.gif, and then insert image.gif into the cache, giving it metadata which tell the browser "don't bother checking for a new copy of this, just display it". I don't know if that would work the way we want, but discussion on this method is welcome as well.
Nathan
if you are going to see the html page in browser, move the image.gif to a image folder inside a virtual directory and use
http://localhost/sitename/images/image.gif
<IMG src="http://localhost/sitename/images/image.gif" border=0>
http://localhost/sitename/images/image.gif
<IMG src="http://localhost/sitename/images/image.gif" border=0>
ASKER
This requires a web server to be running on the client computer, doesn't it? I'm sure our users would appreciate us starting a web server on their system when they install our toolbar...
Nathan
Nathan
Nathan,
What is the status of this?
bol
What is the status of this?
bol
ASKER
The status is that I stopped working on that project several months ago. We hacked it up by putting the image at a well-known URL and relying on the browser's caching to keep from overwhelming the server. I don't know if the current maintainer of the project still uses that hack or has found a better way to do it.
That said, if you have a possible solution then I can check the project out of source control and try to make it work. My turnaround time might not be that good since I'd have to figure out what's been done to the code in the past half-year, but whatever.
Nathan
That said, if you have a possible solution then I can check the project out of source control and try to make it work. My turnaround time might not be that good since I'd have to figure out what's been done to the code in the past half-year, but whatever.
Nathan
Nathan,
Not really. Browser security will stop what you want to do. There just aren't really ways around this.
If an install is OK to provide this then you might look at a Browser Helper Object (BHO). You can start by looking at http://msdn.microsoft.com/en-us/library/Bb250436.aspx . From what I have read about them they may allow the type of control and access you want and need. I haven't developed them and have had little exposure to them. Since I helped with this before I have had some exposure and done some research though and think they would be worth your time to at least look at.
Other common IE development "tools" are listed at http://msdn.microsoft.com/en-us/library/aa753587.aspx . I don't think any of those will be more useful but thought you might like the info and list.
Let me know if you have a question. I hope this helps.
bol
Not really. Browser security will stop what you want to do. There just aren't really ways around this.
If an install is OK to provide this then you might look at a Browser Helper Object (BHO). You can start by looking at http://msdn.microsoft.com/en-us/library/Bb250436.aspx . From what I have read about them they may allow the type of control and access you want and need. I haven't developed them and have had little exposure to them. Since I helped with this before I have had some exposure and done some research though and think they would be worth your time to at least look at.
Other common IE development "tools" are listed at http://msdn.microsoft.com/en-us/library/aa753587.aspx . I don't think any of those will be more useful but thought you might like the info and list.
Let me know if you have a question. I hope this helps.
bol
ASKER
Actually, we have written a BHO, but unfortunately they are still subject to the same security restrictions as the page which is currently displayed. I certainly understand why this would be the case, but it's frustrating that there's no real way around it (in Firefox, for example, the image can be stored in chrome and a chrome:// url used to access it).
Thanks,
Nathan
Thanks,
Nathan
Nathan,
Thanks for letting me know about the try with BHOs. I can understand your frustration but am generally glad they do try to keep them secure. I can't think of any other way to do this in IE. Let me know if there is anything else I can do to help.
bol
Thanks for letting me know about the try with BHOs. I can understand your frustration but am generally glad they do try to keep them secure. I can't think of any other way to do this in IE. Let me know if there is anything else I can do to help.
bol
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I do not believe that any of the solutions you provided will actually work. However, you were willing to help me, and it's possible that I'm just not doing it right, so I'll give you the points.
Grading Comments:
I do not believe that any of the solutions you provided will actually work. However, you were willing to help me, and it's possible that I'm just not doing it right, so I'll give you the points.
Thanks but you never need to close or reward just for effort. With your requirements and browser limitations/security I believe you are right the solutions probably won't work. The answer would be you can't, which I did point out above. ;)
I am glad I could help and wish it could've worked out for you. If any of the conditions do change then you pretty much have all the options listed and mentioned here.
bol
I do not believe that any of the solutions you provided will actually work. However, you were willing to help me, and it's possible that I'm just not doing it right, so I'll give you the points.
Thanks but you never need to close or reward just for effort. With your requirements and browser limitations/security I believe you are right the solutions probably won't work. The answer would be you can't, which I did point out above. ;)
I am glad I could help and wish it could've worked out for you. If any of the conditions do change then you pretty much have all the options listed and mentioned here.
bol
have you tried calling the images from a different location, just to make sure that the problem indeed lies with the file:// etc.?