Forum user: rdcpro

Let me know if you need further info. I can hook you up with CDNetworks, but it was remarkably easy to implement, even in SharePoint. Just a few lines of code to gather the stuff I needed, and one call to their COM library function:

    Ikeygen authobj = (Ikeygen)Context.Server.CreateObject("keygen4.keygen");
    string _encryptedToken = authobj.GetCode(
        originalUrl,
        Context.User.Identity.Name,
        TTL,
        Context.Request.UserHostAddress, 
        serverIp,
        _privateKey);

    _encryptedStreamingEndpoint = string.Format("{0}?key={1}", _encryptedStreamingEndpoint, _encryptedToken);

My email is my username on this forum, at hotmail.

Regards,
Mike Sharp

I've recently implemented something similar to the SimpleCDN, except that I'm using CDNetworks as the content distribution network (they have excellent coverage in Asia).

It's based on the encrypted token technique. This offers two levels of protection. You encrypt a token (which contains several things, like client IP, server IP, timestamp, TTL, etc). Then you append the encrypted token to the URL, so that you have a URL that is only valid for the time interval specified in your TTL. The encryption is done via a COM library DLL they supplied (they have it for various platforms), which I imported to an ASP.NET assembly. The encryption uses Blowfish.

The second level of protection is that even if the token is still fresh (within its Time To Live), if the URL has been used before, it won't work a second time. So someone hits the page, which autobuffers the video via RTMP. This caused the request to be made using the encrypted token, and CDNetworks stores that in a temporary list of banned URLs. If the user copies the RTMP streaming endpoint, including the encrypted token, from the page source, it won't work (it's already been used).

Obviously, this doesn't protect you from someone holding a video camera to the screen, nor does it prevent auto background recording techniques (like Tunebite), but it certainly prevents hotlinking, which is perhaps a worse form of theft, because it costs you the bandwidth.

Regards,
Mike Sharp

Using 3.1.1, I've noticed that if I use autoBuffering: true as a clip parameter, the clip doesn't reliably buffer. I noticed by accident that if I switch to autoBuffer: true, then it seems to be much more reliable.

The documentation says the property should be autoBuffering, but both work. What's the difference?

My specifics: Flowplayer 3.1.1, using the RTMP 3.1.0 plugin. I set up the player using a secure one-time URL (CDNetworks is the content delivery network), but the problem shows up whether I use secure RTMP or not. The player is embedded in a SharePoint web part, but I notice the issue even when it's hard-coded into the page.

Regards,
Mike Sharp