I'm not concerned about users uploading files to someone else's server, but sometimes servers are configured to rewrite certain urls, or to do redirects, and attackers might be able to take advantage of that to rack up some user's bill. For instance, some cache-busting schemes rewrite /d/_somehash_/file or /d/file._somehash_ to the same /d/file and your service has no idea they're actually the same file. In this case, some attacker can just make up random hashes to make false transcode jobs, even though they all return the same video file.
Does your service treat /d/file and /d/file?v=1 as separate files? If so that can also be used as an attack vector as someone can add whatever parameters they want to the url, and most webservers silently ignore those. You can close this by ignoring those parameters, but then you exclude sites that serve files through some script (like /cgi/get-file?f=somefile)
Does your service whitelist file extensions? Or stream in file headers first to decide whether any file is a valid movie, otherwise stopping the download? Otherwise, any site that hosts other large files (say, linux ISOs) can force you to download really large files and waste bandwidth and resources.
With that in mind, I think if you also make it so your clients must also provide a subdirectory (for example, I could set it so only files within /static/videos/ are valid, as that's where I've decided to put my videos) then most of these issues will be taken care of. Your clients would then just need to make sure they don't have rewrite enabled for that subsection of their site, and make sure other large assets live outside that subdirectory.
I am not sure whether the server treats /d/file and /d/file?v=1 as different files or same. Need to check that.
Regarding the mime type, how can I test it without downloading it..? It downloads and then match. If irrelevant then discards. Need to figure out a way to check mime before downloading.
Your /satic/videos/ idea is excellent. This solves a lot of issues. I will take that path along with name, email & host.
And the account will go to "readOnly" state after every update of these critical account details. We need to test manually the path and host before removing the "readOnly" mode. (any other solution?)
Thanks again for delving this much into this. Shoot me an email if you wish to discuss more on this :)