View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0012313 | mantisbt | attachments | public | 2010-09-01 09:18 | 2017-09-03 18:41 |
Reporter | Avg00r | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.2 | ||||
Target Version | 2.6.0 | Fixed in Version | 2.6.0 | ||
Summary | 0012313: Can't open image attachments in browser windows | ||||
Description | Actual result: Clicking on attachment link (on page "view.php") rise "save as"-dialog in a browser (IE, Opera, Google Chrome, Firefox). Expected result: Open image in a browser (in new\same window). | ||||
Additional Information | Happened after update from 1.2.1 to 1.2.2. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0011952 | closed | dhx | Arbitrary inline attachment rendering could lead to cross-domain scripting or other browser attacks |
has duplicate | 0013700 | closed | rombert | "Rather than downloading, the attachment is viewed in the browser" doesn't work |
has duplicate | 0014722 | closed | atrol | Stop downloading image attachements |
has duplicate | 0015683 | closed | dregad | image attachment now showing in browser |
has duplicate | 0022543 | closed | vboctor | Open images in the browser rather than download them |
Reminder sent to: dhx is this behaviour now WAD since fix of 0011952 ? |
|
You're right atrol, this change was made intentionally for security reasons. Therefore nothing needs to be fixed. If users click on an attachment name they should be presented with a file download dialog. The old method attempted to guess the MIME type and let the browser try to render it (opening up the possibility for XSS attacks - or worse). Avg00r: I suggest enabling inline image previews as this is a more secure way of showing image attachments in the browser. If we ever want to improve the ability for users to view image attachments inline, this is the feature we'd look to improve. |
|
dhx, I guess it is right to let users to choose between security and usability. |
|
Avg00r, can you provide me fixed file version ? |
|
I want to second Avg00r's request. Since our Mantis is only used internally, we prefer usability. |
|
If you right-click on the image preview and do an open image on a new tab (chrome at least) you get to see the image, because it contains all the security additions on the url. I wonder if clicking on the preview image or on the clicket should link to that instead of to the download link? Is that the exposing the security issue again? In anyway, I second the approach of having that configurable for controlled (intranet) bugtracking |
|
There are changes for 1.2.3 version.
The following changes I've put 1.2.3's version code in the else-block, and a code of 1.2.1 inside if-block. file_download.php. Two changes. First one:
And second:
core/print_api.php. There are also two changes:
If somebody may help me to do diff files against 1.2.3 version, I'll upload this patch. Btw, I've upload whole fixed files. EDIT (dregad): fix markdown |
|
This is a useful addition, as we are using this in a closed environment, and usability is certainly key -- outweighing those security concerns. This works fine on 1.2.6. It would be great if this could be provided as a standard option in the codebase? Is there a way we can fold this in? Or is this a 'wontfix'? |
|
I completely second tcowin, in the company its a wish from most users to have the images displayed in the browser instead of being downloaded. A switch (display attachment secure / convenient) would be very nice. If this is a nofix, I will change my patchfiles to represent this feature on the company servers, but having this patch already in official tree would be so nice. |
|
I also support this, we already have a zillion switches, we can do with one more to improve usability in a closed environment. |
|
I second vtheiding, tcowin,frankyb, ..., our Mantis is only used internally, we prefer usability. $g_inline_file_exts: thanks. |
|
Removed assignment. dhx will not contribute to this issue in near future. |
|
Any news on this? We add a screenshot to almost every bug report (with bug shooting, great tool BTW). Having to download all these screenshots first before you can view them in full screen is nerve wracking! We don't want to hot-fix as proposed by Avg00r to be able to update. Could this change be introduced to the official code? |
|
New configuration options will hardly be added to version 1.2. Until such an option is available: What about dealing with it the way dhx wrote
|
|
our screenshots are normally of websites. In the inline preview they are too small to see comments or markers. But the preview should not be bigger than it is, because with 4-5 screenshots you'd have to scroll forever. |
|
Same for us as for LeapAhead, cas, frankyb, tcowin, ... |
|
This issue also affects the organization I work for, adding a note to ensure notification of change to this issue. Can anyone confirm whether the attached patch works for the timebeing, and that I can roll that patch back if i need to upgrade in the future? Thanks! |
|
please, really allow reverting to old "unsecure" behavior. The security benefit of this PITA seems dubious - the attachment is downloaded and then run anyway, there are just several more unnecessary clicks. some -if not most- teams have a limited set of trusted submitters. Thank you for consideration. |
|
This works just fine in 2.x releases as far as I can tell. See 0022588:0056700 for example. What more do you want ? |
|
upload works fine, thank you. |
|
Sorry if I wasn't clear; I only meant 0022588:0056700 as an example of viewing image attachments inline.
If you click on the inline image, it will open a new tab with it, which I understand is what was initially requested here.
PDF's are indeed not supported currently, but that's not part of this issue's original requirement. AFAIK previewing a PDF's contents requires use of an external library to generate a thumbnail image which I think is beyond this issue's scope. |
|
I am confused by this thread, and by the last example of the image attachment opening in a new tab, as that's not the behavior I'm seeing at all. I've just updated Mantis to the latest version, haven't used it for a couple years. I increased the allowable size to be able to see the image inline which works fine. But I'm still not able to click to see the full-sized image in the browser, but am instead forced to download via download dialog. I AM able to click to see a PDF, though I think that may just be the way I have Chrome configured. I've created a project here: http://qa-testing.dev.wilsonrms.com/view.php?id=700 to illustrate the issue. It's view status is public, but I'm not sure if that's enough to provide access without a login, as I've never shared anything outside my team. As others have said, this is really like hitting a wall in the bug review process. If the image is a full-window grab w/markup, the inline preview is way too small to be useful. The opening-in-another-tab thing is fine, but how was that accomplished? |
|
Anyone? Anyone? How-to? Little help? |
|
[quote]AFAIK previewing a PDF's contents requires use of an external library to generate a thumbnail image [/quote] Generating a thumbnail image is not necesary. All modern browsers have a pdf reader built in. Maybe this is a case of misunderstanding? The same goes for images. Problem is just that browser is downloading files instead of viewing them. Maybe it's a mime-type setting? |
|
It's not really a matter of the browser being capable of reading any particular format. In my case, I view PDFs with a plugin that allows me additional options, which in this case is working fine/as predicted. PDFs aren't the issue. Any browser—modern or not—should render a jpg. But instead, clicking on the image results in either an automatic download to disk, or a dialog offering one. If a user has uploaded a jpg, there's just no reason why I shouldn't be able to open that directly in the browser vs. littering my desktop with yet another file that I simply need to see, not download. It's the php that's forcing this: ...And the PHP is written into the web app code, obviously, so it seems like Mantis devs could implement the file attachment differently, or at least allow an option for users who are not concerned about any potential security issues. I added a 'guest' user to my Mantis for reference: http://qa-testing.dev.wilsonrms.com/view.php?id=700 Very much appreciate any input/suggestions. This is really a sticking point from me as I gear up to put MantisBT back in use. Thanks! |
|
So I applied the changes are described above by Avg00r, despite that entry being 3 years old, and since I don't seem to be getting anywhere with my query here on this thread. This resulted in no change that I can perceive. I had hopped the tweaks would contravene the .php, but no such luck. Can anyone add anything of value to this conversation? Thanks in advance, |
|
Found it! there is a problem in file_download.php I think it is asumed, that $t_content_type should always have a ';' present, that's maybe wrong. i'm not good enough programmer to submit a patch, what can i do? |
|
ok sumbited pull request https://github.com/mantisbt/mantisbt/pull/1125 |
|
It seems that @vboctor thought there is always a |
|
As per RFC , the parameter bit is optional, so @rattkin is right, the code in download.php is incorrect. |
|
MantisBT: master 54929f3b 2017-08-02 04:18 Details Diff |
Fix inline viewing of image attachments The code extracting the MIME type from the content was incorrect, assuming that a semi-colon would always be present but it's not always the case. This resulted in MIME type being empty, which in turn made the browser download the file instead of displaying the image inline when the web server's content disposition header is set to "attachment". Jan Müller's original patch [1] was replaced by more efficient code. Fixes 0012313 [1] https://github.com/mantisbt/mantisbt/pull/1125 |
Affected Issues 0012313 |
|
mod - file_download.php | Diff File |