Add method for generating signed Smart CDN URLs

[Acconut]

We recently added support for signed Smart CDN URLs (see https://transloadit.com/docs/topics/signature-authentication/#smart-cdn) and would like our SDKs to offer methods for generating these signed URLs.

This PR adds such a method, alongside documentation and tests.

[Acconut]

@mifi @remcohaszing Thank you for the thorough reviews! I think I incorporated all of your feedback. In particular, the urlParams type has been narrowed down and it now also allows duplicate values via array. Could you have another look at it?

[kvz]

As i'm implementing implementations for other languages, I find I want to compare signed URLs to see if the implementations are the same.

For this reason, and I guess, also unit testing etc, it's nice if you can pass in an expiresAtMs instead of only a relative expiresInMs. We could accept both for convenience. Or just support the absolute one.

For my testing I ended up with:

  let expireAt = Date.now() + 1 * 60 * 60 * 1000 // 1 hour
  if (opts.signProps.expireAtMs) {
    expireAt = opts.signProps.expireAtMs
  } else if (opts.signProps.expireInMs) {
    expireAt = Date.now() + opts.signProps.expireInMs
  }

WDYT?

[Acconut]

For testing I simulate a faked time, so the expiration time is always fixed: https://github.com/transloadit/node-sdk/pull/201/files#diff-e22f393adc69cfde9a0b1a6d6d6e33aafe4afeb3ca83061ce296462c99d6b845R350 This works well and is also possible with minor adjustments in the Go, Python and Java SDK. I suspect it to also be possible in PHP and Ruby.

I find that this is a better approach than adding another parameter that will just be used for testing. I expect that customer prefer setting the relative expiration duration instead of an absolute expiration timestamp, since that is the value you care about when signing things.

[remcohaszing]

I lean towards expiresAtMs over expiresInMs, but it’s a slight preference. I do think it’s best to provide one option. Providing multiple options is confusing. The user may mix them up or specify both at the same time.

Perhaps the best option is expiresAt where it accepts a Date object.

[kvz]

If we want to support only one param, I agree it should be expiresAt.

its possible to tamper with clocks in tests in at least a subset of languages and testing frameworks, but not always and not always trivial.

People may also want to debug their integration outside of testing frameworks.

And for instance in my case I simply wanted to compare the signature between this reference implementation and Ruby & PHP I’m writing.

Found all kinds of subtle differences thank to this being controllable.

[Acconut]

Should we move all SDK PRs to use expiresAt then? As far as I know this is the only point of discussion that we need to settle before we can merge these PRs.

[kvz]

I agree one way is better than two, and I think passing in something absolute has its benefits. So yes, let's change it throughout.

I took care of PHP, Ruby, Python just now. I also added Node.js parity testing to the Python SDK, just in your PR Marius, so you might want to take a look and see if you agree.

[Acconut]

@kvz I updated the PR to only use expiresAt. Does it look good to you now?

[kvz]

It does!