On Wednesday, November 27, 2002, at 11:58 AM, Diego Alonso Lopez wrote:
I`m making a virtual video shop with on-demand movies. People can buy
any movie and see it on they computers. The problem is that everybody
can save the movie (a pointer to the movie) and see it more times
without paying for it.
Ok, i can use access file but the problem don`t disappear because a bad
user can use its login+password and see the film again and again. Even
more, if this user obtains other movie pointer (from a friend for
example) he/she could view this film using his own login+password ?am
i right?.
You are correct. If a user shares their password/username to someone
else, then you have no control preventing unauthorized access. This
is true for most any file sharing service - and isn't unique to
streaming.
Is there any solution for this?.
I only could find a little solution. If i have only one movie and one
access file in each directory i could add a new user in the access file
after he paid. Then, i could delete this user after he/she start to
view the film. This way he/she couldn`t view the film again.
But how could i get just the instant the user started to view the
film????.
One possible solution would be to use "expiring" passwords which would
get deleted after a reasonable amount of time (ie. 24 hours?). You
could
implement this by writing some scripts (Perl is a good candidate for
this),
so that user accounts would be created on-demand (and the qtusers file
updated). Then at regular intervals (ie 24 hours, etc.) you would have
a
separate script that would delete user accounts (which would terminate
their access). Take a look at the 'qtpasswd' utility. It has the
ability to
both create users, as well as to delete them. You can also run the tool
completely from the command-line (with no user interaction) assigning
both the username and password with a single command. Below are
two Perl excerpts (using the system command to execute qtpasswd).
They are provided merely as examples, and they require being run as
the administrator user. Since I don't know what OS you're running, I'll
use DSS unix-style paths in these examples)
#!/usr/bin/perl
...
# Pick a username - this can be chosen by the user or randomly
generated: $username
..
...
# Now generate a random 6-character password (that will be assigned
this user)
@a = (0 .. 9, 'a' .. 'z');
$randompassword = join '', map { $a[int rand @a] } (0 .. 5);
...
...
# Create the new user and/or assign new password to an existing user
in the qtusers file:
system("/usr/local/bin/qtpasswd -F -f /etc/streaming/qtusers -p
$randompassword $username > /tmp/null");
...
# Now, display to the Web user (or email them) what their assigned
username and temporary random
# password is, letting them know that access will expire (ie. within
24 hours or whatever)
...
...
The "expire" script would just need to have a list of usernames that it
should expire,
iterate over the list, and for each name do this:
...
# To delete/expire a user ($username) in the qtusers file:
system("/usr/local/bin/qtpasswd -F -f /etc/streaming/qtusers -d
$username > /tmp/null");
...
Your 'qtaccess' file could then just be set like this:
This way your entire Movies directory would be protected and require
user authentication (in the QT Player/plugin),
and you're not having to create lots of new subdirectories or directly
re-writing out lots of qtaccess files.
FYI, here's all the flags for 'qtpasswd'
Usage: qtpasswd [-F] [-f filename] [-c] [-r realm] [-p password] [-d]
username
-F Don't ask for confirmation when deleting users or overwriting
existing files.
-f Password file to manipulate (Default is
"/etc/streaming/qtusers").
-c Create new file.
-r The realm name to use when creating a new file via "-c" (Default
is "Streaming Server").
-p Allows entry of password at command line rather than prompting
for it.
-P File to read the password from rather than prompting for it.
-d Delete the specified user.
-h Displays usage.
Is it necesary to modify QTSSAccessModule?.
It depends how you want to approach the problem. If you modified
QTSSAccessModule,
there are all sorts of things you could do, including possibly
restricting a user so that a
given username/password would only be valid from a particular client IP
address (at
that time), or even a particular ethernet hardware address. None of
this has been done
though, and it would take considerable programming effort... but the
possibilities are mindless :-)
Being an opensourced project, we appreciate and encourage users to
download the source, take a look at what features they would like to
add, implement them, and share it back with the greater-Darwin
community.
