[Red5devs] Permissions for SOs, and...

[Luke Hubbard]

I had a simple idea for this. Not sure if it fits with what you were
thinking but here goes.

Basically we use naming prefix convention for attribute store variable
names..

First let me say there are three categories.

owner = the client who owns the parent object
local = access by any code on the server
remote = access by the client, via remote get / set

[no prefix] = local public ( local and owner read / write )
_ = local protected ( local read only, owner read /write )
__ = local private ( owner read / write )
$ = remote public ( remote read / write, local read / write, owner read /
write )
$_ = remote protected ( remote read, local and owner read / write )
$__ = remote & local protected ( remote read, local read, owner read / write
)

So some examples. Take the chatroom..

$topic = 'Permissions system, anyone can change this topic. Local or remote'
date = new Date(); // this can be read and set on the server
_admin = 'luke' // only the object owner can change this.
$_users = ['luke','joachim','red5devs'] // everyone can see this, but remote
users cannot modify it.

IMHO groups etc are too complex to add to the naming convention.
Whats cool about this approch is we can implement it in the serializers (
only passing vars from attribute stores starting with $ )
Also implementing the owner check should be easy using our thread local ref
to current connection, and thus the client.
The last thing, is there are all valid ecma variable names, so it wont stop
us scripting things like.

client.$_groups = ['staff','kungfu_fighters'];

Thoughts?

- Luke


On 6/15/06, Joachim Bauch <jojo at struktur.de> wrote:
>
> Hi Steven,
>
> Steven Gong wrote:
> > Good idea. How about we get a design on how the IAttributeStore is
> > arranged for core Red5 objects? And have you got the idea about how to
> > control the access to the attribute store itself?
>
> What I was thinking is that the implementation of the permission
> management code could use the setAttribute / getAttribute methods
> of IAttributeStore to save the permission / group informations
> in special attribute names.  That way we can reuse for example the
> persistence code and objects wouldn't need to implement any special
> code to actually store the permissions, only to manage and assign
> them.
>
> However I don't know yet how we can control the access to these
> attributes - just thinking aloud ;)
>
> Joachim
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20060615/6c98a869/attachment-0001.htm