tedd.sperling

Hi gang:

Here's the problem.

I have a client who has Flash Videos and wishes to rent these Videos
out for a certain time period. (No, it's not porn -- shame on you).

the video. That's all been solved.

However, once the user is provided with a url where the Flash Video
resides, then the user can view the video remotely by just creating a
page that references that url -- that's easy to do.

Now, how can I stop that from happening?

I have some ideas, but would like to hear what greater minds have to say. :-)

Thanks in advance for all replies.

tedd


--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

parasane

I stopped reading at this point, due to lack of interest.

Then I started again.


You could do link expirations with an auto-generated URL to mask
the actual location, or could even create a dynamic symlink or copy on
the server itself. Have it expire and regenerate a new link every 15
minutes.

To stop people from remotely-linking the video, disable hotlinking
of that file (or type) in Apache.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

robert

Use a URL that maps to a PHP script. Have the PHP script check that they
are logged in. If not, redirect to login. If they are logged in, then
flush the flash object to their browser with appropriate headers.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

tedd.sperling

Rob:

I have all of that logic in place now.

My question was specifically how to stop a remote viewer from viewing
the video once the url is known.

I think Daniel answered it by disabling hot-linking. I just need to test it.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

tedd.sperling

???

You lost me at "You could do.."

You have an example?

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

robert

Then what is the problem? or do you mean you don't ant the same user to
view the item while logged in at some point in the future? If so then
use a GET parameter (MD5 or SHA1 should suffice) that maps to a DB entry
that indicates expiration time.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........

parasane

Not really, but I do have theory in explanation:

1.) Links are generated to the videos based on a cron that runs
every 15 minutes. The links can either be generated for
each individual, or can be generated for the server as a whole.
While the former is more secure, the latter is much more prudent
and takes far less resources. Chances are, a global re-address
should suffice.

2.) The generated links are stored in a database, and are called
when a page loads. See the postscript for one possible point
of interest related to this.

3.) The user clicks the generated link, which is a mask to the actual
file. The user does not see the actual file, however, as this
is where Rob's idea of flushing the file through the buffer comes
into play. The file is `read` through the buffer to the client.

ALTERNATIVE 1:
The cron can create symlinks on the server to the original files
to be used either under the user's directory (to which they, and
only they, have access), or done globally.

ALTERNATIVE 2:
Physically copy the files into the user directory, and have them
renamed or removed from the directory on a schedule. This will
allow you to halt access should the files be hotlinked. Conversely,
you can do what I've done over the years: when you detect that
someone is displaying an image on their page that resides on your
server, eating your bandwidth, you replace it with something
undesirable.
For example, I had a wannabe tough-guy on MySpace displaying
a graphic from one of my sites (militaria) on his profile. It was a
rather large graphic that was sucking down about 50MB per day.
I replaced it with a cute graphic announcing how much he
enjoyed Pokemon, and the linking stopped within about 48 hours.

So there are plenty of viable methods.... choosing which works
best in your situation is the key.

P.S. - In Step 2, keep in mind that, if a page is loaded and a
link not clicked prior to the next run of the cron (and subsequent
generation of links for the client to receive), the links will cause
404 errors. One solution would be to maintain a key in the database,
with one or two rows of previously-generated links. This will allow a
minimum of 16 minutes (on two rows) to a maximum of 44 minutes (on
three rows). The $_SESSION['key'] (or ?key=xxxx) variable is looked
up in the database when the link is clicked, and PHP determines how to
translate the link. If it's not found, the session has been active
and idle for too long, and times out. This is another recommended
layer of security for any user area, of course, because there should
be no Good Reason[tm] that anyone would be staring blankly at a page
for 44 minutes. If they simply forgot about the session, then they
can suffer the consequences and take the 30 seconds (or less) required
to log in again.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

frozendice

Tedd, I think your biggest problem is going to be that most browsers cache
the things they run across, this would include embedded flash videos,
although it may take a little work
(http://www.walkernews.net/2007/06/03...-cache-folder/)
the users could grab the file form their cache. Second even if you use PHP
to map to a file eg. somephpfile.PHP?file=dl29coj2jodod which would respond
by serving a specific file, all you have to do is use Firefox's HTTP Live
Headers extension which will see the response come back with the actual
filename since you have to connect to it eventually.

You can fix the caching problem by following one of these suggestions
http://kb.adobe.com/selfservice/view...nalId=tn_14743
And as far as the evading the live headers finding the actual file name and
just directly downloading it I'm not really sure how you would stop that.
You could have a PHP file open the .swf and read all of it's contents then
write out the headers and all the data, that way the user would really only
be talking to the PHP file.

Oh, and there's one more big problem. What's to stop people from just
taking the url (mapped or not) once logged in and just going to that
directly and doing a save as?

Really there's a ton of interesting ways a user could grab the flash movies,
but maybe rather than just having a .flv player and .flv files which can be
stolen off your site you might want to build authentication into the flash
movie itself. You could do something like serve the customer a unique
cookie every time they request to watch a movie, then serve them the movie
and have it check for the cookie.

Although even with all that in place you can still just get a flash
decompiler and decompile the protected .swf player/video and grab the .flv
content out of it.

Jesh, this is really a lot harder than I thought. Oh well, guess there's
never absolute security.

- Dan

tedd.sperling

Rob:

I'm sorry, I must not explaining it well.

I have all the code in place to manage viewers.

What I'm asking is how to stop someone who isn't authorized to view a
video after they know the url.

For example, let's say a person pays and has access to the video for
some period of time.

Later his time runs out and if he returns to the site and tries to
see the video again, he can't because he has to pay again. No
problem, I have all that worked out.

However, let's say the user pays, views the video, makes a note of
the url, and his time runs out. What's to stop him from viewing the
video again by just entering the url?

That's what I'm asking -- I think Daniel's suggestion to prohibit
hot-linking may work. I just need to test. Also, Daniel has provided
me with some other code that is going to take me a while to test.

Thanks for your time.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

robert

It's simple, the URL should NOT directly point to the flash. It should
point to a PHP wrapper script. The wrapper script then allows you to do
any kind of checking necessary to restrict viewing of the video. This
can include:

- checking that the user is logged in
- checking that the user paid during current session
- checking that the user has email address robert@interjinn.com
- etc

If the check allows viewing of the flash, then read the content of the
flash object in PHP and flush to browser along with appropriate flash
content headers.

Cheers,
Rob.
--
.................................................. ..........
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
.................................................. ..........