Passwort in User Klasse ?

[Forumsgast]

Hallo,
wenn ich eine Klasse User habe wo Informationen hinterlegt sind wie Username, Email, etc. soll ich dann dort auch das Passwort hinterlegen ?
Beim Einloggen und Ändern des Passwortes muss ich dieses ja mit der Usereingabe vergleichen können und das alte Passwort auch neu setzen können. Jedoch soll es nicht ständig per Getter verfügbar sein.
Meine Frage also: Wie soll ich das Passwort in einem Userobjekt hinterlegen damit ich es überprüfen und ändern kann ohne dass es jeder überall auslesen kann ?

Grüße

[Forumsgast]

Die Klasse braucht lediglich eine Methode, die überprüfen kann, ob ein übergebenes Passwort das richtige ist. Dazu braucht sie es nicht selber kennen - sondern nur das Ergebnis einer Datenbank-Abfrage o.ä. auswerten.

[Forumsgast]

Ok, ja das ist mir auch eingfallen. Soll die Eingabe mit einer Variable verglichen werden oder soll das Passwort direkt mit dem Datenbankeintrag verglichen werden ?

[Forumsgast]

Und ich hoffe du speicherst das Passwort nicht als Klartext ab! Der Hash (inklusive Salt) kann schon im Objekt liegen, das ist nicht so gefährlich wie das Passwort selbst. Aber wenn du auf Nummer sicher gehen möchtest kannst du auch den Hash nur in der DB lassen.

[Forumsgast]

Und ich hoffe du speicherst das Passwort nicht als Klartext ab!

Würde ich nie tun
Ok dann werde ich beide Informationen direkt im Objekt ablegen.

Danke.

[Forumsgast]

Userobjekte enthalten Userdaten (Name, Geburtsdatum..), nicht Auth-Informationen. User können auch ohne Anmeldung bestehen. Z.B. hier im Board sieht man auch ohne Anmeldung die Usernamen, welche Beiträge erstellt haben.

[hts]

Userobjekte enthalten Userdaten (Name, Geburtsdatum..), nicht Auth-Informationen.

Genausogut hätte er es Account-Objekt nennen können ...

[Forumsgast]

Hat er aber nicht.

wenn ich eine Klasse User habe

[Forumsgast]

Ein Personalausweis trägt man bei sich, man hat die Daten vom Ausweis nicht auf die Stirn tätowiert.

[hts]

Vielleicht kann ich das mal aufgreifen.

Vor Kurzem hatte ich mir Gedanken über den Aufbau eines "User-Systems" für ein Community gemacht. Datenbankmäßig bin ich zu dem Schluss gekommen, dass die Benutzer-Informationen in zwei Tabellen hinterlegt werden.

I) Account (Logininformationen: "Loginname", "Password", ...)

II) User ("AccountId", Name, Vorname, Adresse, ...)

Eigentlich bräuchte man noch eine dritte Tabelle, da es eine N-1-Beziehung ist (ein Benutzer kann mehrere Accounts haben)

Geht ihr soweit konform?
Jetzt kommen die Klassen ins Spiel. In einem ZF-Testprojekt (bin neu mit dem Zend-Framework) habe ich zwei Models (Account und User) angelegt. Dann habe ich festgestellt, dass die Models im ZF nicht dem "M" aus "MVC" entsprechen, da ich im Benutzermodel auf beide Tabellen zugreifen müsste, also:

$User->setPassword('geheim'); //Zugriff auf Account-Tabelle + Hashfunktionalität
$User->setZipCode('08150'); // Zugriff auf User-Tabelle 

Und bei der weiteren Recherche habe ich mich dann in den Weiten des Internets verloren (jeder macht es auch noch anders)
Vielleicht hat da jemand einen Tipp, wie man am Besten vorgeht, ohne zu "overengineeren".

[Forumsgast]

$User->setPassword('geheim'); //Zugriff auf Account-Tabelle + Hashfunktionalität

Immer noch falsch. Oder willst Du die ganzen Auth-Methoden im User durchschleifen? Ist doch unnütz!

[Forumsgast]

interface iUser {
   function getName();
   function getMail();
   function setName();
   function setMail();
}

interface iUserAuth {
   function setUsername($stringValue);
   function getUsername();
   function setPassword($stringValue);
   function getPasswort();
}

interface iUserAuthInfo {
   function __construct($usernameString, DateTime $lastLogin);
   function getUsername();
   function getLastLogin($dateTimeFormatPattern);
}

class User implements iUser {
   protected $authInfo;

   public function setAuthInfo( iUserAuth $userAuth) {
      if ( $this->authInfo !== null ) $this->authInfo = $userAuth;
      else return false;
      return true;
   }

   public function getAuthInfo() {
      if ( $this->authInfo !== NULL ) return $this->autoInfo;
      else return false;
   }

   /* .. */
}

class UserAuth implements iUserAuth {

   protected $username, $lastLogin;

   public function __construct($usernameString, DateTime $lastLogin) {
      $this->username = $usernameString;
      $this->lastLogin = $lastLogin;
   }

   public function getUsername() {
      return $this->username;
   }

   public function getLastLogin($dataTimeFormatPattern) {
      return $this->lastLogin->format($dateTimeFormatPattern);
   }

   /* ... */

}

/* sql jobs and data prepare */

$user = new User();
$user->setName($name);
$user->setMail($mail);

/* sql jobs and auth data prepare */

$authedUser = new UserAuth($username, new DateTime($dbValueLastLoginDate));
$user->setAuthInfo($authedUser); 

Ein Personalausweis trägt man bei sich, man hat die Daten vom Ausweis nicht auf die Stirn tätowiert.

[hts]

Immer noch falsch. Oder willst Du die ganzen Auth-Methoden im User durchschleifen? Ist doch unnütz!

Verstehe nicht ganz. irgendwo muss man doch das Passwort setzen/ändern können.

@troy, danke für die Mühe.
Mir ging es um das Zusammenspiel mit den Zend-Models. Aber ich werde es jetzt doch analog deinem Beispiel machen, Models (extends Zend_Db_Table_Abstract) um Business-Logik erweitern und separat ansprechen.

In meinem RegisterController habe ich z.Z.:

$Accounts = new Model_Accounts();
$NewAccount = $Accounts->createRow();

$NewAccount->Username = $RegisterForm->getElement('username')->getValue();
$NewAccount->Salt = $Accounts->generateSalt();
$NewAccount->Password = $Accounts->generatePasswordHash($RegisterForm->getElement('password')->getValue(), $NewAccount->Salt);
$NewAccount->Email = $RegisterForm->getElement('email')->getValue();
$NewAccount->Created = new Zend_Db_Expr('NOW()');

$NewAccountId = $NewAccount->save(); 

Die Hash- / Salt-Funktionalität werde ich dann vom Controller in die "Model"-Klasse verlagern, so dass es automatisch bei setPassword() aufgerufen wird.