Client approval
A draft design or proposal should remain available for review only until the end of the review process. Apply appropriate access control (expiry date/time) and remove the link from public view once the review process is complete.
Different types of files will have different requirements for behavior. A file uploaded to a public website may require an open URL, whereas a client document may require a password, expiration date, or a link that can be deactivated once the review process is complete.
Media2URL saves your settings for each file you host. With Media2URL you can decide who will have access to your file, how long that person's access will last, what that person can do once they get to your file and, when available, how you can authorize direct delivery of your file.
When you give someone a file, do you want to provide just the URL? Do you want to require them to enter a password? Or, do you want the link to expire after a certain amount of time? If you can determine these three things, it will be easier for you to select your access settings.
In areas where these options exist you may select either Public, Unlisted, Private or Password Protected. When using the Unlisted option, the user must know the URL in order to access the area; however, when using the Private option the area can be accessed based on the permissions granted within the workspace.
Select a termination date that will discontinue access to the asset at the end of the specified timeframe. Your ability to control how long users have access to the asset is dependent upon the type of asset and your subscription level.
The user will be able to select from the preview options that are currently active in addition to selecting how they would like the file delivered. The user may choose to have their share page mask the file name/details, disable the ability to download the file, and/or view the file via preview only if applicable.
Direct file request option allows users to create a signed URL that will be valid for a specific period of time (instead of creating a permanent raw address), as long as the direct file request has been configured with signed delivery. Users have the ability to revoke a file's direct link, or update the signing key used to generate the file's direct links if they want previously generated signed URLs to cease being valid.
| Layer | What it controls | Media2URL examples |
|---|---|---|
| Delivery | Whether a direct delivery request is authorised | Signed URLs, TTL, signing key rotation, transformation controls |
| Access | Who should be able to open the file | Public, Unlisted, Private, protected by a password |
| Lifecycle | How long access remains or how downloads are limited | Expiry, access for one view, maximum downloads, disable link |
| Interface | What someone sees or can do on the share page | Preview without download, hide filename/details, download button control, delivery mode |
Although these controls may be able to function as a unit, each one is unique and therefore cannot replace another. For example, the use of a password will provide a response to a different inquiry than that provided by an expiration date. Additionally, preventing users from downloading files is a completely separate control mechanism than restricting access to the file.
A smaller configuration of components which meets the actual requirements of the sharing scenario will typically be the most beneficial.
As long as the original route is still available, the standard URL will remain operational. The signed delivery is a second check that Media2URL performs prior to serving the files it supports.
If signed delivery is activated, Media2URL will generate a delivery URL with a cryptographic signature and an expiration date. The server may then use this signature to confirm that the URL was generated by Media2URL using the appropriate signing key, rather than being modified to create a new valid request.
Signing and encrypting addresses help to provide solutions for different types of problems. When a signature is used, it allows Media2URL to verify that the request to deliver was generated with the correct signing secret and that the request has not expired. Protection is provided by verifying the signature and checking if the request has expired, as opposed to protecting the address by hiding it.
The signed delivery TTL regulates the duration of use for each issued signed URL up to the maximum allowable limit. A shorter duration decreases the amount of time that a previously issued signed URL can be utilized when transferred to another location; however, the shortest possible duration may not provide the most desirable user experience.
Media2URL allows you to change the signed delivery key used for each file. Once changed, any URLs previously issued with the older signed delivery key will become invalid, but the actual media asset remains safely stored.
Because a single original image may be used for various types of layout, it is beneficial to allow users to dynamically resize images. However, when there are no limits placed on how many transformations can be applied to an image, there is the potential to create many unnecessary versions of that same image.
Media2URL provides options for allowing images to be transformed and sets limits on the maximum size of each image transformation requested. Limiting the width and height of an asset creates boundaries for that asset rather than allowing for limitless dimensions.
The large size of a stored image is a result of preserving the original image. Therefore, a user does not need to obtain permission for each and every transformation request to create a new version of the image in the desired size.
The limits on how large you want your images to be (Maximum Transformation Width and Maximum Transformation Height) provide additional constraints on what you are delivering to the customer. If you only require standard size images for your website, then you can set these limits significantly smaller than the actual dimensions of the source image.
| Access mode | What it means |
|---|---|
| Public | The configured link can be opened normally by someone who has the URL |
| Unlisted | The URL is meant to be shared directly and is not the same as workspace authorised private access |
| Private | Access follows the private or workspace authorisation rules available for the file |
| Protected by a password | The recipient must pass the configured password check where that access mode applies |
The term "unlisted" should never be used interchangeably with "private". Although a person receives a link (URL) that is "unlisted", they can still share this link with others.
When the person receiving the email is going to have to do more than just guess at your email address, use either "Private" or "Password-protected." Your Team Workspaces allow you to manage the roles and permissions of your team members.
Shared files do not all have to stay available forever. Media2URL has features that provide for the closing of access to files once they are viewed by users and/or limiting how many times a user can download the file. These features are different than providing a "expiration date," which closes access to files based upon a specified time frame.
The controls which will be at your disposal are based upon your plan, as well as upon how you set up your link. Prior to sending out a file for which you would like to have restricted access, please check out the options presented in your dashboard because downloading limits and single view limitations do not function in the exact same manner. Additionally, none of the above-mentioned controls will enable a person who has previously viewed or downloaded the file to unview/delete the file that was available to them during the time period in which they had access.
The usefulness of a shared URL can expire prior to its expiration date. This could be due to several reasons including that the asset was accidentally shared with the incorrect audience; the customer's review process has ended; or a newer version has replaced the previous one.
By disabling the link you will be able to prevent the public delivery of that link without having to delete the asset from your library. Therefore, the decision to disable a link is independent of the decision to delete files.
| Situation | Controls worth considering |
|---|---|
| Client draft for one week | Password or Private access + expiry |
| Single use handoff | A setting that closes access after one view |
| Download with a fixed allowance | Maximum downloads + appropriate access mode |
| Application delivered private media | Signed delivery + suitable TTL |
| Signed URL copied somewhere unexpected | Rotate the signing key or disable the link |
| Public image with dynamic resizing | Transformation limits and maximum output dimensions |
| Preview without normal download UI | Preview without download plus download button control |
The above examples represent only some possible combinations, not all of those required. You should select from the list of controls provided only those which will help resolve the issues you are currently experiencing.
A draft design or proposal should remain available for review only until the end of the review process. Apply appropriate access control (expiry date/time) and remove the link from public view once the review process is complete.
Workspace member documents are not designed to automatically share with the same level of access as a public brochure. Private access allows you to differentiate your dashboard workflow from standard public sharing practices.
When you require an immediate response with your media content from your website/application, but you don't want to provide users with a permanent delivery URL that has an indefinite life-span, then you could enable the signed delivery feature. This feature will create a signature and time constraint around the media delivery request.
Public image may still require a delivery limit, regardless of whether the original image was intended to be visible. Limits on transformation size assist with keeping dynamic sizing within what the site needs.
When a file will be used publicly, it makes sense to make a public link. If you added password protection and/or an expiration date on every single file, you would just be creating extra steps for users. Similarly, if a file contains confidential client information, you do not want to leave it accessible to everyone via a public link just because you want to send someone a direct URL. Begin with what the user needs to accomplish with the file, and then select the appropriate level of access control, life-cycle control, and delivery method controls that enable them to complete their work while limiting as much as possible the amount of access they have to other files.
The term "unlisted" refers to an option where access to a resource can depend upon the availability of a specific URL. This is different from the type of access that would require authorization from a private workspace. If a person shares an active unlisted link with another individual, then that individual might be able to utilize the resource provided that the rest of the access requirements for the resource continue to exist.
Where possible based on the file and plan, you may hide/disable the default download behavior or provide a way for users to view the file without downloading it. Additionally, you may implement a maximum download control which restricts the total amount of times a user may download the file. While hiding a download button is one way to prevent users from downloading files, it does not provide an absolute guarantee that users cannot take screenshots or record the screen to save what they see.
The link may be turned off by accessing the control panel for each asset, if this is an option within your asset control panel. This will turn off the link while leaving the original library file intact.
The way in which passwords behave will be determined by how the asset was accessed or delivered. Do not assume that the password shown on the sharing page accurately represents all possible ways to access the asset via direct delivery URLs. Rather, you should look at the current controls applied to the files. Signed delivery is an additional control mechanism for authorizing supported direct requests.
A signed URL will include details that Media2URL can check for validity prior to delivering the applicable file. The signature is generated via the configured signing method and may also incorporate a time-limit. At this time, Media2URL utilizes HMAC-based signing as part of its signed delivery process. HMAC is a keyed message authentication mechanism, not a URL encryption technique.
Media2URL increases the number of versions of the signing process used on the asset. After increasing this number, any previous signed URLs that were generated with a prior version of the signing process may be made invalid, and new URLs may be generated using the latest version of the signing process. As a result, you will have the ability to invalidate old delivery URLs without having to replace the actual file.
For all of the supported links on Media2URL there are controls available to limit access after the initial viewing. However, these controls have different functions than an expiration date, as the expiration date will end the ability to view the content at the end of the specified time frame.
The ability to transform a single source image into several alternative representations is provided by dynamic transformation. Transformations may result in excessive processing, and possibly additional derived resources, due to uncontrolled parameter variations, without well-defined boundaries. Media2URL provides the option to enable/disable transformations, as well as the ability to define a maximum dimension for requested transformations to help limit uncontrolled generation of derived resources.
Next steps
For a deeper explanation of restricted file access.
For links available for a limited time.
For workspace roles and member permissions.
For managing the stored asset separately from its link state.