4

秘密鍵、メールパスワード、データベースパスワードなどの資格情報はどこに保存しますか？

https://security.stackexchange.com/questions/19785/security-concerns-about-my-webapp/19786#19786に投稿しました

そして、クレデンシャルを保存する最良の方法は外部サーバーにあるようです。

ただし、play2はapplication.confを使用してこれを行います。

  • では、play2のどこにどのようにクレデンシャルを保存しますか？

アップデート1：

はい、herokuを使用しています。

環境変数を次のように設定します。

heroku config:add test=ITWORKS

application.confに追加しました

sometest=${test}

私は次のようにアクセスしようとしています：

Logger.info(Play.application().configuration().getString("sometest"));

しかし、次のエラーが発生します。

UnresolvedSubstitution: conf\application.conf: 54: Could not resolve substitution to a value: ${test}

したがって、play2はherokuにあるため、変数テストを検出できないと思います。しかし、それをローカルウィンドウ環境にも追加しました->それでも同じエラーです。

何が悪いのか分かりますか？

Update2：

うまくいきました。env変数を追加した後、再起動する必要があります。

最後の質問：

ローカルマシンに毎回システム変数を追加するのはちょっと面倒です。開発モードはありますか？

4

2 に答える 2

4

application.confたとえば、環境変数をサポートしますdb.default.user=${DB_USER}。これをコンソールパラメータとして渡すか（に表示されるため安全ではありませんps）、より安全に環境変数として設定できます。

Herokuでheroku config、たとえばを使用して環境変数を設定しますheroku config:add DB_USER=MyDBAdmin。

ローカルでは、を介してそれらを設定するか、 （bashを使用する場合）export DB_USER=MyDBAdminに追加することができます。~/.bash_profile

于 2012-09-05T21:06:05.520 に答える
3

広告。3： In Playapplication.confはroute、他の種類のpath方法ではアクセスできないため、「webrootに配置された」とは見なされません。テリーのアドバイスはPHPでは適切ですが、Playには適合しません（もちろん、フレームワークを知らないと警告しました）。彼はPHPスクリプトのサンプルを提供していますが、私を信じてください。アクセスhttp://somdomain.tld/config.phpとPlayのアクセスの違いconf/application.confは非常に大きいです。それらを直接比較することはできません。

クレデンシャルを保存するapplication.confのが今のところ最も安全な（そして最速の）方法です。パーサーが停止したとしても、ブラウザーでファイルを逆コンパイルする方法を想像することはできません（PHPではないため不可能です）。クレデンシャルを離れた場所に保存することにした場合、クライアントに構成を取得する権限があるかどうか、アプリケーションの起動に必要な時間が長くなるなどを追加で確認する必要があるため、新しいリスクが発生します。

アップデート1：

環境変数を使用することは安全な方法ではありません-マリウスが指摘したように、それはプロセスリストに表示されるので、各管理者にクレデンシャルを表示します。あなたのメール。

Herokuではもちろん、 DB接続URLを渡す方法ですが、他の資格情報は構成ファイルに保存する必要があります。最後に、Procfileコマンドの長さは255文字に制限されているため、すべてのクレデンシャルをその中に配置すると、アプリがいつか起動しなくなることを覚えておいてください。

この場合の解決策は、代替構成ファイルを使用することです。シナリオは非常に単純です。

  1. application.conf実稼働データベースへのURLを保持する一般的なherokuURLにクレデンシャルが含まれているため、Herokuである可能性が高く、コメントする必要がある場合db.default.user。db.default.password
  2. ローカルバージョンの場合、ファイルを作成します。つまりconf/local_postgres.conf、最初にapplication.confを含め、資格情報などの必要なすべての構成キーをローカルのPostgresDBにオーバーライド/追加します。さらに、他のものを設定したり、ログレベルを変更したり、有効smtp.mockにしたりすることができます。

  3. この設定でアプリをローカルで実行します。（注意してください、私はいくつかの問題を抱えて-Dconfig.resourceいたので、代わりに構文を使用する-Dconfig.file必要がありました、あなたはどの方法があなたのシステムでうまくいくかを見つけなければなりません）すなわち。

    play -Dconfig.resource=local_postgres.conf "~run 9123"

    ヒント：デフォルト以外のポートを使用するのが、ローカル構成で作業していることを「実証」する最も簡単な方法です。別の設定があることを忘れて、共通のplay ~runコマンドでアプリを起動する場合、その場所http://localhost:9123にあるアプリは利用できなくなります。

  4. bashスクリプトrun-local（またはrun-local.batWindowsのファイル）を作成し、前のポイントからコマンドを配置します。.gitignoreファイルでは無視してください。

これから、ポイント4のスクリプトを使用して、ローカル開発用のアプリケーションを実行しますapplication.conf。Herokuにプッシュしている間、Procfileで代替構成を設定しないため、からの値を使用してアプリがデプロイされます。さらに、HerokuのSQLを使用してアプリケーションをローカルで実行し、アプリケーションをデプロイにプッシュせずに進化を実行したり、最新のフィックスパックをチェックしたりできる他のいくつかの組み合わせを使用できます。もちろん、データベースのローカルバージョンで開発していることを常に確認する必要があります。そうしないと、誤ってライフデータを変更/破壊するリスクがあります。

アップデート2：

最後に*.conf、異なる場所の構成を変更する必要がある場合に備えて、ファイルを別々のクラスに保存するよりも、ファイルを使用する方が適切です（前述のように、同じコード、開発/製品環境などで作業するチーム）

もちろん、次のように短縮できます。

import play.Configuration;
import play.Play;

// ...
Configuration cfg = Play.application().configuration();

cfg.getString("smtp.password");
cfg.getBoolean("smtp.mock");
cfg.getInt("smtp.port");
于 2012-09-05T22:01:11.527 に答える