Mailing-List: contact dev-help@roller.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@roller.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 25 Mar 2008 10:49:55 -0800
From: Allen Gilliland <Allen.Gilliland@Sun.COM>
Subject: Re: ACL for viewing individual posts?
In-reply-to: <C560602C-9224-46BA-BE0B-B16C99721624@yahoo.com>
Sender: Allen.Gilliland@Sun.COM
To: dev@roller.apache.org
Message-id: <47E94953.6030704@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <2BDEA5EC-8CD8-45A0-9267-0C9A3FE88CBB@yahoo.com>
 <ZCWL7A13E676@zacwolf.com> <ZCWL7A2CF709@zacwolf.com>
 <C560602C-9224-46BA-BE0B-B16C99721624@yahoo.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)

Just so that you guys know ahead of time, setting up the groups & roles 
is the easy part.  The difficult part starts to come when you have to 
make *all* operations in the system enforce those rules and account for 
them.  This is where you are likely to run into problems making this 
work for Roller.

In the case of rendering a blog you have to realize that there become a 
huge number of ways in which the contents of that blog need to be 
rendered based on its intended audience and their permissions, which 
Roller is not equipped to deal with in any way right now.  Basically, 
every piece of a blog which is potentially made viewable has to be 
passed through this system and designed to only return results which are 
intended for the given client.  So with the rendering system, you would 
basically need to rewrite it so that it makes pretty much all decisions 
based on who the client is and what permissions they have.  That is no 
small feat.

Not that I want to discourage you from proceeding to work on this, but 
with changes that big you would probably find it easier to start from 
scratch.

-- Allen


David Jencks wrote:
> 
> On Mar 25, 2008, at 9:40 AM, Zac Morris wrote:
> 
>>>
>>> Just to be absolutely clear, you are interested in setting the
>>> permissions per blog entry, not per blog?
>>
>> Yes, but it would also be possible to set one of the groups as
>> "default" thus making all posts readable only by that "group".
>>
>>
>>
>>> I don't know how people use this stuff or want to use it but to me it
>>> seems like if I was going to go to the trouble of setting up
>>> permissions for something I'd assign them to a blog so that would
>>> provide a convenient re-use point.
>>
>> The difference is, like I said in my original post, the
>> difference between "blog as single topic publishing engine" vs.
>> "blog as multiple topic journal".
>>
>> The first approach, which roller now seems to be geared
>> towards, is where a given blog is matched to a given audience,
>> and then posts to that specific blog match a given "topic"
>> readable for everyone reading the blog.  In this model,
>> entitlement is based on "poster" priviledges, and not reader
>> priviledges.
>>
>> The second approach, which LiveJournal is geared towards, is
>> where a blog is a personal journal, and you basically set the
>> audience for each of your posts [because each post may not
>> match a specific "topic"] (i.e. when I post a journal entry that
>> contains personal information that I only want a group of
>> friends to see).
>>
>> I have no problem doing the work, but like I said I see this as
>> a possible philosophical issue, as it is a paradigm shift of
>> how roller could be used, so wanted to know if anyone is
>> diametrically opposed.
>>
>>
>>
>>
>>
>>>
>>> I had an idea about "hierarchical blog names" sort of like group/
>>> subgroup/.../blogname.
>>
>> Yeah, it has been my experience that only technically minded
>> people seem to embrace hiarachical presentation.  Let take the
>> Windows OS as an example.  Since Windows grew out of DOS, the
>> hiarachical filesystem is pretty much at the heart of Windows;
>> but if you ask the majority of non-technical users to bring up
>> "File Manager" they don't have a clue what you're talking
>> about.  This is why MS is already looking towards a dB/meta-data
>> based OS that won't be hiarachical in nature.  Personally I
>> think that sucks, but I've worked with enough of these
>> non-technical users to understand that they just don't "get"
>> hiarachical file systems.
>>
>> Let me say this all another way.  Typically blogs are mostly
>> matched to a given "topic".  Let's say a political blog.  An
>> individual, or a group of contributors, posts a series of
>> entries that match that given topic that is readable by the
>> entire "audience".
>>
>> What I'm talking about is a blog where the contributor IS the
>> topic.  Since this kind of blog isn't quite so "clear cut" as
>> say a political blog, each "post" might need a different
>> audience.  So instead of having to setup multiple indivdiual
>> "blogs" for different "topics", what I'm talking about is a
>> journal type approach where I post to a single blog, but then I
>> can choose the given audience that post is visible to.  Go take
>> a look at LiveJournal for exactly what I'm talking about.
> 
> Ok, I did :-)  I think I understand what you want to do.
> 
> As Alan says the infrastructure for representing groups of people per 
> user is missing.  You could implement this pretty easily using the RBAC 
> system I have in my head :-)
> 
> The basic idea behind RBAC (role based access control) is that you have 
> users you can identify, permissions to do stuff (in this case do 
> something to a blog or (for your idea) blog entry), and roles (basically 
> abstract names).  Then you have user-role associations and 
> role-permission associations (you can also have role hierarchies, 
> role-role associations, but they aren't necessary for this).  A user 
> gets a permission through a user-role association and then 
> role-permission association.
> 
> Here, to use the LiveJournal wording, each user gets to set up a role 
> for their friends and a role for each custom friend group. Then for 
> instance to make something visible to a particular custom friends group 
> you'd assign the view permission for that something to the custom 
> friends group you have in mind.
> 
> While it might seem a little odd to use roles for this -- often people 
> think of roles as more static, set up by administrators, fewer in 
> number, etc -- this parallels the implementation of discretionary access 
> control using rbac.  I like rbac because it provides a fairly clear 
> framework for thinking about authorization and lets you implement a very 
> wide variety of policies using the same basic system.  For instance you 
> can implement both this -- the extreme of user-based permission 
> management -- and a completely administrator-administered access system 
> using the same framework.
> 
> I have a couple ideas on how to implement the permissions also which I 
> can go into if you want.
> 
> thanks
> david jencks
> 
> 
>>
>> THANKS!
>> -Zac
>>
>>
>> ________________________________________________________________________
>> Delivered using the Free Personal edition of Mailtraq (www.mailtraq.com)
>