Tillämpa kolumnbehörigheter för en tabell över en utlösare

Det korta svaret:ge inte dina användare direkt tillgång till databasen. De ska aldrig kunna ansluta. Endast de personer som ansvarar för underhåll och drift ska ha tillgång till produktionsdatabasen. Detta av säkerhetsskäl. I nästan alla fall där information lagras i en databas finns det en applikation som kontrollerar all åtkomst, den hanterar själva uppdateringarna och den upprätthåller den affärslogik som du väljer.

Blanda inte data med affärslogik.

Det finns några databassystem, som Oracle som utmärker sig på att hyra ut din butik och tillämpa mycket av din affärslogik i själva databasen. Detta är dock för en annan typ av applikation och en annan inställning till att bygga system.

MySQL har inte alla dessa verktyg för att göra detta så enkelt. Lita på mig när jag berättar att du gör dig redo för en underhållsmardröm om du försöker skriva din applikationslogik i triggers och lagrade procedurer och vyer, och sedan ge dina användare direkt tillgång till databasen.

När var sista gången du fick direkt databasåtkomst när du registrerade dig för något? Twitter, Netflix, Groupon, Facebook -- du interagerar med en webbaserad applikation som tillämpar affärsreglerna och läser och skriver data till databasen för din räkning.

Det finns massor av verktyg som gör det enklare att skriva din applikationsprogramvara:felsökning, profilering, källkontroll för kod och samarbetsutveckling, enhetstestning, kontinuerlig integration och distributionsverktyg. Om du försöker skriva in allt i databasen kommer du att förlora allt det.

Här är ett snabbt exempel på hur detta skulle fungera:

Strukturera ditt behörighetssystem som tre tabeller:användare, grupp, användargrupp. Användaren har användarkontona i ditt system, gruppen har de olika åtkomstnivåerna som "admin", "klient", "anonym", etc. Grupper är hur du tilldelar åtkomstnivåer till användare.

`CREATE TABLE `user` (
`user_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`email` varchar(64) NOT NULL,
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 CREATE TABLE `group` (
  `group_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(32) NOT NULL,
  PRIMARY KEY (`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `user_group` (
  `user_id` int(10) unsigned NOT NULL,
  `group_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`user_id`,`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;`

Nu för att definiera några grupper

`insert into `group` (name) values ('admin'), ('user'), ('anonymous');`

Och en användare, lägg sedan till dem i administratörsgruppen:

`insert into user (email) values ('[email protected]');`
`insert into user_group (user_id,group_id) values (1,1);`

Nu säger denna behörighetsmodell att en användare kan tillhöra en eller flera säkerhetsgrupper. Din ansökan skulle kontrollera för dessa grupper och utföra olika åtgärder baserat på resultaten. Låt oss se lite psuedo-kod:

Ladda en användares grupper:

class User {

  private $user_id;
  private $groups;
  private $db;

  function load_groups() {
    // query the database
    $result = $db->query("SELECT name FROM `group` g JOIN user_group ug USING (group_id) WHERE user_id={$this->user_id}");
    // save an array of group names
    while ($row = $result->fetchrow()) {
      $this->groups[] = $row['name'];
    }
  }

  function is_member($group) {
    if (in_array($group, $this->groups) {
      return true;  // user group includes this value
    }
    return false;  // user is not in the group
 }

Nu i din applikation kan du ha en funktion för att se data, men den skulle ge olika resultat beroende på användarens grupper:

function display_data($user_object) {
   display_basic_data();   // everyone sees the basic data
   if ($user_object->is_member('admin')) {  
     // if the user is an admin, then display bank data too
     display_bank_data();
   }
}

På samma sätt bör dina funktioner för att ändra data verifiera att användarna har behörighet att ändra saker.