[Red5] Persistance

[grant@bluetube.com]

I think for authentication I'm torn.... you could do a flat file for users/passwords and encrypt the password before storing it to the file like unix system do however its not "user" friendly from a development perspective as you have a proprietary authentication system.

Does FCS have role base authorization and to what level does it go...

user has access to "resource" or does it go further and determine what a user can do with a resource.  I'm very inclined to put the authentication/authorization in a database, either embedded or remote and we should probably come up with a schema for it, I'm more than happy to do that if we nail down some requirements as my full time job is 80% security development.

Grant

----- Original Message -----
From: Dominick Accattato daccattato at gmail.com
To: John Grden neoriley at gmail.com, Red5 at osflash.org
Sent: 9/28/05 11:53 AM
Subject: Re: [Red5] Persistance

> right, but i don't think we will be able to get into file access until we
> have a scripting solution down the road. right? I mean the current way that
> flash comm server does it is through a property that you set on the server
> side actionscript client object. A user logs into the application server.
> Then the user authenticates against a db, flat file, ldap, flash remoting.
> After that you can then appropriately set acl's (access control lists). This
> is from the livedocs.
>  application.onConnect = function(newClient, name){
> newClient.readAccess = "myMedia/mp3s;myData/notes";
> };
>  any other thoughts?
> 
>  On 9/28/05, John Grden  wrote:
> >
> > "Are the remote shared objects really persisted to a database, forgive me
> > if I'm being stupid but I thought they were in memory objects (I'm not an
> > FCS guy)."
> >
> > no they're not. Memory only in it's base configuration. If someone wanted
> > to extend the SO's persistance beyond the application's life, they'd have to
> > dump it to some sort of db/file etc.
> >
> > "you could put the FLV in the database but we may prefer a flat format for
> > performance, i'm not sure what kind of blob performance something like mysql
> > would have for flv's but I'd imageing we want that as fast as possible. My
> > inclination for persistence would be mysql as the most widely hosted
> > database out there for typical websites and free. If we use hibernate
> > switching databases is easy, there are a few gotchas with some databases (ms
> > sql server doesn't support object graph sorting when an object is part of
> > the result set) but overall is very seamless, we develop using mysql and
> > deploy to db2 (corporate database decision)"
> >
> >
> > Do we need to consider what the user will go through with putting FLV's on
> > the server? IE: if it's saved in a blob/text field in a db, then there's an
> > interface for doing so - right? Right now, all you do is upload the FLV, via
> > FTP, to a folder and you're done. If you want to take a recorded FLV off the
> > server, you just go to the folder of the application and grab it. SO, my
> > thought is, this is very easy and simple to get to FLV files and beleive me,
> > on some applications, this is a big deal.
> >
> > example: If you do a multiuser video chat, you probably will have a
> > security feature where someoen could record someone else's bad behavior. You
> > then have to review that recording as an admin and in alot of cases, need to
> > move the FLV from the server to another location etc. So, have file access
> > is a good idea.
> >
> > Thoughts?
> >
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
> >
> 
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org