Re: [ACL] Knowing the rights we have

["Pierangelo Masarati" <ando@sys-net.it>]

> Hello,
>
> I'm writing a web-based application (Perl CGI) which allows my company's
> users to modify some of their information, such as password, telephone
> number, and so on.
>
> So I generate a web page which contains a form with all the attributes I
> want to show the user (name, groups she's a member of, mail address,
> telephone number...).
> Depending on the rights on the server, the user can read/write some
> attributes, or only read.
>
> I'd like to draw a text-edit box for the fields that the user has write
> access to, and a normal readonly text for the other ones. This way, the
> users wouldn't waste time trying to modify what they can't. Moreover, this
> would allow to instantly view what it is possible to do.
>
> I've been looking for a way to do that in many places (IRC, mailing-list
> archives, Google, etc.), but I couldn't find anything about it. The LDAP
> APIs in common languages don't seem to provide ACL-related functions,
> neither.
>
> A workaround would be trying to update the attribute's value with the same
> value it already has, but I tend to find it a little ugly. I would also
> have to handle some special cases, for example when the value is empty,
> etc.
>
> Did I miss anything ? Any suggestion will be welcome.
> Thanks.

This topic has been discussed some times; you should browse the archives. 
In short: you can't get straight access information via API but trying the
access you want to assess.  Access rights are based on the identity of the
requester, on the value of the accessed data and of other aggregate
structures, and on the type of access, so there's no way you can get that
info unless you simultaneously know all the above.  Access rights are
dynamical, so there's no way you can reasonably staticize them except by
trying modifications.  I note that on the one hand, if you try your
modifications as a whole, you won't be told what modification had
insufficient access; on the other hand, trying each modificaton separately
might lead to different errors, related to temporarily leaving an entry in
an inconsistent state.

A quick approach is to provide your app with static information about what
fields you want to be modifiable, according to the acls you know your
server is honoring.  It's up to you (or your users) to decide if this is
acceptable.  And don't forget to handle error conditions :)

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497