UGC is third-party generated content, and you as our customer are serving as a distributor for it.
For example, the third-party creator is your customer. In this use case, you're using NetStorage to house this content, and you're giving the third-party access to the storage group for upload, and access to it via their end users.
Customer-generated content is content that you as the customer create and own, and you have a one on one relationship with NetStorage for storage and access.
If you wish to implement UGC, you need to understand that various limits apply, versus the traditional customer-generated content use case:
- There is a per-customer limit on the total number of CP codes or NetStorage upload accounts. You cannot establish individual permissions or reporting on a per-user basis, if your end-user total surpasses these limits. Put simply, you're adding more storage group "users" via this use case, and NetStorage has limits on the total number of resources available to accommodate them.
- NetStorage request rate limits are blind to end users—whether they're your requesting end users or those accessing on behalf of the third party. So, these rate limits are not enforced to specifically deny a single end user that is causing an overload. It is up to the application to ensure an end user is appropriately rate-limited to reduce the chance that an innocent end user is denied.
- As the customer, it is your responsibility to ensure that any user-generated content meets our Acceptable Use Policy.
- We do not detect and remove invalid content. As the customer, this is your responsibility.
- You should implement an effective response policy to user complaints.
- You should implement a compute platform to block or flag content, and either:
- Upload directly to the compute platform, or
- Use a NetStorage "holding area" (another directory in the storage group) that is not accessible to the end user, until the content is scanned and transformed by the platform.
If you're implementing this use case, consider these recommendations:
- If your third party-users upload directly to NetStorage, we recommend that you use the NetStorage HTTP API to facilitate this. The individual protocols available for use with NetStorage enforce limits on the number of concurrent connections (while the API does not).
- If you have to pre-process or scan the content, perform either:
- Upload the content to an alternate place that performs this process and the end-user authentication.
- Upload the content to NetStorage using an upload API with a common credential that is not known to the end users requesting access to it.
- If you don't have to pre-process or scan your content, consider:
- For many types of content, the end user requesting it typically must be validated as a subscriber. Run a REST-API that can authenticate end users and authorize them to upload a certain size to a particular path by returning a time-expiring token. You can use an Akamai Delivery Configuration to check the validity of the token before using the NetStorage HTTP API to pass on the upload to NetStorage. You also need to have end users sign an End User License Agreement (EULA) as strict as ours in regard to content uploads. Contact your Account Representative to review our EULA.
- Review the Eventual Consistency Model section to confirm that your workflow doesn't suffer from any of the issues discussed there. This especially applies if your third-party users are allowed to replace an object without a new version name, and they expect to see that change immediately.
- If users are limited to accessing a specific directory, you can get the size of that entire directory tree via one instance of the NetStorage HTTP-API “
- You can also look into the Transcoding solution in Media Services On Demand: Content Preparation or Image Manager for methods to handle applicable content.
Updated about 2 years ago