[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: users and owners
On Tuesday 14 May 2002 06:20 am, Giaretta Gerardo wrote:
> well, I think it could be a great improvement!
>
> Only a remark: I can't understand the benefits of making the owner
> objects nestable... may be this would make the tool more complex and
> less user friendly. Is it really necessary?
>
Well, the particular user would need the ability to add their owners.
Basically what would happen is that new owners added by a user would then be
placed under their particular owner object to keep from polluting the global
owners list.
One way could be to make owners pseudo-nestable where their cannot be nested
under normal circumstances, only when the above situation exists. In essence
the user interface would have no option to add a sub-owner object, and the
only time the program would insert a child owner was when it was tied to a
specific user.
This might sound confusing.. I will post a proposal with what you originally
considered to the list in a couple of days for comments/suggestions.
> Gerardo
>
> > -----Original Message-----
> > From: Hitesh Patel [mailto:hitesh@presys.com]
> > Sent: venerd́ 10 maggio 2002 19.02
> > 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 |
+--------------------------------------------------------------+