Hide Forgot
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:
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?
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.
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
Created attachment 1513971 [details] test patch
*** Bug 1658965 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 1659603 has been marked as a duplicate of this bug. ***
*** Bug 1669734 has been marked as a duplicate of this bug. ***
*** Bug 1673270 has been marked as a duplicate of this bug. ***
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.
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 ~ $
Changing config "allow_attachment_display" does the trick of showing inline, just confirmed. Will work on the change management soon.
Its been a long time since the last update, is there a ETA yet for when this is going to be fixed in production ?
We're discussing internally what's the best approach. (Very) soon there'll be a plan as we have a better staging environment now.
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.