It might be useful to have an optional feature to limit the amount of downloads.

Potential benefits include

• Limiting the blast radius of denial of wallet attacks
• Enabling "self-destructing" download links that are valid for one download only, e.g. for sending sensitive information

Thoughts on how to implement that

• Use DynamoDB table item attributes to track current and max downloads counters
• Alternative: Store current and max downloads counters as object metadata on each uploaded file. Would alleviate need for separate database but would add more latency since S3 would effectively act as a database. The biggest downside I see for that option: in order to change object metadata you need to create a copy of that object.

There might be some libraries on npm to make that easy

It might be useful to have an option to specify an expiration date for a download URL, i.e. users would no longer be able to download a file associated with a URL once its date has expired.

Potential benefits

• Users can increase the security of their generated download URLs by issuing short-lived ones, making it harder to guess and exploit them
• Tracking an expiration date could be used with a clean-up routine to automatically delete files whose download URLs have expired (👉 #8)

Thoughts on how to implement that

• Use DynamoDB table item attribute to track expiration date
• Alternative: Store expiration date as object metadata on each uploaded file. Would alleviate need for separate database but would add more latency since S3 would effectively act as a database.

This requires the following information:

• grant_type: refresh_token
• refresh_token
• client_id
• client_secret
• scope: openid
• audience: (same value as the client_id)

Teoretically a user could refresh a token by themselves by performing the following request:

curl -v -d 'grant_type=refresh_token&refresh_token=XXXX&client_id=XXX&client_secret=XXX&scope=openid&audience=XXX' -H 'Content-Type: application/x-www-form-urlencoded' 'https://<cognito_user_pool_url>/oauth2/token'

But since a user won't have access to the client_secret this is something that will need to be done server side and there needs to be an API exposed to the user to do that...

It will be deprecated, replace with new URLSearchParams()

https://nodejs.org/api/url.html#class-urlsearchparams

In backend/serverless.yml we currently define the following parameter:

resources:
  Parameters:
    UserPoolIdParameter:
      Type: AWS::SSM::Parameter::Value<String>
      Default: /weshare/${sls:stage}/userPoolId
    UserPoolClientIdParameter:
      Type: AWS::SSM::Parameter::Value<String>
      Default: /weshare/${sls:stage}/userPoolClientId

These parameters are only populated at the first deployment and are not kept up to date anymore.

If a user redeploys the user pool for any reason, these parameters should change and the backend stack should be able to reference the new values.

This will result in a permanently failed authentication and the inability to upload files.

A possible solution might be to not rely on CloudFormation parameters but use SSM values directly.

A current workaround is to manually update the API Gateway Authorizer for the createShare endpoint and specify there the new values.

The current README does not provide any useful information on how to install the project on a given account.

Also, we need to make the project configurable making sure the user can easily specify their custom domain and avoid potential conflicts with values that need to be unique (e.g. Cognito user pool domain)

Right now it is necessary to have a custom domain which makes the first setup unnecessarily complicated and it makes it hard for people to just try to install weshare.

It might be good to figure out how to use AWS-generated domain names (through API Gateway URLs) by default.

This requires a bit of research and there might be some significant pain points:

• We currently assume there's only 1 base URL and we rely on that to build the other URLs (${base}/auth and ${base}/share). If we cannot rely on a custom domain we would need to either merge the auth and the backend stack to have the same API Gateway or figure out a way to support multiple base URLs. Similarly, the prefixes /auth and /share are currently the result of using custom domain mappings with API Gateway. We would need to either recreate them as actual paths under the API gateways or make the CLI smarter to use these prefixes or not depending on whether a custom domain is being used or not.
• Doing conditional resources in CloudFormation is notoriously painful...

It might be useful to have an option to protect a download URL with a password.

Potential benefits

• Users can more confidently share sensitive information by not only sharing a URL but also requiring a password in order to download the file

Thoughts on how to implement that

• Use DynamoDB table item attribute to store download password
• Alternative: Store download password as object metadata on each uploaded file. Would alleviate need for separate database but would add more latency since S3 would effectively act as a database. Also not sure about potential unwanted security implications of storing passwords that way
• Caveat: This would probably require some kind of web frontend for users to type in the download password

By switching to a POST pre-signed URL for upload we can allow the client to upload an arbitrary stream of bytes. This should help us to make the CLI more generic and make it possible to support the following use cases:

• Upload generic input from stdin (which in turn allows dynamic pipelines like on-the-fly gzip compression or encryption)