1

すべてのプロパティファイルがアーカイブ（warファイル）に埋め込まれている特定の環境用にwarファイルをパッケージ化できるビルドがあります。

私たちは今、本番用に構築しようとしています。私の懸念は、コードベースが本番データベースのパスワードを公開する必要があることです。本番ビルドプロファイルが実行されて悪影響が生じる可能性は低いですが。

このリスクを打ち消すために私が考えたオプションは、生産の詳細をSVNに保存しないことです。

  1. 管理者に、DBへの接続に使用されるシステムプロパティを上書きさせる、または

  2. コンテナにc3p0ではなくDB接続を管理させます。これにより、コンテナはこの構成を自分で管理できます。

何かアドバイスはありますか？

4

3 に答える 3

2

本番 DB のユーザー名とパスワードをソース管理システムに入れるべきではありません。アプリはDataSource、運用環境の管理者によって制御/制限されている JNDI を使用して DB 接続 (例: a) を取得する必要があります。

たとえば、アプリが Tomcat にデプロイされている場合、tomcat/conf/context.xml には次の内容があります。

 <Resource name="jdbc/myDB"
              auth="Container"
              type="javax.sql.DataSource"
              maxActive="20"
              maxIdle="10"
              maxWait="3000"
              username="myusername"
              password="mypassword"
              driverClassName="com.mysql.jdbc.Driver"
              url="jdbc:mysql://myhost:3306/myschema"
              defaultAutoCommit="false"/>

java:/comp/env/jdbc/myDB..そして、アプリがユーザー名やパスワードを提供する必要なく、接続が取得されます。tomcat のインストールは管理者によって製品サーバーで保護されているため、製品サーバーで管理者アクセス権を持たないユーザーは使用できません。

于 2011-01-31T16:36:24.507 に答える
0

本番環境では、資格情報をプロパティ ファイルにまったく保存しないというアプローチを好みます。代わりに、アプリケーション サーバーが を使用して資格情報を提供することを好みますjndi。

Apache Tomcat を使用している場合は、たとえば、jndi リファレンスを参照してください。

于 2011-01-31T16:34:15.237 に答える
0

アーカイブ内とアーカイブ外の両方にプロパティを設定しようとしましたが、アーカイブ外にプロパティを設定すると、この種の問題を管理するのがはるかに簡単になります。

注意事項:

  1. 可能な限り、プロパティのデフォルトを設定して、プロパティが見つからない場合にデフォルトを使用することができます (たとえば、デフォルトのデータベース接続 URL として「localhost」を使用します)。
  2. 非運用環境のプロパティ ファイルは、コードと一緒にソース管理に保持できます。

これら 2 つのポリシーを使用すると、開発者は非運用プロパティ ファイルの管理を担当できるため、運用管理者の例としても役立ちます。また、ほとんどのプロパティをソース管理で一元管理することで、プロパティを十分に切り離しながら、一元管理することの利点をいくつか提供します。

編集: JNDI はオプションですが、構造的にはプロパティ ファイルを外部に保存するのと同じであることに注意してください。異なる環境でそれらが緩まないように、これらをバージョン管理する必要があります。

于 2011-01-31T16:34:47.467 に答える