[asterisk-gui] Opinion, what do you want in the gui for users?

[Pari Nannapaneni]

 > that if you give someone access to configuration (i.e. enable the
 > 'config' option) you are giving them blanket access to the PBX's
 > configuration files -- including other user's passwords, the passwords
 > for your various ITSP accounts, etc.

As most of the users personal settings can be managed from users.conf, We can have a modified version of
getconfig for the user (something get_myconfig ) using which the user can retrieve/edit only
his section (context) of users.conf.

This would let the user change most of the things he wants to manage like email adress, vm passwords,
sip/iax passwords etc, but we will soon run into the same problem as steve mentioned here - which is
this would also give the user ability to change his dialplan etc which is probably not what we want.

So using a database looks like the most logical thing here as we can define a per entry basis
permissions using a database. Infact we can even implement multiple levels of user privileges
if we have database - like [SuperAdmin] --> [admin1, admin2..]--> [user1, user2, user3, user4..] etc.
It also have additional benefits like ease of use, ability to do CDR stuff,
ability to do detail statistics/reports of queues and other resources like cpu/network/disk usage etc.

-Pari

Steven Sokol wrote:
> On 4/13/07, Alvaro Oliver <alvaro.oliver at gmail.com> wrote:
>> How about setting profiles?
>> An admin account may have access to every single tab in the GUI, while an
>> user account can just access some selected (by http.conf?) tabs.
> 
> Unfortunately, it's more complex than that.  If you grant a user the
> ability to connect with Asterisk over the Manager API, you can set
> various permissions in their profile in manager.conf.  The problem is
> that if you give someone access to configuration (i.e. enable the
> 'config' option) you are giving them blanket access to the PBX's
> configuration files -- including other user's passwords, the passwords
> for your various ITSP accounts, etc.
> 
> We need to be able to grant a user read/right access on a
> conf-file-by-conf-file basis.   It's also may be better off to move
> the user configuration information out of a flat file and into the
> AstDB -- upgraded to use SQLite3.  That way we could define security
> tables that in turn define what permissions each user has on each
> other table.
> 
> This, by the way, is ANOTHER reason why it's imperitive that
> getconfig/writeconfig NOT embed #includes when processing files.  If
> we give somebody permission to read user.conf but not passwords.conf,
> but users.conf #includes passwords.conf, then the security is
> violated.
> 
> Thanks,
> 
> -S