4

私はPerl/Catalystで書かれたカスタマーポータルを開発して維持しています。Catalyst認証プラグインを使用します（LDAPストレージバックエンドと、適切なユーザーが適切なグループメンバーシップを持つようにするためのいくつかのdeny_unlessルールを組み合わせたもの）。

多くの場合、顧客の権限を管理する際に、ユーザーの設定をテストしてから引き渡す必要があります。現在、私たちの唯一の手段はユーザーのパスワードをリセットして自分でログインすることですが、これは理想的とは言えません。特に、ユーザーがすでに自分のパスワードを設定している場合などです。

私の質問はこれです：Catalystの場合、正しいスーパー管理者権限が与えられると、設定のテスト中に一時的に別のアカウントになりすまして、完了したら元に戻すことができるような、ユーザーアカウントになりすます方法に出くわしたことがありますか？

Catalystにない場合、人々は他のフレームワークや独自のカスタムソリューションでこれにどのようにアプローチしましたか？確かに、これはWebアプリケーションに潜在的に悪質な攻撃ベクトルを導入するものですが、実装を余儀なくされた場合、人々はこれの設計にどのようにアプローチしましたか？おそらくいくつかの深刻なcookie-session-fu？それとも、actualID /effectiveIDシステムですか？

4

1 に答える 1

5

カスタムオーセンティケーターコントローラー、カスタムユーザークラス（MyApp :: Core :: User）、およびいくつかのレルムを使用します。

package MyApp::Controller::Auth;
...
sub surrogate : Local {
    my ( $self, $c ) = @_;
    my $p = $c->req->params;
    my $actual_user = $c->user; # save it for later

    try {
        $c->authenticate({ id=>$p->{surrogate_id} }, 'none');
        $c->session->{user} = new MyApp::Core::User( 
             active_user    => $actual_user, 
             effective_user => $c->user );
        $c->stash->{json} = { success => \1, msg => "Login Ok" };
    } catch {
        $c->stash->{json} = { success => \0, msg => "Invalid User" };
    };
    $c->forward('View::JSON');  
}

私はmyapp.conf次のようなものを使用します：

<authentication>
    default_realm ldap
    <realms>
        <ldap>
             # ldap realm config stuff here
        </local>
        <none>
            <credential>
                class Password
                password_field password
                password_type none
            </credential>
            <store>
                class Null
            </store>
        </none>
     </realms>
</authentication>

このようにして、通常のCatalystユーザーオブジェクトを作成しますが、それをカスタムユーザークラスにラップして、より詳細に制御します。サロゲート用の専用レルムを作成することもできたかもしれませんが、代わりに独自のユーザークラスを使用することを選択しました。それはしばらく前に行われたものであり、なぜ私たちがそのようにしたのかを思い出すことができます。

于 2011-02-27T21:29:10.193 に答える