2011-02-08 21 views
2

私は既存のフレームワークベースのPHP/MySQL Webサイトを持っています。これは、ユーザー名とハッシュ(MD5)パスワードを持つユーザーテーブルを持つシンプルなセキュリティモデルを備えています。既存のユーザとパスワードを新しいSymfony/sfDoctrineGuardユーザシステムに移行する

私は現在このサイトの "バージョン2"に取り組んでいます。今回は、symfonyをDoctrineと併用しています。新しいバージョンは正常に動作しています。ユーザー管理のためにsfDoctrineGuardプラグインを使用しています。

私は、既存のユーザーを既存のユーザー名とパスワードを維持しながら、最小限の労力で新しいアプリケーションに移行したいと考えています。私の主な問題は、私が使っているパスワードハッシュを変更したいということです。

現在のサイトでは、パスワードが無制限のMD5ハッシュを使用しています。*です。私はすでに既存のアルゴリズムを維持しながら(無塩MD5のために私自身の「アルゴリズム」機能を提供することによって)ユーザーをSymfony/sfDoctrineGuardに移行する方法を考え出しました。しかし、無制限のmd5は明らかに理想的ではありません。

私のカスタムPlain-MD5パスワードハッシュアルゴリズムを使ってsfDoctrineGuardユーザーに正常に移行できるユーザーがたくさんいることから、これらのユーザーを変換して標準を使用できるようにする方法はありますか? SHA1 sfDoctrineGuardアルゴリズムを塩漬けしましたか?

私は、各ユーザーがログインするときにこのユーザーごとに行うことができます。これは、再ハッシュのためにユーザーのプレーンテキストパスワードを取得する唯一の方法だからです。私がする必要があることは、 "このユーザーはこのパスワードで正常にログインしました"という点に何かを突き刺すことだと思うので、ユーザーのアルゴリズム、塩、パスワードを新しいSHA1システムに設定して、ユーザーをデータベースがなくてもそれについて知ることさえできます。

私はちょっと掘り下げてしまったし、sfDoctrineGuard(具体的にはsfGuardSecurityUser、私は思う?)のログインシステムを無効にする方法や正しい方法を見つけることができない。さて、実際のプラグインファイルをハッキングすることなく、悪いように見えます。

Symfony/sfDoctrineGuardの専門家が私に正しい方向を教えてもらえますか?

*私のように見ないでください、それは私の最初のウェブサイトでした!そして、少なくとも私はそれらを平文で保存しませんでした...

答えて

1

あなたの問題を解決するためのたくさんの選択肢があります。

sfDoctrineGuardPluginのほとんどすべてをオーバーロードまたは変更できます。

sfGuardSecurityUserで何かを変更する必要がある場合は、アプリケーションのUserクラス(実際にはsfGuardSecurityUserを拡張します)で変更することができます。

デフォルトでlib/model/doctrine/sfDoctrineGuardPluginディレクトリに置かれているモデルクラスをオーバーロードすることもできます。

デフォルトのガードスキーマも拡張できます。たとえば、ユーザーがパスワードを変更したかどうかを知らせるフィールドを追加し、パスワードを変更しなかった場合は更新することができます。

最後に、あなたのカスタムのパスワード・チェックと設定のアルゴリズムを実装することができます: http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin?tab=plugin_readme(「外部メソッドを使用してユーザーパスワードを確認」と「パスワードを保存するために使用するアルゴリズムを変更」するスクロール)。

+0

ああ!それは私が必要とした単なる手掛かりかもしれません。私はすでに自分のmyUserクラスに独自のバージョンのcheckPasswordを実装しようとしましたが、それは決して呼び出されませんでした(奇妙なことに、sfGuardSecurityUserのcheckPassword()は呼び出されないので、それは実際にチェックを行うPluginsfGuardUserだ。あなたが言及したディレクトリには、オーバーライド可能なバージョンがあることが分かっている。私はそれを見つけられなかった。私は自分のコードをそこに置くことができるはずだ。ありがとう! –

+0

ありがとう、@kuba。私はアルゴリズムの間でパスワードの移行を成功させることに成功しました。別の答えとして私の正確な解決策を追加しました。誰かが同様の問題に直面するのを助ける場合に備えて。 –

0

クーバのおかげで、私は正確に正しい方向を指していました。

誰かがこのようなことをしていた人を助けるために、ここで私がしたことがあります。

まず、既存のユーザーを(古いデータベースからダンプされたテキストファイルのフィクスチャロードを使用して)マイデータベースに移行しました。私は、データロード中にUnalentSentence :: unsaltednotransformと呼ばれる無制限のMD5パスワードを変更せずに残したカスタムアルゴリズムを使用しました。これはsf_guard_userのユーザに、古いパスワードハッシュを 'password'に、 'UniqueSentence :: unsaltednotransform'を 'algorithm'に入れてくれました。 (テーブルに直接行を移しても問題はありません)

次に、自分のカスタムcheckPassword関数を/lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.classに追加しました次のように.PHP、: - それはだ場合、それは古いパスワードアルゴリズムを持つユーザーを検出した場合、それは古いアルゴリズムを使用してパスワードを検証し、

class sfGuardUser extends PluginsfGuardUser 
{ 
    public function checkPassword($password) 
    { 
    if ($this->getAlgorithm() == 'UniqueSentence::unsaltednotransform') { 
     // Our password has been set by a fixture load that left it in its 
     // original state from the old system, an unsalted MD5. 

     // Has the user got the right password? 
     if (md5($password) != $this->getPassword()) { 
     return false; 
     } 
     // Yes. So, now we re-set the password. 
     $this->setSalt(''); // An empty salt will be regenerated 
     // Use a smarter algorithm 
     $algorithm = sfConfig::get('app_sf_guard_plugin_algorithm_callable', 'sha1'); 
     $this->setAlgorithm($algorithm); 
     $this->setPassword($password); 
     // Could just return true here, but dropping through to the usual 
     // method means that if we've broken something, we'll know sooner 
     // rather than later. 
    } 
    // Just pass the call onto the usual method. 
    return parent::checkPasswordByGuard($password); 
    } 
} 

をあなたが見ることができるように、それは非常に簡単ですアルゴリズムをSHA1に変更し、パスワードを再設定します(塩分を最初に空に設定して再生成するように設定します)。その後、基本クラスの標準checkPassword()を使用します。

これは正常に動作しているようです。マイグレーションしたユーザーとしてログインすると、通常のユーザーと同じように動作しますが、後でデータベースをチェックすると、アルゴリズム、ソルト、ハッシュパスワードが予期したとおりに更新されます。

関連する問題