検索
リンク
タグ
ASP.NET
.NET
ASP.NET MVC
F#
Visual Studio
Azure
ASP.NET Core
ライトニングトーク
Plone
AJAX
Selenium
C#
jQuery
ADO.NET Entity Framework
SQL Server
JavaScript
LINQ
WebMatrix
EFCore
Fizz-Buzz
カテゴリ
最新の記事
最新のコメント
記事ランキング
最新のトラックバック
以前の記事
2022年 12月 2022年 11月 2022年 10月 2022年 09月 2022年 08月 2022年 07月 2022年 06月 2022年 05月 2022年 04月 2022年 03月 2022年 02月 2022年 01月 2021年 12月 2021年 11月 2021年 10月 2021年 09月 2021年 08月 2021年 07月 2021年 06月 2021年 05月 2021年 04月 2021年 03月 2021年 02月 2021年 01月 2020年 12月 2020年 11月 2020年 10月 2020年 09月 2020年 08月 2020年 07月 2020年 06月 2020年 05月 2020年 04月 2020年 03月 2020年 02月 2020年 01月 2019年 12月 2019年 11月 2019年 10月 2019年 09月 2019年 08月 2019年 07月 2019年 06月 2019年 05月 2019年 04月 2019年 03月 2019年 02月 2019年 01月 2018年 12月 2018年 11月 2018年 10月 2018年 09月 2018年 08月 2018年 07月 2018年 06月 2018年 05月 2018年 04月 2018年 03月 2018年 02月 2018年 01月 2017年 12月 2017年 11月 2017年 10月 2017年 09月 2017年 08月 2017年 07月 2017年 06月 2017年 05月 2017年 04月 2017年 02月 2017年 01月 2016年 12月 2016年 11月 2016年 10月 2016年 09月 2016年 08月 2016年 07月 2016年 06月 2016年 05月 2016年 04月 2016年 03月 2016年 02月 2016年 01月 2015年 12月 2015年 11月 2015年 10月 2015年 09月 2015年 08月 2015年 07月 2015年 05月 2015年 04月 2015年 03月 2015年 02月 2015年 01月 2014年 12月 2014年 11月 2014年 10月 2014年 09月 2014年 08月 2014年 06月 2014年 04月 2014年 03月 2014年 02月 2014年 01月 2013年 12月 2013年 10月 2013年 09月 2013年 08月 2013年 07月 2013年 06月 2013年 05月 2013年 04月 2013年 03月 2013年 02月 2013年 01月 2012年 12月 2012年 11月 2012年 10月 2012年 09月 2012年 08月 2012年 07月 2012年 06月 2012年 05月 2012年 04月 2012年 03月 2012年 02月 2012年 01月 2011年 12月 2011年 11月 2011年 10月 2011年 09月 2011年 08月 2011年 07月 2011年 06月 2011年 05月 2011年 04月 2011年 03月 2011年 02月 2011年 01月 2010年 12月 2010年 11月 2010年 10月 2010年 09月 2010年 08月 2010年 07月 2010年 06月 2010年 05月 2010年 04月 2010年 03月 2010年 02月 2010年 01月 2009年 12月 2009年 10月 2009年 09月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 ファン
ブログジャンル
画像一覧
|
2014年 02月 26日
2014/02/26 追記
始めに訂正を。 以下のコメントを頂戴した。 WEBアプリ前提で書いてるようですが、クライアントアプリケーションで app.config はまずくないですか言われてはたと気がついた。 たしかにそのとおりである(!)。 以下で引用しているツイートをきっかけにこのエントリを作成したのだが、そちらの命題はどちらかというとサンプルコード公開においてバージョン管理にキーが保管されないようにするにはという観点であったため、app.config でよしとしていた。 しかし一般的なデスクトップアプリケーションやその類においては、app.config やその外部参照ファイルにキーを書いてはダダ漏れである。 よって本エントリを訂正し、ASP.NET Webアプリケーションに限定した内容とする。 なお、一般的なデスクトップアプリケーションやその類においては、ではキーをどう扱ったらよいのか、申し訳ないが自分は知識と経験がないため、言及できない。 それでは、以下。 発端はこちらのツイート。
外部サービスと連携する ASP.NET Web アプリ昨今の Web アプリケーション開発では、上記の NHK 番組表 API などのように、
それら外部サービスを利用するにあたっては、予め、 "アプリケーションキー" や "APIキー"、"シークレットキー" などと呼ばれる、「秘密のキー」をそれら外部サービスから取得しておくのが一般的だ。 そして Web アプリケーションからは、これら「キー」を添えて外部サービスの API を呼び出すことで、呼び出し元のアプリケーションを認証してもらい、サービスを享受することになる。 さて、Web アプリケーションの実行時はこれらキーを外部サービスに提示して認証する以上、アプリケーションはこれらキーをどこからか取得しなくてはならない。 かといって、その Web アプリケーションのソースコードにこれら秘密のキーを書きこんでしまったらどうなるだろう? キーをソースに書くのはあり得ません!大抵の場合は、開発中は本番用とは異なる、開発・テスト用のキーを使って開発やテストを行うはずだ。なのにソースコードにキーを書きこんでしまったら、開発・テスト中と本番リリースとで、毎回アプリケーションをビルドする羽目になる。 さらにいえば、チームで開発してるとなると、メンバ各々が開発用のキーを使うケースも普通に想定され、そうしたときにはバージョン管理システムにおけるソースコードの衝突が多発してしまう。 また、言うまでもないが、この「秘密のキー」は文字どおり秘密にしておくべきだ。 当たり前だが、このキーはあなたのアプリケーションの「身元」を証明するための「証明書」なので、他の人に開示しないよう注意すべきでなのである。 もしも GitHub をはじめとした外部リポジトリサービスにソース公開するオープンソースプロダクトやサンプル公開を手掛けているきに、ソースコード中にじかに「秘密のキー」を記述してしまい、GitHub で全世界に公開! という状況は避けるべきだ。 くどくど書いたが、要するに、 これら秘密のキーをソースコードに埋め込むのは 「あり得ない」 ということだ。 ではどうするか?ASP.NET Web アプリケーションでは、これら「秘密のキー」は web.config<config>ソースコード中では、System.Coniguration 名前空間の ConfigurationManager クラスの AppSettings 静的プロパティを通して、web.config var appSettings = ConfigurationManager.AppSettings;※さらなるヒント: @shibayan の SwissKnife.T4.AppSettings T4テンプレートを使うともっとスマートに記述できる。 しかしこれだけではまだ道半ばだ。 普通は web.config つまり、このままでは何も解決していないことになる。 しかし、さらに appSettings セクションにはもうひとつ仕掛けがある。 もうちょっと記述を書き足すことで、 appSettings セクションの内容を外部ファイルで上書きできる のだ。 まず、appSettings セクションに、file 属性で外部ファイルへの相対パスを記述する。 <config>※file属性で示す外部ファイルのファイル名に規則・制約はない。 ちなみに、この状態で、hoge.config ファイルが存在しなくても、とりあえずアプリは動作し、ConfigrationManager.AppSettings 静的プロパティも普通に機能する。 しかしここで、下記内容の hoge.config ファイルを作成したとする。 <appSettings>※file属性で示す外部ファイルのパスは相対パスなので、この例では hoge.config は web.config すると、ConfigrationManager.AppSettings 静的プロパティは、もとの web.config 上記 hoge.config によって上書きされた内容 が取得されるのだ。 上記例であれば、appSettings セクションの key="appKey" の内容は hoge.config には記載がないので、web.config しかし key="appSecretKey" の内容は hoge.config に記載があるので、そちらの内容 ("345def" ではなく "xyz789") が取得されるのだ。 この仕組みによって、「秘密のキーに関する部分」と「それ以外の部分」にソースを分離することができる。 web.config web.config <config> Azure Websites や AppHarbor などの PaaS ではASP.NET による Web アプリケーションを配置可能な PaaS として代表的な、Windows Azure Websites や AppHarbor。これら PaaS に、これまでに述べたような外部サービスを利用する「秘密のキー」を伴う Web アプリケーションを配置するにはどうしたらよいか? 勿論これまで説明してきたとおり、hoge.config も一緒に配置することでも機能する。 だがしかし、FTPSでアップロードするならまだしも、Gitリポジトリからの発行とかだと hoge.config はバージョン管理下におくわけにはいかないので、この方法はうまくない。 実はもっと簡単な解決方法があるのだ。 Azure Websites や AppHarbor の、管理 Webコンソール上で "アプリケーション構成" の欄に値を設定すると、アプリケーションから ConfigurationManager.AppSettings 静的プロパティで web.config - appSettings セクションの内容を読み取った時に、 管理コンソールで設定された値が優先して読み取られる のだ。 例えば Windows Azure Websites において、配置した Web アプリの web.config が下記のとおりであったとして、 <config>Azure Webistes の管理コンソールで下図のとおり設定したとすると、 ![]() var appSettings = ConfigurationManager.AppSettings;これで、開発チームは「秘密のキー」をバージョン管理下におくことなく運用チームにアプリケーションの配置イメージを引き渡し、運用チームが PaaS に配置するのと同時に、PaaS の管理 Web コンソールから本番用の「秘密のキー」を設定することで稼働させることができるようになる。 まとめ
以上、サンプルのソースコードだと、ソースコード中や web.config に直接キーを書きこんでしまう例が見受けられるが、そんなサンプルのソースコードでは教えてくれない「現場のノウハウ」ということで。
by developer-adjust
| 2014-02-26 21:38
| .NET
|
Comments(4)
![]()
WEBアプリ前提で書いてるようですが、クライアントアプリケーションでapp.configはまずくないですか
0
![]()
web.configなら、構成変換の追加を使ってもいいんじゃないでしょうか。
> クライアントアプリケーションでapp.configはまずくないですか
ご指摘ありがとうございます。そのとおりでした(汗 エントリ修正の上、冒頭でその旨記載しました。 言われなかったらこのままだったかもしれません、ありがとうございます。
> web.configなら、構成変換の追加を使ってもいいんじゃないでしょうか。
そうですね、そのほうが最適なケースもあるかと思います。 ただ、自分は本エントリで触れたような内容で構成変換を使ったことがなくて、その長短について言及できないです。 ご自身のブログ記事等で構成変換使う場合を取り上げていただけるとよろしいかもしれません、その際は本エントリに URL 掲載・引用させていただきます!
|
ファン申請 |
||