4

I'm working on a website which serves PDF files (generated on the fly) for viewing and downloading by the user. The user needs to save these, sign them (using any 3rd party PDF app), then upload them. For this particular question we are focused on the handing off of the PDF from Chrome on iOS to a 3rd party PDF application.

On an unsecured, public website viewing a PDF from a public link such as this IRS form works fine. You can view it, then press "Open in..." in the bottom right and choose another application. The other application will receive the URL of the PDF and open it fine.

However, on a secured website, the hand-off does not happen correctly. After pressing "Open in..." in the bottom right on the PDF and choosing the 3rd party PDF app, the other app will receive the URL but not the cookies required to maintain session state. Therefore when it downloads the PDF it gets the login page of the website. Different applications handle this different but for instance, Google Drive will save the login page as a corrupt PDF file. Note that this works fine in Safari, the issue is with iOS Chrome.

What I've tried to do instead is to have the Chrome browser on iOS load the PDF as a blob, then create a data url and display the PDF using that:

<a id="myLink">Click here to test PDF data url</a>
<script>
    $('#myLink').click(function() {
        var xhr = new XMLHttpRequest();
        xhr.open('GET', '/f1099msc.pdf');
        xhr.responseType = 'arraybuffer';
        xhr.onload = function(e) {
            if (this.status == 200) {
                var blob = new Blob([this.response], { type: 'application/pdf' });
                var reader = new FileReader();
                reader.onloadend = function() {
                    window.open(reader.result);
                };
                reader.readAsDataURL(blob);
            }
        };
        xhr.send();
        return false;
    });
</script>

This approach works fine and displays the PDF successfully. However, pressing "Open in..." in the bottom right to hand-off the PDF to another app does not work. Pressing it is unresponsive. I assume this is because of the large size of the data url, and that not being supported for hand-off to another app.

Any thoughts? How can I use iOS Chrome's "Open in" feature on iOS with PDF behind secured website or with a large data URL?

Here is an example page that will load a PDF as a data url. It works to display a PDF on Chrome iOS only. Other browsers aren't a fan of this method.

TheSoftwareJedi
  • 34,421
  • 21
  • 109
  • 151
  • How about generating a "one-time use" url for downloading the file that contains all necessary information in the URL itself and does not rely on cookies to be set? Use that url to open the PDF. From a theoretical point of view there not much difference between sending temporary auth details via cookie than appending it to the query parameters, if the connection is secured. – Capricorn Jun 04 '18 at 14:34
  • I was tempted to post that as an answer to my own question - as its the only solution I can think of. I would prefer something that didn't have me designing a temporary URL entry point to the system though. Post it as an answer! – TheSoftwareJedi Jun 04 '18 at 14:47
  • Looks like ChromiumProject is aware of that problem though: https://bugs.chromium.org/p/chromium/issues/detail?id=831678 – Capricorn Jun 04 '18 at 14:53

2 Answers2

4

Source of the issue seems to be the implemented behavior in Chrome for iOS. There's an issue filed at https://bugs.chromium.org/p/chromium/issues/detail?id=831678 addressing the missing cookies.

As an alternative approach one could generate a temporary URL that contains all necessary authentication details and does not rely on cookies to be send along with the request.

Use these temporary URLs to open the PDF in Chrome. Pressing the "Open in..." button passes that temporary URL on to the third party application. For security reasons you should deactivate the temporary URLs based on time or number of calls. One could also implemented restrictions that the temporary URL is only valid for that exact IP address.

Capricorn
  • 2,061
  • 5
  • 24
  • 31
  • Thanks! If you know how to determine a fix date/version from that bug report, that would be awesome. I can't see how that works. – TheSoftwareJedi Jun 04 '18 at 15:08
  • Apparently that issue is marked as fixed, although the the linked issue for refactoring the cookie store is still open (state _started_): https://bugs.chromium.org/p/chromium/issues/detail?id=779106. Also might be that the fix is only iOS11+, as older versions do not have the same API, once it is there. – Capricorn Jun 04 '18 at 15:17
  • TLDR; For now tell your users to use Safari if you have this requirement. – TheSoftwareJedi Jun 04 '18 at 15:24
0

We need someone to look into this as it still isn't fixed. However I may have found a workaround, but it doesn't work for all file types. For PDFs, the error "The file could not be downloaded at this time" can be fixed with iOS Chrome by doing the following:

  1. In iOS Chrome, enter address: chrome://flags/
  2. Find the flag for "Open Downloads in Files.app" and enable it
  3. From now on when you tap a document in a secured site for interaction (Open in...), the share sheet will pop up with option to download the PDF file, not the HTML file as previous. What still bugs me is this doesn't work for .xls or .doc file or other document files (as they don't present the "Open in..." dialog?). My question is how can this be fixed as I've been looking everywhere!!
Nguyễn Trọng Nhân
  • 1