5

私は、Webサイトを構築するときに、いくつかのかなり簡単な問題を解決することによって、OOPスキルを向上させ始めました。それで、ログインシステムから始めました。YouTubeのチュートリアルに従って、ログインクラスを作成しましたが、それが進むにつれて、多くの疑問が生じました（ところで、コードは100行なので、貼り付けます。 ）。

したがって、このLoginクラスには検証メソッドなどがありますが、セッション検証が行われるようになります。これは、構成内のパラメーターの前に指定されているため、使用できません（少なくともこのクラススコープでは）。

    $this->_username = ($this->_login)? $this->filter($_POST['username']) : $_SESSION['username'];
    $this->_password = ($this->_login)? $this->filter($_POST['password']) : '';
    $this->_passmd5 = ($this->_login)? md5($this->_password) : $_SESSION['password'];

したがって、その場合、セッション変数が設定されていないときは、verifySession（）メソッドを使用できません（たとえば、ログに記録されたユーザーがメインページに表示する内容を区別するため）。

だから私の質問は-その設計は正しいですか、そしてログインシステムの残りの部分をどのように構築する必要がありますか：すべてのページでloggedIn検証とログアウト-それらのそれぞれが別々のクラスにあるべきですか（そしてメソッドについてはどうですか、特定のクラスで繰り返されます、私は常にそれらを継承する必要があります）。OOPにはさまざまなアプローチがあることを認識していますが、初心者として従う必要のある特定のアプローチがあります（これは、OOPを最大限に理解するのに役立ちます）。

4

3 に答える 3

4

本当に「ログイン」クラスが必要かどうかはわかりません。あなたはこのような何かをするかもしれません

class User
{
   private $username;
   private $password;

   public function __construct($username)
   {
     //load this user object here
   }

   private function hashPassword($password)
   {
      ///Dont do this has the hash, but im just keeping it simple
      return md5($password . 'a}{!@#' . $this->username);

   }

   public function authenticate ($password)
   {
      return $this->hashPassword($password) == $this->password;
   }

}

login.php

$user = new User($_POST['username']);
if($user->authenticate($_POST['password']))
{
 //do session initilization here (can be a class, or whatever)
 Session::createUserSession($user)
}
else
 echo 'bad login';

logout.php

Session::destroyUserSession();

このデザインはおそらく最善の方法ではありませんが、あなたにアイデアを与えるかもしれません。

于 2012-06-27T22:54:14.710 に答える
3

「私はyoutubeのチュートリアルに従いました」が最初の問題です。貼り付けた3行のコードだけで、視聴したビデオがアマチュアPHP開発者によって作成されたことがわかります。

「だから私の質問は-そのデザインは正しいのか、そしてログインシステムの残りの部分をどのように構築すべきか」

３行しか掲載されていないので、デザインが正しいかどうかわかりません。そうではないのに賭けたいと思います。

オブジェクトをいつ使用するかについての経験則は、コードが2つ以上の関数を必要とするほど明らかに高度であり、アプリケーションの複数の場所で使用され、コードがない場合は名前空間の競合が発生する可能性が非常に高い場合です。 tオブジェクトまたは名前空間にカプセル化されます。これはその基準を満たしていません-ログインと登録画面はそれぞれ（最大で）1ページであるため、そのコードは1回使用されます。そのロジックをカプセル化する理由はありません。Nikoは、一般的なパターンであり、カプセル化しても問題ないSessionクラスとUserクラスについて言及しました。

ログインシステムの構築に関しては、それらは急速に複雑になり、最近ではほとんど専門化されています。次のSOwiki記事を読むことをお勧めします。

フォームベースのWebサイト認証の最も信頼のおけるガイド

上記のwiki記事に続くパッケージ化されたシステムが必要な場合は、以下を参照してください。

http://barebonescms.com/documentation/sso/

SSOクライアントは、アプリケーションにクラスを提示しません。SSO_LoggedIn（）、SSO_Login（）、SSO_Logout（）などの関数のセットだけです。単純なもので十分な場合にOOPを実行するためだけにOOPを実行するのは誤りです。ソフトウェアを書く方法。機能が優れている場合もあります。コードをインライン化する方がよい場合もあります。それは本当に依存し、何が最善のアプローチになるかについての洞察を得るには何年もの経験が必要です。

于 2012-06-28T14:07:42.500 に答える
0

$_SESSION['password']

セッションにパスワード（プレーンテキスト？）を保存する必要はありません。ユーザーがログインを許可されているかどうかを確認する必要があります。ユーザーがログインを許可して正しいパスワードを指定した場合は、「ログインしている」以上の情報をセッションに保存しません。便宜上、user-idのユーザー名を保存することもできます。

ただし、データベース内のパスワードと比較した後は、パスワードは必要ありません。

于 2017-06-22T11:05:06.593 に答える