Redirect response on file download request
dschreij opened this issue · 6 comments
The Waterbutler API appears to have recently started sending redirect responses to file download requests. If we try to download a file in OpenSesame, which uses the QOpenScienceFramework library, we receive a response like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="https://accounts.osf.io/login?service=https://osf.io/download/y2rmh/">https://accounts.osf.io/login?service=https://osf.io/download/y2rmh/</a>. If not click the link.
</DOCTYPE>
...
The QOpenScienceFramework library uses the download link provided by the data > links > download attribute of a file node (which for example looks like https://osf.io/download/570f7496594d9001e668da0c/), and is able to handle HTTP 301 and 302 redirect requests, which to my knowledge is the conventional way of redirecting. My hunch is that Waterbutler performs this redirect in a less conventional manner. I haven't been able to check this, but perhaps Waterbutler issues a normal HTTP 200 response to show the "You are being redirected" page, and then redirects to the download with a meta tag or javascript?
This error is also discussed at open-cogsci/QOpenScienceFramework#13
Some new info:
I have checked the request/response process and found the following:
GET https://osf.io/download/y2rmh/
RESPONSE 302
Redirecting to https://accounts.osf.io/login?service=https://osf.io/download/y2rmh/
GET https://accounts.osf.io/login?service=https://osf.io/download/y2rmh/
RESPONSE 200
So, GET https://osf.io/download/y2rmh indeed results in a 302 REDIRECT response, which is correctly caught and handled by our application. It then does go to the redirect URL: GET https://accounts.osf.io/login?service=https://osf.io/download/y2rmh/ and receives a 200 OK response. This final response should contain the file data, but this isn't the case: I receive the contents as described in the issue above. If I open the same link in a browser, I do get the file. I can't really put my finger on what's going on here, but I still suspect the actual redirect is performed by the browser through some script or a <meta http-equiv="refresh" content="0; url=http://example.com/" />. If this is the case, it is not a really API-friendly way of redirecting as this should be browser-independent.
Hey @dschreij,
That file is private, meaning you need to provide credentials to download them. I think either http basic auth or a personal access token should let you grab it.
Cheers,
Fitz
Hi @felliott, Thanks for the reply.
I know the file is private, but it belongs to my account. I am logged into the system and possess a valid API token, or at least, the QOSF module successfully pulls all other (private) information from the server, so it's only the file download where this problem occurs.
As an extra test I have also tried to upload and delete a file or folder, and I can do that without problems, it is only the downloading that doesn't work.
Hey @dschreij,
Apologies, I skimmed your example and thought that was a curl command. I'm not sure what's going on here. It looks like the OSF auth is failing so it's sending a login link instead of the link to waterbutler. I'll poke the OSF devs and see if we changed anything with our auth recently that might have broken this.
It turns out the issue has already been reported, and there's a ticket to fix it here: CenterForOpenScience/osf.io#8239 Since this doesn't involve WB directly, I'm going to close this issue, but I'll link this PR over on the QOSF issue.