Bug 16141 – Webkit ignores authentication cookie while downloading PDFs through ezproxies

• Status: RESOLVED
• Resolution: INVALID
• Component: PDF

[Alexander Griekspoor]

Bug filed as radar Bug ID# 5612474

Summary: 
Many scientists use an ezproxy setup to browse subscription based scientific journals and download articles in the form of PDFs. While this worked fine on tiger/safari2 it no longer works in leopard/safari3. EZproxies work by forwarding all webtraffic through an address like http://ezproxy.lib.unimelb.edu.au/login?url=%@ where the %@ is replaced by the url of the journal (for instance http://nature.com). The first time a user uses such a url it will have to authenticate. The ezproxy server sets a cookie for the authenticated session and the user can browse the journal pages. When he clicks a link he no longer has to authenticate again because of the cookie. However if he downloads a PDF the system is now broken on Leopard/safari3. NSURLDownload in contrast to the regular webkit browsing doesn't seem to take the cookie into account and instead of downloading the PDF it downloads the html (!) page that asks the user to authenticate again. This affects many users in the scientific field.

Steps to Reproduce:
- use safari 3 to browse to nature.com over an ezproxy: http://ezproxy.lib.unimelb.edu.au/login?url=http://www.nature.com
- mail me ([e-mail]) to get a password/username to authenticate on the page you arrive
- once authenticated browse the journals homepage (this will be fine).
- go to the following page: http://ezproxy.lib.unimelb.edu.au/login?url=http://www.nature.com/nature/journal/v450/n7169/index.html
- if you click on a pdf link the pdf will open fine inside safari
- however, if you go back and right-click the same link and select "Download linked file" Safari will not download the linked PDF file but instead an html file that if you open it will show that it is again the authentication page.

Expected Results:
I expect that the PDF file should be downloaded when you use the download linked file option, the cookie that was set before when you authenticated the first time should still be valid to grant the NSURLDownload of the PDF file.

Actual Results:
What actually happens when you click on the PDF link is that you will get the application/pdf mimetype from webkit, if you then use NSURLDownload to download that file you will actually download the authentication html (!) page.

Regression:
This worked fine on Tiger in combination with Safari 2, it no longer works on leopard with safari 3

Notes:
Please contact me ([e-mail]) to get authentication credentials for the ezproxy system.

Sample code:
A sample project illustrating the problem can be downloaded from: http://mekentosj.com/temporary/ezproxytester.zip
See .m file for instructions

[David Kilzer (:ddkilzer)]

<rdar://problem/5612510>

[Mark Rowe (bdash)]

I strongly suspect that this issue is in the network layer that WebKit uses rather than in WebKit itself.

[Alexander Griekspoor]

Very likely indeed. As a sidenote (will add that to the RADAR report as well). I've rewritten things to use NSURLConnection instead of NSURLDownload and that works, so it's definitely a bug in NSURLDownload.

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> <rdar://problem/5612510>

In the future, please add an "InRadar" keyword to the bug if you've filed your own Radar.  Thanks!

<rdar://problem/5612474>

[Mark Rowe (bdash)]

I'm going to close this as INVALID on the basis that the reporter believes this bug is not in WebKit, and based on the description I agree.