Hello,
As a follow up, as promised, here is what we have implemented and tested
with Amazon S3:
https://github.com/processone/ejabberd-saas-docs/blob/master/http-filetransfer/http-filetransfer.md
I hope you will find some ideas could be valuable for Daniel's proposal.
--
Mickaël Rémond
http://www.process-one.net
On 27 Jul 2015, at 19:03, Mickaël Rémond wrote:
The general workflow is as follow:
1. Sender request an upload URL. XMPP server return an upload URL and
a file ID. This is the step to ensure that the master key is not
shared, as client will only receive a temporary URL, only valid for a
given file (based on its MD5). The requirement for the MD5 could be
discussed of course. At some point we needed it for S3 API upload
delegation.
2. Sender upload the file and can share the file ID.
Download URLs are typically not permanent. A storage backend could
purge them or change them. The main reason of that HTTP upload /
download protocol is to be asynchronous. We do not know when the
receiver will receive the file notification (when back online) so we
needed to cope with possibly changing file URL.
Moreover, with a service like S3, the download URL is not permanent.
Having a file ID allow us to decouple the file from the actual
download URL.
3. The receiver ask the XMPP server and URL based on the file ID.
It has two benefits:
- The XMPP server can use the "master key" to generate a temporary
URL.
- If the server wants to do some XMPP level credentials checks it is
possible (but not mandatory).
- It protect against leaked URL having the file "permanently"
available to any third-party.
I think this should address a few of the concerned expressed here, by
Sam, Rick and Evgeny. We may need to open to more straightforward
cases, where the final download URL is constant, but we are willing to
help.
