Ticket #853 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

Client upload to storage without having primary storage keys

Reported by: wwaites Owned by: wwaites
Priority: critical Milestone: ckan-v1.3-sprint-1
Component: dpm Keywords:
Cc: Repository:
Theme:

Description (last modified by rgrp) (diff)

Reverse engineer boto and work out how to get headers to support upload to google storage without holding api keys.

This would lead to an extension to OFS.

This analysis should inform (and go hand-in-hand) with the implementation of ticket:879 (Storage Auth API in CKAN).

Change History

comment:1 Changed 3 years ago by wwaites

  • Status changed from new to closed
  • Resolution set to fixed
  • Description modified (diff)

done in http://bitbucket.org/ww/ofs need to merge back into main ofs repo

comment:2 Changed 3 years ago by pudo

  • Status changed from closed to reopened
  • Resolution fixed deleted

Looking at the changeset this cannot be functional yet: where is the implementation of the policy document exchange. It seems to me like this is currently adding the actual credentials to the request (self.ofs.conn.add_aws_auth_header(headers, 'PUT', path)).

c.f.:

comment:3 Changed 3 years ago by rgrp

  • Priority changed from awaiting triage to critical
  • Type changed from defect to enhancement
  • Description modified (diff)
  • Summary changed from plumbing for rest upload to Understand how to upload to storage without having primary storage keys

comment:4 Changed 3 years ago by rgrp

  • Summary changed from Understand how to upload to storage without having primary storage keys to Client upload to storage without having primary storage keys

comment:5 Changed 3 years ago by wwaites

  • Status changed from reopened to closed
  • Resolution set to fixed

we don't need a policy document exchange. it's simpler than that. the "server" instance has already permissions to upload. it just calculates the headers and such that are needed (based on the "client"'s initial headers) and gives them to the "client" the client then uploads without knowing the "server"'s credentials. The "client" never needs any of its own goostor credentials at all.

the only separate step is to make the widget readable by the world.

ticket #879 is to expose this as a small set of API calls.

Note: See TracTickets for help on using tickets.