dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] Ajout : Droits sur les commerciaux


From: Laurent Destailleur (Eldy)
Subject: Re: [Dolibarr-dev] Ajout : Droits sur les commerciaux
Date: Tue, 30 Jan 2007 01:53:43 +0100
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

Rodolphe Quiedeville a écrit :
Le 26.01.2007 19:52, Laurent Destailleur (Eldy) a ecrit :
Franky Van Liedekerke a écrit :
On Fri, 26 Jan 2007 16:59:41 +0100 (CET)
Régis Houssin <address@hidden> wrote:

j'ai ajouté ceci en test sur /comm/propal.php afin de sécuriser
l'accès aux fiches propal envers les commerciaux qui sont restreint
au niveau visualisation des sociétés, est-ce que ca convient ? si oui
on le reporte sur les factures et autres :

// Protection restriction commercial
  if (!$user->rights->commercial->client->voir)
  {
    $sql = "SELECT sc.fk_soc";
    $sql .= " FROM ".MAIN_DB_PREFIX."societe_commerciaux as sc";
    $sql .= " WHERE sc.fk_soc = ".$propal->socid." AND sc.fk_user =
".$user->id;
    if ( $db->query($sql) )
    {
      if ( $db->num_rows() == 0) accessforbidden();
    }
  }
  //fin de Protection restriction commercial
On y ait presque mais ce code empêche un utilisateur externe de voir ces
propres propal.

J'ai donc apporté une modification et j'ai réessayé les tests dans les 4
combinaisons possibles et la règle suivante est bien respectée:
Utilisateur interne socid=0 + Droits voir tous clients        => Voit
toute société
Utilisateur interne socid=0 + Pas de droits voir tous clients => Ne voit
que les sociétés où il est liée comme commercial
Utilisateur externe socid=x + Droits voir tous clients        => Ne voit
que lui meme
Utilisateur externe socid=x + Pas de droits voir tous clients => Ne voit
que lui meme

Je te laisse regarder Régis et si ok, on l'applique aux autres entités.
Par contre pour des raisons de lisibilité je remplacerais le code sql
par une méthode sur l'objet user

if (! $user->isCommercialOf($propal->socid)) access_forbidden();

Cela simplifiera aussi la recopie du code dans les autres entités.

Je pensais à déplacer aussi ces vérifications de permissions, pourquoi
ne pas plutôt mettre cela dans l'objet qui est demandé par l'utilisateur ?

Quand on fait un Propale::Fetch par exemple on passe l'utilisateur
courant et on vérifie avant de retourner les données ?
Les habilitations sont des fonctions metiers du domaine habilitation
Les classes des fonctions métiers propres à l'entité.

Si on ajoute les habilitations dans les classes meme, on crée une dépendance entre du code métier et le système des habilitations. Que se passe-t-il quand ces classes métiers sont utilisé en dehors d'un contexte web (en batch par exemple ? Ou par une interface extérieure ?) De plus cela déporte la sécurité qui pour moi doit etre au début des pages web à un niveau plus bas, donc conceptuellement moins bon, meme si en théorie cela ne change rien.

De plus tous les accès ne se font pas forcément par le methode fetch. Ainsi les écrans de recherche ramène des listes et non une instance particulière d'un objet.


--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Author) : http://awstats.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net
Dolibarr (Contributor) : http://www.dolibarr.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]