First, I would like to state I'm posting this to the Support Issues and Questions and not to a particular language because this thread should focus more on "designing the application" and not actually writing language-specific code. With that said, please share how you are handling uploading, converting (transcoding), and extracting images for your application. For example, are you uploading, converting, and extracting in one HTTP request or are you using the callback urls to complete the operations.

 Also, are you uploading to your server and then uploading to Nirvanix or are you uploading directly to Nirvanix. If you are uploading directly to Nirvanix how are you doing it without showing Upload Key and other valuable information either in the URL or hidden in the HTML code (which is visible by the client's browser by right-clicking and viewing the source).

 
Thanks,

Brian
 

 The Upload token while it should be protected can be restricted to a single IP Address and only allow uploads to a specific directory.  The token can also be set to a specific timeout which would let you restrict access to upload even further.  You can read more about these parameters in the API Document under GetStorageNodeExtended.

Regards,
    Barry R.

Barry,

again one of my (silly) doubts. You mentioned that the "Upload token" should be protected. May I ask why?

What can somebody do with an "upload" token except uploading?

I must say I had missed the GetStorageNodeExtended method, thanks for mentioning it. The destFolderPath is indeed quite a security as I can make sure nobody starts uploading outside my staging area...

 thanks

 
ciao Luca
 

 The primary reason for protecting the upload token is to keep users from abusing your bottom line.   You wouldn't want to pay for upload bandwidth that was not part of your system.  Also if the token is allowed to overwrite it could be used to change existing files (again another reason to use the destFolderPath)

Regards,
    Barry R.

 Barry,

 I guess I have to upload it to my app server and then upload it to Nirvanix if I don't want to put my upload token in plain sight.
 

Hi, I am about 80% complete on a complete video sharing system that uses the CDN and here are a few points I considered when I designed the system.

 

UPLOADING 

The upload was the first thing I thought about...uploading to your server before the CDN is not ideal because the purpose of the CDN (in my case) was to take the load off our servers. So the ideal thing is to get a session token from the CDN and use that to get node data for uploading to. But, as discussed this exposes the upload token to the user.

One way around this is to have a tiny SWF file that handles all tokens. The SWF is compiled, plus the token info is generated at runtime inside the SWF. Instead of passing data to the SWF when it loads, which would expose that data, you would have a load event which requests the data from your app server (i.e login info) which can then be transmitted to the SWF via SSL.

This does kind of utilize the "sledgehammer to open a walnut" situation, but would ensure that the data is safe.

Any server-side file that needs a token can request it from the SWF, which can pass it back as an RSA encrypted string, with the public key on the app server to decrypt the string.

The SWF has no visual interface so acts more like a remote class.

CONVERTING 

Our code is for a media manager, not just video sharing, so we have various folders for different types of media. To further enhance usability we use a flash/ajax/php combination to produce an upload component that can upload multiple files of different type in a queued system.

 > User selects 20 files of various mime type and clicks Upload Button
 > File is uploaded to the correct node into a temp folder
 > Once all files are uploaded, a script runs on the temp folder moving the files to the correct location
 > Any video files not in FLV format are placed in an xml file which is then called later
 > XML file is called via a cron script which processes the conversion using a callback to remove the files after done processing
 > Original file is then deleted from temp folder

A list is included in the interface to show the user the current state of transcoding for the files so they understand if a file is not ready for sharing.

EXTRACTING

Haha! This is where I have been having trouble....sometimes it works, sometimes not.

In our situation, a file is simply that. To share that file a user must create a media object whose data is stored on the app server side. We do this because we allow the users to create playlists of objects that can later be passed to our players.

For the thumbnailing of FLV files I created a small mini-player with a scrubber bar allowing them to seek to any frame in an FLV and capture that frame.

This is what I am still on because it doesn't always work. I just tried to capture a frame and I got a response code 70002, file not found. I then entered into a browser that same url that it said was not found and viola, there it is. I'm about to post a message about this because extracting thumbs has worked for me on some occasions and not on others so it really is holding up my development.

 ---

I hope the above ideas help you out in your final design.

Paul
 

"One way around this is to have a tiny SWF file that handles all tokens. The SWF is compiled, plus the token info is generated at runtime inside the SWF. Instead of passing data to the SWF when it loads, which would expose that data, you would have a load event which requests the data from your app server (i.e login info) which can then be transmitted to the SWF via SSL.

This does kind of utilize the "sledgehammer to open a walnut" situation, but would ensure that the data is safe.

Any server-side file that needs a token can request it from the SWF, which can pass it back as an RSA encrypted string, with the public key on the app server to decrypt the string.

The SWF has no visual interface so acts more like a remote class."

That is very slick!!
I still wonder if someone catches on to the fact that there is a SWF file and decompiles it. Are you saying that you store your Nirvanix login information in the SWF or your some how call it from your server. I guess that doesn't really matter if I am reading what you said correctly. This is cool, I never thought of doing that. Sure I thought about using a SWF to upload but then thought about the risk of decompiling and got scared.

I haven't read the rest of your post yet but that is really interesting.
 

I thought about the cron idea as well but I don't know if it will work on App Engine. I guess I should check that out.

Nothing is stored inside the SWF apart from a public key to decrypt the RSA strings.

The login data is requested at run time, and when passed would be RSA encrypted and also send over an SSL. So we really are talking about security at every level.

The login can be performed from the SWF, or the login performed by the app server and the SWF requests a sessionToken to talk to the CDN.

Either way any confidential data is only used when needed, only stored on the app server and is always encrypted using multiple methods during transmission to/from the SWF.

Using multiple technologies to solve the problem lessens the chances of the data becoming useful to anyone.

Also the encryption method can be changed. I use RSA because we wrote a very nice RSA class to handle data, but you could use SHA1 or MD5.

 

Paul. 

That sounds great now that you've explained a bit more.  

CrazyMerlin,

I just want to make sure I have this right.

1. I would use the Python library (in my case) to generate or specify the uploadToken, destFolderPath, forwardingUrl, callbackURL.
2. Create a hashed string from those variables.
3. Pass it into a swf file (over SSL)
   
4. Decrypt the string in the SWF file
5. Create a multi-part post request in the SWF file that posts the file directly to Nirvanix.
6. Create a Python page to handle the response from the callbackURL that either converts the videos creates an error entry. 

Thanks you have been a great help,

Brian

Hi Brian,

Yes that sounds about right, and should certainly give you a decent amount of security as far as not allowing someone to generate those variables for themselves. To make your life easier you might want to add a hyphen inbetween the variables as you join them into a string. You can them use that hyphen as a delimiter to explode the unencrypted string in the SWF file, and also use it as a check check for the correct number of variables.

Ex:

var un_enc_str:String = decrypt(enc_str);
var myVars:Array = un_enc_str.split('-');

if(myVars.length < 4)
{
   getUrl('error.php?a=failure&reason=40', '_self');

}