Bug 1658655 - Attachments can't be simply viewed
Summary: Attachments can't be simply viewed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: 5.0
Hardware: Unspecified
OS: Unspecified
unspecified
high with 1 vote
Target Milestone: ---
Assignee: Jeff Fearn 🐞
QA Contact: Utkarsh
URL:
Whiteboard:
: 1658965 1659603 1669734 1673270 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-12 15:51 UTC by Erik Hamera
Modified: 2021-07-31 06:42 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-07-31 06:42:14 UTC
Embargoed:


Attachments (Terms of Use)
test patch (5.09 KB, patch)
2018-12-13 09:52 UTC, Jeff Fearn 🐞
no flags Details | Diff

Description Erik Hamera 2018-12-12 15:51:47 UTC
Description of problem:

Attachment can't be opened in browser window, and must be saved. To add insult to injury it's going to be saved to the default place and not save-as.

That converts one simple middle click to:
- middle click
- wait until the save file window appears
- wait until the [OK] button will be clickable
- click [OK]
- Go to terminal
- ls -ltcr ~/Downloads
- copy the last file by mouse
- vim [middle click]

It's at least 23 mouseclicks+keystrokes which is really annoying. Is that really necessary?

Version-Release number of selected component (if applicable):


How reproducible:

Always.

Steps to Reproduce:
1. open bug https://bugzilla.redhat.com/show_bug.cgi?id=1650348
2. middle click to the 'attachment 1509530 [details]' in comment 2
3. hope it opens in the new tab
4. be disappointed

Actual results:


Expected results:


Additional info:

Comment 1 Jeff Bastian 2018-12-12 16:00:45 UTC
If you click on the Details link for a text/plain attachment, it says:

    The attachment is not viewable in your browser due to security restrictions enabled by your Red Hat Bugzilla administrator.

    In order to view the attachment, you first have to download it.

Is this just a default config setting in BZ5?  Or did we intentionally block viewing text/plain attachments in the browser?

Comment 2 Alasdair Kergon 2018-12-12 16:17:33 UTC
The display feature failed after the upgrade so had to be disabled temporarily until it can be fixed.  It was working on the test server, so hopefully won't take too long to resolve.

Comment 4 Jeff Fearn 🐞 2018-12-12 22:41:42 UTC
agk is correct, there is a configuration issue with the DNS entry for the second cname, which allows in browser viewing of attachments. Currently it should be acting just like BZ4 did. If it's not, then that is a bug.

Aside: The attachment isn't marked as a patch, if you edit the details and mark it as a patch it will allow you to use the shiny new patch viewer. Funny looking diff file so it might be an interesting test case.

https://bugzilla.redhat.com/attachment.cgi?id=1509530&action=edit

Comment 5 Jeff Fearn 🐞 2018-12-13 09:52:55 UTC
Created attachment 1513971 [details]
test patch

Comment 6 Jeff Fearn 🐞 2018-12-13 09:55:28 UTC
*** Bug 1658965 has been marked as a duplicate of this bug. ***

Comment 7 Jiri Denemark 2019-01-23 11:02:54 UTC
Can someone please look at this. Not being able to see plain text attachments
directly in the browser is a very annoying regression.

It works with patches using the ...&action=diff URI, which is nice, but it
is not usable with other plain text attachments.

Comment 8 Jeff Fearn 🐞 2019-01-24 00:51:14 UTC
Hi Jiri, we think this is going to be addressed by Bug 1657579 and then re-enabling the attachment view configuration option, but we can't be sure about that until it hit's partner Bugzilla because it's the only other place we have with the http/https crossover.

Comment 9 Jeff Fearn 🐞 2019-03-14 03:47:27 UTC
*** Bug 1659603 has been marked as a duplicate of this bug. ***

Comment 10 Jeff Fearn 🐞 2019-03-14 03:47:37 UTC
*** Bug 1669734 has been marked as a duplicate of this bug. ***

Comment 11 Jeff Fearn 🐞 2019-03-14 03:47:46 UTC
*** Bug 1673270 has been marked as a duplicate of this bug. ***

Comment 12 Jeff Fearn 🐞 2019-03-14 04:04:18 UTC
I am pretty certain that this issue is caused by "something weird" in the production set-up. I've created a bug on the beta site and added a few attachments to it, if you click on them they work as expected. Feel free to add other types of attachments to it.

https://beta-bugzilla.redhat.com/show_bug.cgi?id=1570736

We thought it was caused by the firewall doing SSL termination, but it doesn't look to be correct as addressing that in Bug 1657579 did not fix it.

