01295: Attachments in IE7-IE8 over HTTPS without direct download
Description: I am using IE 7 (as enforced by my company). When I attach non-image files (pdf, doc etc...) and use Attach:file_name.ext Δ it works fine, until I log in. Some of my pages are restricted to an edit password. If I edit one of these pages, enter the edit password and log in, for the entire duration that 'logout' is displayed none of the attach links work. PDF files just hang and doc files prompt an odd save as/open download dialog and fail no matter what is clicked. As soon as I click logout, all attach links work fine again. Other users of my system running epiphany, chrome or firefox on unix machines dont have this issue but I am restricted to running IE7 on a windows machine.
I am unable to provide an example as I cannot create a page in test that needs to be logged into and my system is running on an internal local network (intranet). I will be happy to provide my config files or other things that may be helpful.
You say "epiphany, chrome or firefox on unix machines dont have this issue", but just to confirm, when they are logged in, their attach links don't break, is that correct? Can you attach/embed an image into the page and check if it works while logged-in? Can you post here the source HTML output of a sample page with some different attach links and embedded images? Do you have some Cookbook recipes enabled? Is $EnableDirectDownload set in (farm)config.php? Can you post the contents of the file config.php? (Remove any passwords or private stuff). --Petko September 12, 2012, at 02:56 PM
Yes. When logged in using epiphany, chrome or firefox on unix machines the attach links work fine. It is only an IE issue.
Embedding or attaching images works fine while logged in.
We have no cookbooks enabled.
$EnableDirectDownload is set to 0 in farmconfig.php.
Thanks, but I don't see anything that should be obviously problematic. I have now set $EnableDirectDownload to 0 for this page, can you test if you can download the files in IE7 here? You can attach a PDF, a DOC or a PNG file here for the test. --Petko September 12, 2012, at 05:28 PM
I can attach a doc here and it works fine, because I can't log in.
I'll also ask you to test your site with this setting in config.php:
$EnableIMSCaching = 1;
--Petko September 12, 2012, at 05:36 PM
Tried with no luck unfortunately.
There is one more thing you can try. Set in config.php, after the line with "$Author", the following line:
if($action=='download') header("Pragma: ");
This may come from a specific way for IE to work over HTTPS. [1] [2] --Petko
Same again, no luck. Thanks for the help though.
One last thing, when I try to open the PDF document either nothing happens or if I open in new tab it opens a blank page. However when I try to open the doc, this download dialog appears. Note the strange string in name. This usually just displays 'test.doc.'
When open is clicked a blank page is opened, when save is clicked this popup appears.
Try this page and report, please. The password is quick. --Petko September 13, 2012, at 09:11 AM
Everything on that page works just fine while logged in. I guess that means it is not really a bug but something wrong with my configuration. Although what I have no idea.
I have a problem to get the PDF file on the test page with IE8, and I've also had problems with files over HTTPS, so this bug is confirmed. I'll investigate it. Can you post details of the file '/home/www/htdocs/php/dev/auth.php'? I'd like to know any line which would be using the header(...) function. In the meantime you may want to enable direct downloads (set $EnableDirectDownload to 1). --Petko September 13, 2012, at 01:08 PM
Setting $EnableDirectDownload to 1 causes all attach links to redirect to a page that says 'Access Forbidden!'. I believe because we have an .htaccess file in the Uploads folder.
Yes, if you require protected uploads, and have placed a .htaccess file in the uploads directory, not much can be done. --Petko
Note, MSIE9 doesn't seem to have any of these problems on my installations, but on protected pages trying to get the *.doc file it opens another user:password dialog box. --Petko
Sorry for the delay but I can confirm that this problem does not occur in IE9. Unfortunately my company currently restricts browser usage to IE7 only.
I also have the bug when using 'Open' as opposed to 'Save' on *.doc files that causes a bogus authentication to display (it can be ignored using 'Cancel' with no effect), however I don't believe that is pmwiki related because the same problem occurs on the CVSWEB installation of my CVS repository. I think that one can be put down as an IE bug because it does not occur using other browsers and is intrinsic to the download dialog and not our software. I have some detailed example HTTP headers if you are interested.