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

Re: users and owners



On Sunday 12 May 2002 12:09 am, Hays, Kelly wrote:
> Hi,
> 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.

Yeah... this could get complicated.  I will hash out some plans for it and 
post them to the list for suggestions in a couple of days.

> Thanks,
> 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
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >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
> >i've
> >been trying to figure out how to implement some segmentation into the
> >permissions system so that only certain users could modify/add user
> > certain objects.
> >
> >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 their
> >owner object.  There could a special id that is reserved for users that
> >have
> >access to perform operations on anything.
> >
> >I think this can be implemented fairly easily.  At the most it would
> >probably
> >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
> >setup)
> >   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
> >registered
> >    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
> >arguments
> >	specifying the object type (network,device,owner, etc...) and the id
> >of the
> >	object that is going to be editing/deleted/viewed.
> >API_PermissionsCheckUser
> >	then looks up the specific object and if the owner id's match
>
> returns
>
> >	successful.
> >   b. Add Function
> >	The function immediately calls API_PermissionsCheckUser with
> >arguments
> >	specifying the object type, the id of the parent object, and a mode
> >switch
> >	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                |
> >
> >+--------------------------------------------------------------+
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.0.6 (GNU/Linux)
> >Comment: For info see http://www.gnupg.org
> >
> >iD8DBQE82/0CCws8KqPtd2URAqo0AJ9iKtvyaon4mk2xte9fphn0lx6OGgCfe9fh
> >OjLLEceJ+JQhM/vnohcTlPE=
> >=qUYy
> >-----END PGP SIGNATURE-----

-- 
+---------------------------------+----------------------------+
| Hitesh Patel                    |  Lead Developer            |
| hitesh@presys.com               |  NorthStar                 |
+---------------------------------+----------------------------+
| NorthStar: http://www.brownkid.net/NorthStar/                |
| PGP Key:   http://www.brownkid.net/pgpkey.asc                |
+--------------------------------------------------------------+