permission system and usecase ideas

[Michael Ralston <mi...@ralston.id.au>]

I've got an application which requires a fairly complicated permissions 
system.

I am making a website in which users will be able to login to the lenya 
authoring area and edit a 'profile page'. Changes to this profile must 
be approved before being published to the live area. Simple enough right?

Next, I don't want users to be able to create new pages, only edit their 
own page. Not too complicated... Just make a new role called creator.

Also... I don't want users to be able to view other users profile pages 
from inside the authoring area, only from the live area. This seems to 
be getting more complicated to me.

I know it must be possible to achieve the last goal. Not sure how to go 
about it though...

Anyone got any thoughts?

Michael



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org

Re: permission system and usecase ideas

[so...@apache.org]

On 5/19/06, Michael Ralston <mi...@ralston.id.au> wrote:
> I've got an application which requires a fairly complicated permissions
> system.
>
> I am making a website in which users will be able to login to the lenya
> authoring area and edit a 'profile page'. Changes to this profile must
> be approved before being published to the live area. Simple enough right?
>
> Next, I don't want users to be able to create new pages, only edit their
> own page. Not too complicated... Just make a new role called creator.
>
> Also... I don't want users to be able to view other users profile pages
> from inside the authoring area, only from the live area. This seems to
> be getting more complicated to me.
>
> I know it must be possible to achieve the last goal. Not sure how to go
> about it though...

This could be implemented without true security.

"True security" would error if the document is accessed by someone not
on a list.  Each document has an Access Control List that is checked
each time the document is accessed.

"Process security" means the only methods of access force the current
user to a particular document.  In this case, you have a Usecase that
uses the username to decide the document.  If a visitor accesses:
   http://server/pub/somedocument?lenya.usecase=profile (Lenya 1.2)
   http://server/pub/profile (Lenya 1.3)
they receive their document.  The Usecase knows who they are, and only
delivers their document.  The only method of receiving someone else's
document is to login as the other person.  (You could also build a
bypass that accepts a parameter of the desired username, but errors if
the visitor is not in the "admin" group.  It must record the username
parameter for use by the save function, and again check if the visitor
is in the admin group before writing to someone else's profile.)

The difference is important with client applications because a user
can often bypass process security.  Process security is fine for web
applications because there are no possibility of bypassing the access
process.

This is how our "session" Usecase works.  If a visitor is not logged
in, they receive the Login/New Registration screen.  If they are
logged in, they receive their profile form.  There is no method to
retrieve the document without the Usecase from live.  The admins can
edit the data from the User administration screen.  (We stored the
data in the User "description" field because Lenya 1.2 does not allow
dynamic fields in the User documents.  We plan to fix that for
Lenya1.3 so profiles such as you are implementing are easy.)

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org