Deleting a file results in `RequestError::Unauthorized` even though deletion is successful

[duncanjbrown]

When deleting a file using the gem a RequestError::Unauthorized exception is thrown, even though the API client is configured with the correct keys and it's possible to make other API calls. The file appears to be deleted successfully.

On DELETE the API responds with a 302 pointing the client to the original File resource, and it's when following the redirect that the client raises the error.

Steps to reproduce

• Create an Uploadcare API client using valid public and private keys
• Create a new file object using the client.
• Call file.load_data! to confirm that authentication is working
• Call file.delete and see a 401 error

Code to reproduce

file_id = "a-valid-uuid"
file = api.file(file_id)
file.load_data!
begin
  file.delete
rescue Uploadcare::Error::RequestError::Unauthorized => e
  puts "Rescued a 401 on file deletion" # this always happens
  file = api.file(file_id)
  file.load_data! # we can still load it
  puts file.deleted? # will return true
end

[dmitry-mukhin]

Can you reproduce this with cURL by any chance? We need to figure out if it's a lib issue or API's

[rgarner]

Hi @dmitry-mukhin – we added faraday_curl and here's a gist with full cURL output of the four HTTP requests that the above code will generate, along with an abbreviated version for clarity and the original code above for context.

It appears that the Ruby library attempts to use the same signature for the GET that happens as a result of the 302 on DELETE of the file, which fails because the same signature is sent with both requests but the signature has been made for the DELETE verb only. This happens with uploadcare-ruby 1.1.x or 2.0.0.

[dmitry-mukhin]

Ok, the redirect was a bad idea in the first place and will go away in the next API version.

Currently, we can't give you estimates on when the lib will be updated (but it will). However, any PRs are most welcome.

[rastyagaev]

Unable to reproduce with fresh gem version (2.1.2). I've tried both 0.3 and 0.5 API versions. Seems like the bug is fixed, and you can close the issue.