[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: users and owners

I think this is a good idea. In fact I had planned to ask for this soon. I'm
glad someone beat me to it. Please keep in mind that some "Owners" will have
more than one person on staff. I suggest that the Owner record reference a
group that consists of one or more users. It should be possible for a user
to be a member of more than one group. 
Kelly Hays
Manager, Network Services
Texas Tech Univ. Health Sciences Center

>-----Original Message-----
>From: Hitesh Patel [mailto:hitesh@presys.com]
>Sent: Friday, May 10, 2002 12:02 PM
>To: Giaretta Gerardo; northstar-devel@brownkid.net
>Subject: Re: users and owners
>Hash: SHA1
>On Friday 10 May 2002 10:00 am, Giaretta Gerardo wrote:
>> Hi list!
>> I think users management is really well done in NorthStar.
>> May be an improvement may be done considering users and owners together.
>> I guess this situation: the owner POC has to update some information
>> about him or about his objects. It could be possible create a user that
>> has only permissions to edit this owner's objects.
>> May be this is really complex in the code.... it was only an idea I had
>> having fun with the tool.
>> Bye,
>Well, you just answered a question that's been lingering in my mind for a
>while about how to implement exactly what your saying.  For a while now
>been trying to figure out how to implement some segmentation into the
>permissions system so that only certain users could modify/add user certain
>This would be a great way to do this since all that would really have to
>happen would be linking the user to the particular owner object id and then
>checking that what they are trying to view/add/edit/delete is owned by
>owner object.  There could a special id that is reserved for users that
>access to perform operations on anything.
>I think this can be implemented fairly easily.  At the most it would
>require an extra column in the users table that references the owner id and
>may also require making the owner objects nestable so that single users can
>still create owner objects that are referenced under their 'parent' owner
>object.  That and some twiddling with the SQL statements to add a check for
>the owner object should do it.
>Here's how the current permissions checking works:
> 1. The user call is received (ex. addnet)
> 2. API_PermissionsCheck is called with the user call as the parameter
>   a. Lookup user permissions mapping (established earlier in session
>   b. If the user DOES have permission return 1, else return 0
> 3. The user call is used to lookup the function reference that was
>    when the module was init()'ed
> 4. The call is made
> 5. The function does what it needs to
>Now what would need to be added would alter step 5 from above to something
>like this:
> 5. If the function is an
>   a. Edit/Delete/View Function
>	The function immediately calls API_PermissionsCheckUser with
>	specifying the object type (network,device,owner, etc...) and the id
>of the
>	object that is going to be editing/deleted/viewed.
>	then looks up the specific object and if the owner id's match
>	successful.
>   b. Add Function
>	The function immediately calls API_PermissionsCheckUser with
>	specifying the object type, the id of the parent object, and a mode
>	to make API_PermissionsCheckUser traverse towards the root of the
>tree until
>	it finds an object that has an owner id matching the user.  If there
>is a
>	match then we return successful.
> 6. If step 5 was successful continue, if not exit showing an error
>I think this should work fairly well and won't required much new code (at
>least i think).  Anyone have any comments?
>- --
>| Hitesh Patel                    |  Lead Developer            |
>| hitesh@presys.com               |  NorthStar                 |
>| NorthStar: http://www.brownkid.net/NorthStar/                |
>| PGP Key:   http://www.brownkid.net/pgpkey.asc                |
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org