It does appear to have changed the behavior though as enabling the feature now triggers and endless redirect when you try and view an attachment. The only two sites this happens on are partner and prod, and as I don't have access to either system I can't ssh in and poke around to see what is going on.

I've added Fernando to the CC in the hopes of him being able to help us triage this on partner-bugzilla. If not then it may be possible to have beta-bugzilla moved to be behind the same firewall/proxy set-up as is being used for partner and prod, so I can do some testing on that.

Comment 13 Fernando Reed 2019-03-14 14:11:33 UTC
Content-disposition is different [1]. In production it really forces downloading as a file. I will check what's causing it (and why it was changed, if that's the case.)

0 [10:04:11][0] βœ“ freed@freed ~ $ http --headers --pretty all https://bugzilla.redhat.com/attachment.cgi?id=1513971
HTTP/1.1 200 OK
Connection: close
Content-Type: text/plain; name="search_include_dependencies_5.0.patch"; charset=
Content-disposition: attachment; filename="search_include_dependencies_5.0.patch"
Content-length: 5215
Date: Thu, 14 Mar 2019 14:04:24 GMT
Server: Apache
Set-Cookie: Bugzilla_login_request_cookie=( redacted ); domain=bugzilla.redhat.com; path=/; HttpOnly; SameSite=Lax
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block

0 [10:04:24][0] βœ“ freed@freed ~ $ http --headers --pretty all https://beta-bugzilla.redhat.com/show_bug.cgi?id=1570736
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 10319
Content-Type: text/html; charset=UTF-8
Date: Thu, 14 Mar 2019 14:04:42 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips mod_perl/2.0.10 Perl/v5.16.3
Set-Cookie: Bugzilla_login_request_cookie=( redacted )); domain=beta-bugzilla.redhat.com; path=/; secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=63072000; includeSubDomains
Vary: Accept-Encoding,User-Agent
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block

0 [10:04:43][0] βœ“ freed@freed ~ $

Comment 14 Fernando Reed 2019-03-14 14:17:40 UTC
Changing config "allow_attachment_display" does the trick of showing inline, just confirmed. Will work on the change management soon.

Comment 15 Daniel BerrangΓ© 2019-08-01 09:12:23 UTC
Its been a long time since the last update, is there a ETA yet for when this is going to be fixed in production ?

Comment 16 Fernando Reed 2019-08-28 20:17:51 UTC
We're discussing internally what's the best approach. (Very) soon there'll be a plan as we have a better staging environment now.

Comment 17 Jeff Fearn 🐞 2020-03-03 00:03:49 UTC
As this does not require a code change in Bugzilla I'm removing the target milestone and assigning it to Fernando. I'm pretty sure this is a configuration issue and not code related, given it works fine on other instances. If it does end up requiring some code changes we can revisit this decision.

Comment 19 Zbigniew JΔ™drzejewski-Szmek 2021-04-14 08:02:16 UTC
I'm not sure if ON_QA means that we should be seeing a change in this bugzilla… FWIW, I don't see any change.

Comment 25 Jeff Fearn 🐞 2021-04-14 22:09:50 UTC
The instance linked to is internal and is not public, this is why the comment containing the link is private. Comments not containing the link don't need to be private ... unless they contain some other sensitive information :)

How your browser displays a mime type is up to your browser and how it's configured to handle them.

If you tell Bugzilla to auto detect what the mime type is, then it uses the Content-Type the browser supplied when uploading the file. If your browser gets that wrong then it's going to cause issues.

e.g. 'mbox' is not a text mime type and won't be treated as plain text in most browsers.

This change will not be deployed to the current production/partner/stage hosts, it's in the MPaaS backlog and will be deployed when we change hosting.

Comment 26 Zdenek Dohnal 2021-04-15 07:18:15 UTC
(In reply to Jeff Fearn 🐞 from comment #25)
> How your browser displays a mime type is up to your browser and how it's
> configured to handle them.
> 
> If you tell Bugzilla to auto detect what the mime type is, then it uses the
> Content-Type the browser supplied when uploading the file. If your browser
> gets that wrong then it's going to cause issues.
> 
> e.g. 'mbox' is not a text mime type and won't be treated as plain text in
> most browsers.

Ok, then IIUC bugzilla enforces 'patch' type (which is some subgroup of text/plain I guess) if 'patch' option is checked.

I got confused that I uploaded the same file twice and only difference was checking/not-checking 'patch' and the behavior was different.

So there can be an issue with my firefox settings, which marks a patch as a 'mbox' mime type...

Comment 27 Jeff Fearn 🐞 2021-07-31 06:42:14 UTC
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.


Note You need to log in before you can comment on or make changes to this bug.