3

ハッシュや暗号化などを下位レベルのコードの奥深くに埋め込む一般的な方法について疑問に思っています。エクスプロイトが発見されて効率が上がると、セキュリティ機能を簡単に評価して更新できるように、ある種のオブジェクトまたはマクロ規則を使用する方がよいようです。たとえば、認証を扱う PHP コード (ブログ、コード キャニオン、フレームワーク wiki など) では、次の規則が見られます。

if ($myhash !== md5(shaX($this->key) . blah($this->salt) . blah($this->var))

これを深く埋める代わりに、これはより良いのではないでしょうか

if ($myhash != MY_HASH($key))

構成ファイルまたはその他の簡単にアクセスできるオブジェクトで MY_HASH を使用して、利用可能になったときにセキュリティを強化して更新/保守を容易にしますか? 暗号化またはハッシュするナゲットを、変換関数のみを含む構成ファイルまたは特別なハッシュ ファイルに入れてみませんか?

また、データベースへのアクセスも考慮してください。PHPには非常に多くの抽象化がありますが、アプリケーションがこれを行っているのを見ています:

// grab some data from the database
if ($this->mongo_flag)
{
    $this->mongo_abstraction
    ->where($blah1, $x)
     ->update($blah2);
}
elseif ($this->mysql_flag)
{
    $this->mysql_abstraction
    ->where($blah1, $y)
     ->update($blah2);
}
elseif ($this->couch_flag)
{
    $this->couch_abstraction
    ->where($blah1, $z)
     ->update($blah2);
}

多分 x,y,z だけが違うのでしょう。

前もって適切な db メソッドを持つオブジェクトをインスタンス化することはできません。したがって、データベース アクセスが行われるすべての場所で繰り返される if/else ロジックを排除できますか?

すなわち

$mydata = $this->db_get_method($blah1, $blah2);

また

$mydata = $DB_GET_METHOD($db_type, $blah1, $blah2);

if/else の識別が優先される場合、ネイティブ API はおそらく変更されず、抽象化はほとんど無効になるため、抽象化をスキップしてネイティブ API を使用するだけで、より効率的かつ簡単に維持できるようにする必要があるようです。 /voided は、考えられる各データベース タイプを呼び出すことによって無効化されます。か否か？

私の主な経験は、リアルタイムの組み込み C プログラミングです (多くの PHP コードは、グローバル構造体で設計された手続き型 C のように見えます)。オブジェクトがあまりにも多くの遅延や複雑さをもたらしていますか?

4

3 に答える 3

0

@ complex857が彼のコメントで述べたように、ハッシュプロセスの単純化を開発するためにPHPにはいくつかの努力があります。とにかく、あなたは自分でそれらを行うことができます（プレーン関数、またはより洗練されたクラス）。

私はあなたのことを正しく理解していなかったかもしれませんが、DBの抽象化に関しては、PHP PDO（およびPEARのDBとMDB2）を使用して、特定のDBエンジン用のオブジェクトを作成できます。その後、メソッドはほぼ同じです（違いが生じます）エンジンの特定の機能を扱う場合のみ）。

PHPに関しても大きな問題があります。アマチュアプログラマーによって作成された、まったく悪いスクリプトに遭遇することがあります。したがって、同じ悪い習慣を何度も目にしたとしても、PHPでそれを行うためのより良い方法がないという意味ではありません。また、これらのスクリプトの古さも考慮に入れてください。PHPは、その存続期間中に大きく進化してきました。

于 2012-07-20T19:01:46.673 に答える
0

認証とデータベースの抽象化は、どちらもよくある問題です。プログラマーの思い上がりや経験不足は、多くの貧弱な再発明 (そして時には有用な革新) につながります。

データベースの抽象化に関する限り、バックエンドの実装が劇的に異なる場合、あなたの例はすぐに崩壊します。たとえば、Couch や MongoDB などの NoSQL データベースのクエリ言語とデータ モデリングは、SQL データベースで使用される従来のリレーショナル クエリとうまく一致しません。特定のバックエンドで何が機能するかについて多くの警告を伴う「共通の」インターフェースを使用するか、または非常に制限されている最小の共通分母を使用する、漏れやすい抽象化になってしまいます。これは ORM の一般的な問題です。期待される ObjectClass <=> DatabaseTable マッピングに完全に適合しない結合またはサブセレクトを表現するのに苦労することがよくあります。

SQLのような一般的なリレーショナル言語をサポートするデータベースなど、「類似の」製品内でも同じことが言えます。通常、すべてのデータベースには独自の SQL 方言があり、通常はサポートされているデータ型から分岐し、実装がトリガー、ストアド プロシージャ、ビューなどのより高度な機能に拡張されるにつれて、さらに大きく異なります。

他の例の外観から、開発者が独自の抽象化を実装するのに不十分な仕事をしている可能性のあるスパゲッティ コードのいくつかに出くわすこともあります。

パフォーマンスが問題になる場合、最良の結果は、特定のデータベース バックエンド向けに最適化し、独自の機能を利用することです。

さまざまなデータベース バックエンドのサポートが優先される場合は、 PDO、Doctrine、MDBなどの標準のリレーショナル インターフェイスがあります。データベース抽象化の新しいカテゴリは、MongoDB や Couch などの NoSQL データベース用の ODM (Object Document Mapper) です。

于 2012-07-24T14:37:06.123 に答える
0

私はあなたが提案しているものが好きです。特にハッシングに関しては、アクセスしやすい場所にまとめるのが賢明だと思います。また、db メソッドの呼び出しについてあなたが提案していることも気に入っています。ただし、PHP を使用して提案していることを行うにはリフレクションが必要であり、それにはパフォーマンスの問題があります。この投稿PHP 5 Reflection API performance をご覧ください。パフォーマンス ヒットはそれほど悪くないように見えますが、パフォーマンスはまだ低下しています。db メソッド呼び出しを実現するより良い方法は、動的メソッドを渡すのではなく、OOP 継承を使用することだと思います。データベースごとに異なるオブジェクトが必要です。

于 2012-07-20T18:45:04.517 に答える