Viewing uploaded files fails, or requires logging in again

[zingmars]

Right now if I share a file (i.e. a document) and click on the link that's sent in the Android app it will open a webview asking me to log into the Zulip instance. This is pretty annoying to be honest as the expected behaviour here would be to offer me to download the file instead.

[weastel]

@zulipbot claim

[borisyankov]

I consider the original issue to be a bug report not a feature request

For documents (for example PDFs) that are not hosted on a zulip server, we do open the document in a Chrome Custom Tab / Safari View. This screen immediately displays the document. In addition, a menu would allow downloading the document.

This matches the behavior of several chat apps that I tested, including Slack (also several non-chat apps!)

So, we need to fix the auth issue, not add a direct download functionality, which already exists in the screen that shows the document.

[gnprice]

Thanks @borisyankov for the investigation! I agree with your conclusions.

Folding #3487 into this as a dupe -- you've determined it's the same underlying issue, with a difference in symptoms by platform:

• on Android - after opening fails we go back to the message list
• on iOS - we get a login screen

[gnprice]

you've determined it's the same underlying issue, with a difference in symptoms by platform:

• on Android - after opening fails we go back to the message list
• on iOS - we get a login screen

Hmm actually this doesn't quite fit the data -- the original report here on this thread was on Android, and described a login screen.

I still think these are the same issue so I'll dedupe them; we'll just keep in mind that we have a somewhat confusing set of reports.

[gnprice]

Current state:

• We believe all the reported symptoms are ultimately caused by trying to open an auth-requiring URL and not providing auth; similar to the cause of lightbox: Download manager fails to download from {image_url}. #3124 .

  • Background: normal auth in the mobile app is by including an Authorization header, i.e. by HTTP basic auth. We do this for all API requests made directly by our own code, but it's trickier when other libraries are making HTTP requests. Some we successfully teach to send that header; for others, we resort to sticking the user's API key in the query-part of the URL.

• Reported symptoms include:

  • on Android, a login screen (in the OP on this thread);
  • on Android, a "Cannot display PDF" toast (on Uploaded PDF can't be viewed #3487 -- my repro, and a similar report from a user)
  • on Android, it all working! (on Uploaded PDF can't be viewed #3487, report from a user; details unknown)
  • using chat.zulip.org (from Android), it all works fine (my repro, on Uploaded PDF can't be viewed #3487)
  • on iOS, a login screen (Boris comment on Uploaded PDF can't be viewed #3487)

• Possible related issues:

  • The setup is reminiscent of iOS: blank screen when opening a PDF file #2308, but the symptom is different. That one was reported on iOS. That symptom: a blank browser screen... but if the "Safari" icon there is followed, then it opens successfully.
  • Error: Download manager failed to download from (a user_uploads URL) #2115: download manager fails to download, causing exception.
  • again, lightbox: Download manager fails to download from {image_url}. #3124