2011-01-31 13 views
1

すべてのプロパティファイルがアーカイブ(warファイル)に埋め込まれている特定の環境にwarファイルをパッケージ化できるビルドがあります。ビルドプロダクションリリース - DB接続資格情報

現在、本番用にビルドしようとしています。私の懸案事項は、コードベースでは運用データベースのパスワードを公開する必要がありますが、実際には生産ビルドプロファイルが悪影響を及ぼして実行される危険性はほとんどありません。私はこのリスクを否定する考え

オプションSVNの生産の詳細を格納しないことですと:

  1. は、DBへの接続に使用されている管理者がオーバーライドシステムプロパティを持っている、または

  2. コンテナがc3p0の代わりにDB接続を管理するようにします。この方法で、この設定を自分で管理できます。

アドバイスはありますか?

答えて

2

ではありません。ソース管理システムにプロダクションDBのユーザー名とパスワードを入れてください。プロダクション環境の管理者によって制御または制限されるJNDIを使用して、アプリケーションのDB接続(たとえば、DataSource)を取得する必要があります。

アプリが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のインストールは管理者によってプロダクトサーバで保護されているので、プロダクトサーバで管理者権限がない人は利用できません。

0

私は、プロパティファイルに資格情報をまったく格納しない方法を好んでいます。代わりに、jndiを使用して資格情報を提供するアプリケーションサーバーを優先します。

Apache Tomcatを使用している場合は、たとえばjndi referenceを参照してください。

0

私はアーカイブ内とアーカイブ外の両方のプロパティを持つことを試みました。アーカイブの外にそれらを持つことは、この種の問題を管理する方がずっと簡単です。

には、いくつかの注意事項:プロパティが見つからない場合、それは「ローカルホスト」を使用して、例えば(デフォルトを使用するように

  1. 可能である限り、あなたは、プロパティのデフォルト値を持つことができますデフォルトのデータベース接続URLとして)。
  2. 非実稼働環境のプロパティファイルは、コードとともにソース管理に保存できます。

開発者は、これらの2つのポリシーを使用して、本番管理者には非生産プロパティファイルを管理する責任を負うことができます。また、ほとんどのプロパティをソース管理の中に集中させ、プロパティを十分に分離しながら、物事を集中管理する利点を与えます。

編集:JNDIはオプションですが、構造的にはプロパティファイルを外部に保存するのと同じですが、別の環境では緩くならないように注意する必要があります。

+0

外部にプロパティを持つことはオプションではありません。理由を聞かないでください:) jndiのように見える方法です。 – JamesC

関連する問題