Re: [PHPLIB] Fwd: alternative user/group/perm scheme From: Alexander Aulbach (ssilk <email protected>)
Date: 03/21/00

On Tue, 21 Mar 2000, Florian Gnägi wrote:

}hi
}
}you can't do this with phplib since phplib provides only a 'flat'
}permission scheme, that is, only one permission type per person at any
}time. I have the same problem and since phplib doesn't support more
}dimensional permissons I don't use phplib fo this purpose.

The problem is in my sight, that PHPLIB Auth and Perm are different
classes, but this problem is a mix between both classes, cause
permissions *depends always* about which user is identified (or not
identified - this identical). But changes in this direction results in a
complete rewrite of Auth and Perm (=Authperm) and this is no fun. :)

So I implemented a "not so flat" auth scheme, which meets nearly the same
problems, as described.

I had the problem, that different departments of a firm have only access
to their own book-keeping-account (sorry I don't know the correct english
word).

The only things I have added have been:

- A new table besides auth_user, which holds the account-number (or
account-numbers - there could be more than one number, to which the user
belongs)

- a change of auth_validatelogin() like following:

[... select of the correct user-entries as a join between auth_user
and account-number-table...]

    while($this->db->next_record()) {
      ## vvvvv
      $uid = $this->db->f("ma_uid");
      $this->auth["perm"]= $this->db->f("maz_perms");
      if ($this->db->f("ma_login")) {
        $this->auth["uname"]= $this->db->f("ma_login");
      }
      $this->auth["ma_nr"]= $this->db->f("ma_nr");
      $this->auth["ma_anrede"]= $this->db->f("ma_anrede");
      $this->auth["ma_titel"]= $this->db->f("ma_titel");
      $this->auth["ma_name"]= $this->db->f("ma_name");
      $this->auth["ma_vorname"]= $this->db->f("ma_vorname");
      $this->auth["maz_kst"]= $this->db->f("maz_kst");
      $this->auth[kst][$i]=$this->db->f("maz_kst");
      $i++;
    }
    if ($uid) $GLOBALS[lastlogin]=time(); # when has the user logged in last time?
    return $uid;

So every found record will add a new entry to $this->auth[kst]
(kst = Kostenstelle - the german word for book-keeping account-number)

I also added functins, which check, if the user of this session
belongs to this kst and I call it - like has_perm() - inside my
application at those points, which prevent, that the user can access pages
or informations he/she is not allowed to.

This is of course not the best method, but it works and it is very
expandable, cause with this it is possible to handle unlimited users to
unlimited account numbers (only the speed will slow down a little bit for
unlimited account-numbers :-). And inside of account-numbers they have
also different permissions - as you need.

Hm... I just thought a little bit about this: to integrate this a little
better than me, you should change Auth and Perm a little bit more.

The function has_perm() for example should be added by one parameter
(default 0) for the kst (or group or firm or whatever) and return true
only, if it the auth of current session belongs to it.

}I have an additional table 'accessrights' with the user id and the type of
}rights he has for which (company)-id or whatever.
}
}after login, if he has only one accessright it gets registered in the
}session and we now we know for which (company)-id the user has which
}accessright. however, if he has more than one accessright, he might choose
}his functionality from within a list, eg or you could also guess it from
}the context of the requested page.
}
}I think there is no generic solution for such a problem

Yes, but I think the described method in combination with the well known
permissions of PHPLIB will handle a wide area of those problems and you
can add even more functionality without side effects.

}On Mon, 20 Mar 2000, Mocha PHPLIB wrote:
}
}> maybe i didn't make myself clearer. i understand apache virtual hosting
}> functions but that's not what i'm trying to do. perhaps i can illustrate
}> with a more specific example.
}>
}> say i have a job bank website. let's call it www.ineedajob.com. people come
}> and register so we can register their info, keep their sessions and
}> preferences available, etc. now joe_user could be a user trying to find a
}> job, a user who is a job poster (CO_POSTER) for a company (CO), or he could
}> be an admin (ADMIN_CO) from that job posting company.
}>
}> ineedajob have multiple joe_users, COs, CO_POSTERs. and each CO may have
}> one or more ADMIN_CO. they all get registered the same way initially as
}> users of ineedajob. during the registration process, the user can specify
}> if they will potentially be a joe_user, co_poster, or admin_co.
}>
}> all users get system wide permission(s) for the ineedajob website. each
}> page on ineedajob can be protected on an individual user basis, or group
}> (individual co). each user that belongs to their CO group can only
}> post/delete/edit (depending on their permission within that group) jobs for
}> that company only. the admin_co of HealthCare-R-Us is in charge of setting
}> permissions for their company's co_posters and no other companies. All the
}> people from HealthCare-R-Us can't go and modify RentABabe_Inc's job
}> listings or user permissions.
}>
}> i hope that's a little clearer. sorry for the confusion.
}>
}> At 08:56 PM 3/20/00 -0600, Arno A. Karner wrote:
}> >seams to me u should be able to do this with apache virtual hosting, each
}> >virtual host is a group, each group has its own database, then they can do
}> >want they want who cares. if u dont have the ips for virtual hosting by
}> >ip, u should still be able to do it by port number on the same ip, saving
}> >port 80 to be a redirect point to the proper port numner on ther host.
}> >
}> >each group could have an arbatray numenr of user, still nly have 32
}> >permisions/levels but thats a phplib limitation
}> >
}> >My opinions are my own and not that of my employer even if I am self employed
}> >
}> >On Mon, 20 Mar 2000, Mocha PHPLIB wrote:
}> >
}> > > sorry accidently sent this to php3 list instead of here. i think it
}> > belongs
}> > > here.
}> > > >Date: Mon, 20 Mar 2000 17:15:23 -0600
}> > > >To: php3 <email protected>
}> > > >From: mocha_php <mocha_php <email protected>>
}> > > >Subject: alternative user/group/perm scheme
}> > > >
}> > > >anyone extend phplib to use
}> > > >o user with arbitrary permissions
}> > > >o groups with arbitrary group permissions for a group of users
}> > > >o one main 'root' type user for each group so that 'root'
}> > > > user for that group can assign other/new permission(s) for users
}> > > > belonging to that group
}> > > >
}> > > >let me illustrate a scenario. say you have a web site (what else LOL) and
}> > > >each user can sign up and be a member. each user have various permissions
}> > > >to access various pages. that's all fine with the current phplib user
}> > > >authentication scheme.
}> > > >
}> > > >now, within that web site, you have other groups of users, ie. various
}> > > >companies. each company would like their own level of authentication for
}> > > >their company and also allow an 'administrator' for that company to
}> > assign
}> > > >registered (from the main website) various level of access. 

-- 

SSilk - Alexander Aulbach - Herbipolis/Frankonia Minoris - (0931)22032

-
PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in
the body, not the subject, of your message.