ASP.NET

Visual Studio 2008 以前からVisual Studio 2010への移行に関する本が無料！

刈歩菜良 CTP — Tue, 14 Sep 2010 11:25:00 GMT

ネタ元：「http://twitter.com/onos/status/24436694723」

入手ページ：「Free ebook: Moving to Microsoft Visual Studio 2010」

これはとってもタイムリー。

まさに今やってるとこです。

が、きっちり読んでる暇はないかも...

ついでに翻訳したいなぁ．．．

構成ファイルの暗号化／復号化（補足）

刈歩菜良 CTP — Wed, 08 Apr 2009 13:07:00 GMT

以下の記事に対する補足情報です。

「構成ファイルの暗号化／復号化（前編）」

「構成ファイルの暗号化／復号化（中編）」

「構成ファイルの暗号化／復号化（後編）」

いつもお世話になっているGushwellさんからコメントを頂きまして、ちょっとだけ謎が解明できました。

後編ではRSAキーコンテナに対するアクセス権がないとだめよんという話をしました。

RSAキーコンテナに対して特定のユーザーのアクセス権を付与するのにaspnet_regiisの-paオプションを使うのですが、その情報って結局どこでどのように管理されているのかが謎でした。

でも、実行時に出てくるメッセージが

RSA キーコンテナへのアクセスのために ACL を追加しています...
成功しました!

なので、ACLを使っているのはわかるのですが、どこの？ってとこが疑問だったんですね。

で、Gushwellさんからの情報を元に色々と調べてみると、ありましたありました。

ずばりこちらのフォルダ

C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

に良くありがちなごにょごにょした名前のファイルがいくつか登録されておりました。

どれがどれでどうなんだか分らないのですが、適当なファイルを右クリックしてセキュリティを確認するとそこにaspnet_regiisの-paオプションで追加したユーザーが登録されていて、読み取りだけに権限が付与されていました。

なるほど～。意外と超シンプルな仕組みだったんですねぇ。

なっとくなっとく。

ちなみに、Gushwellさんに教えていただいたフォルダは

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

だったのですが、XPとWindows Server 2003 R2で確認したところ、そもそもC:\ProgramDataが存在していませんでした。

何はともあれ、すっきりしました。

Gushwellさんありがとうございます！！＆遅くなりましたが、MVP再受賞おめでとうございます！！

ところで、例のごにょごにょしたファイル名ってMD5かなんかかしら？

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ の下もごにょごにょありますが、あれはまた別っぽいですね。

えろいひと、おせーて。

(・o・)

構成ファイルの暗号化／復号化（後編）

刈歩菜良 CTP — Tue, 31 Mar 2009 04:35:00 GMT

こっからの続きです。

「構成ファイルの暗号化／復号化（前編）」

「構成ファイルの暗号化／復号化（中編）」

中編ではエラーの原因が暗号化のときに使われるRSAキーコンテナに対するアクセス権がないっちうところまで確認してきました。

ほぢゃらば、アクセス権を与えましょ。

で、誰に？？

RSAキーコンテナにアクセスするのをだれぞ？

これは言うまでもなく、ASP.NETのプロセスを動かしてる人です。

Windows Server 2003以降ならNETWORK SERVICEだし、それ以前ならASPNETなはずです。

が、しかし、偽装をONにしてる場合は話が変わってきます。

固定に偽装してる場合と、Webアプリにアクセスするユーザに偽装してる場合と...

あぁ、でもこの話に行くとまた長くなるので、偽装の話は後日書きましょか。

で、今回は偽装なしでってことで。(^^ゞ

でも、それでも疑り深いあなたは。System.Security.Principal.WindowsIdentity.GetCurrent().Nameプロパティを表示するようなページを作って実際のアカウントを確認してみましょう。

RSAキーコンテナにアクセスできるようにしよう！

これまたaspnet_regiis.exeを使います。こないな感じ。

aspnet_regiis -pa RSAキーコンテナ名アカウント

具体例としてはこないな感じ。

aspnet_regiis -pa "NetFrameworkConfigurationKey" "NT AUTHORITY\NETWORK SERVICE"

これで一件落着、さっきのエラーがウソみたいにすっと実行できるようになります。

ちなみに、権限を外すにはオプションを-prにしましょう。

しかし、この権限情報ってどこでどう管理されてるんでしょ。

気になるぅ～～～。

だれかえろいひとおせーて。

構成ファイルを復号化するには

暗号化したはいいけど、その暗号化した情報を修正したい場合もありますよね。

そんな時は一旦復号化すりゃええんですな。

復号化は

aspnet_regiis -pdf 要素名構成ファイルのフォルダ

でOKです。

具体的には

aspnet_regiis -pdf "connectionStrings" c:\InetPub\wwwroot\SampleWeb

修正したら-pefでまた暗号化しましょう。

RSAキーコンテナに対する権限はすでに与えているので、一度やればもうやらなくってOKよん。

いやぁ、ガラにもなく技術ネタ3連発はなんだか疲れちゃったわ（ん？4連発か）。

あさって（あ、いや、もう明日か）はそうはイカの金玉ですが。(^・^)

構成ファイルの暗号化／復号化（中編）

刈歩菜良 CTP — Mon, 30 Mar 2009 15:01:00 GMT

前編はこちら：「構成ファイルの暗号化／復号化（前編）」

前回は構成ファイルを暗号化して実行したけどうまくいかないっ！ってとこまで見ていきました。

まずはエラーメッセージを確認してみましょう。

エラーメッセージ、こんなん出ましたけど。

'/WebApp' アプリケーションでサーバーエラーが発生しました。

構成にエラーがあります。
説明: この要求を処理するために必要な構成ファイルの処理中にエラーが発生しました。以下のエラーの詳細を確認し、構成ファイルに変更を加えてください。

パーサーエラーメッセージ: プロバイダ 'RsaProtectedConfigurationProvider' を使用して復号化することができませんでした。プロバイダからのエラーメッセージ: RSA キーコンテナを開くことができませんでした。

ソースエラー:

行 11: 行 12: 行 13: 行 14: xmlns="http://www.w3.org/2001/04/xmlenc#"> 行 15:

ソースファイル: D:\webappsite\webapp\web.config 行: 13

バージョン情報: Microsoft .NET Framework バージョン:2.0.50727.3082; ASP.NET バージョン:2.0.50727.3082

ポイントはずばり「RSA キーコンテナを開くことができませんでした。」にあります。

あと、「プロバイダ 'RsaProtectedConfigurationProvider' を使用して復号化することができませんでした。」を見てみると、そのエラーを出しているプロバイダーが“RsaProtectedConfigurationProvider”だってこともわかります。

さらに、謎解きの手がかりとして暗号化前と後のweb.configを見比べてみましょう。

web.config に残された手がかり

まずは暗号化前のconnectionStrings要素を抜粋

  1: <connectionStrings>
  2:     <add name="carboDBConnectionString" connectionString="Data Source=localhost;Initial Catalog=CARBODB;Persist Security Info=True;User ID=CARBODB;Password=CARBODB"
  3:     providerName="System.Data.SqlClient" />
  4: connectionStrings>
  5:

次に暗号化後

  1: <connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">
  2:   <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
  3:    xmlns="http://www.w3.org/2001/04/xmlenc#">
  4:    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
  5:    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  6:     <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
  7:      <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
  8:      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  9:       <KeyName>Rsa KeyKeyName>
 10:      KeyInfo>
 11:      <CipherData>
 12:       <CipherValue>TSN6xejPlJgaMCi94oOOKr8su62WZJ7lY7X5+VBVh4LHAvl4E6pmmRoPDs5B1o4ui06dYNYUgOZ3zwj6c+fWj3ttB3mfZkxgjjQbl3K7Rjo7UcrM+FI1GGzhvTJq3wD8uA7XGFjYDTtNqDdcmEcBD83TjvUvpuEz3FXmpScFpUo=CipherValue>
 13:      CipherData>
 14:     EncryptedKey>
 15:    KeyInfo>
 16:    <CipherData>
 17:     <CipherValue>2QtsIq7IlftkzC8nNffjJ5eQ8kRJOt2RTDe9DrLsK8KDyj//60hjmDXJ5ELtwyanRVYoNGyKS1bB9Gr6al5IbodO3q+ghBJjpo0EuF/Hxj4/KC7q+3VYv/TkaqDMMKmJzUBbeypDn3Bg/9azEvDlsisdIMN0+kZUlsfRstRMXxG6h0SGteyibqnRPxCaUvU0SDfII1jbJvEM9efqAPsME3hHnlBsjQBfzcgagVAGJSm3WUo2r1as2e2lxy+7iHK1Jmv+W9AV0nAJhIo3Zrfjge6YqmRmMLzSakLvhE9oq6E2yV+VXfIbgpFPou5MW7jRWNUL59lt0n9bX6CGReeMvQ==CipherValue>
 18:    CipherData>
 19:   EncryptedData>
 20: connectionStrings>
 21:

めっさ行が増えてるけど、ポイントは１行目。

configProtectionProvider="RsaProtectedConfigurationProvider"

ここで暗号化に使われているプロバイダーが指定されております。

# なぜかMSDNのconnectionStrings要素に説明がないんですが...

でも、キーコンテナに関する記述がありません。

実は、RsaProtectedConfigurationProviderが使うキーコンテナ名はデフォルト値なので、個々の構成ファイルに記述はなくって、machine.configに記述があります。

ってことで、該当のmachine.configへ。

# あ、ちなみに、machine.configは%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIGの下にあるのよ。

# さらに、.NET Framework 3.0も3.5もコアは2.0と同じなので、machine.configの場所も同じ。

  1: <configProtectedData defaultProvider="RsaProtectedConfigurationProvider">
  2:     <providers>
  3:         <add name="RsaProtectedConfigurationProvider" type="System.Configuration.RsaProtectedConfigurationProvider,System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" description="Uses RsaCryptoServiceProvider to encrypt and decrypt" keyContainerName="NetFrameworkConfigurationKey" cspProviderName="" useMachineContainer="true" useOAEP="false"/>
  4:         <add name="DataProtectionConfigurationProvider" type="System.Configuration.DpapiProtectedConfigurationProvider,System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" description="Uses CryptProtectData and CryptUnProtectData Windows APIs to encrypt and decrypt" useMachineProtection="true" keyEntropy=""/>
  5:     providers>
  6: configProtectedData>
  7:

うしろーーーーの方に書いてあるけど、

keyContainerName="NetFrameworkConfigurationKey"

ってのがキーコンテナ名でございます。

で、このキーコンテナを開けることができないっちゅーエラーだったわけなんです。

いわゆるアクセス権限がない状態です。

じゃぁ、権限をあげよーってことなのですが、またまた長くなってきたんで、続きは後編で。

☆ﾐ(*^▽^*)ﾉ彡☆

# えぇ、「後編」を「中編」に変えちゃいました。（＾－＾）

# だって長い記事って読む気なくすでしょ。(^・^)

構成ファイルの暗号化／復号化（前編）

刈歩菜良 CTP — Sat, 28 Mar 2009 00:49:00 GMT

おばんです。

やはり今日も日付を超える前に帰れなんだ...

ので、記事書いてからおうちに帰えろっと。

ところで、OSの記事を書いたら右の「あわせて読みたい」もごろっと変わっててびっくりしました。

今はわたくしの心の師匠επιさんのページがトップに返り咲いていて一安心。(^・^)

で、今日は構成ファイルの暗号化／復号化のお話です。

ASP.NETでweb.configなんかにDBのユーザー名・パスワードみたいなちょっと盗まれたら困るようなデータを入れるときにつかったりします。

# が、実際使われてるんかなぁ。web.configが盗み見られる時点でそれ以前のセキュリティがダメダメって話が...

# ま、二重三重のセキュリティという意味では意味があるっちゃあるんやけど。

便利なのは構成ファイルを暗号化してもソースコードは一切変更する必要がないってとこですね。

だから、すでに運用が始まっているアプリケーションもあとでweb.configだけ暗号化しても大丈夫。

# ただし、知らないとちょっとハマりどころはありますが...

使うツール

web.configを暗号化／復号化するにはaspnet_regiis.exeを使います。

そうそう、ASP.NETがおかしくなっちゃったときに修復したり、IIS入れ忘れててVisual Studioを先に入れちゃったりして、IIS側にASP.NETの設定がされなかったりしたときに使うやつです。

暗号化にも使うんです。

暗号化はこんな感じ

aspnet_regiis -pef セクション名 web.configがあるフォルダ

MSDNとかには-peオプションを使ってIIS上に配置済みのWebアプリのweb.configを暗号化する方法が紹介されてるけど、IISに配置前に暗号化したいことも多いので、私は-pefオプションの方が使い勝手が良いように思います。

で、実際の具体例は

aspnet_regiis -pef "connectionStrings" c:\inetpub\wwwroot\WebApp

みたいな感じです。

注意してほしいのはweb.configファイルを直接指定するんぢゃなくってweb.configファイルがある場所を指定するってとこかな。

あと、そうそう、知っている人が圧倒的に多いと思うけど、aspnet_regiis.exeにはパスが通ってないんで、普通のコマンドプロンプトぢゃなくってVisual Studioのコマンドプロンプト使ってちょうだいね。

んぢゃ、暗号化が終わったところで、Webアプリをレッツ実行！

えぇ！！

うまくいかないんだなこれが。

復号化は勝手にしてくれるんちゃうん！！

そりゃないぜせにょ～る。

┐('～`；)┌

わたくしねみゅねみゅなので続きはまたねん。

☆ﾐ(*^▽^*)ﾉ彡☆

# 全部書くつもりやったけど、まだ会社やし、もういい加減帰りたいからタイトルに後付けで（前編）って書いたのはココだけの秘密。

# コメントで答え書いちゃわないでね～ん。

Windows Server 2008のサーバーコア上IISではASP.NETは動きまへん

刈歩菜良 — Fri, 29 Jun 2007 13:01:00 GMT

ネタ元「マイクロソフト，サーバーコア上でIISが使用できるWindows Server 2008評価版を公開」

えぇーーーーーーーー。

CE とかに .NET Framework のるのに、なぢぇにWindows Server 2008のサーバーコアには.NET Frameworkのりませんのん？
# ん？ちと、つっこみずれてる？

ま、サーバーコアでない（？）IISでは使えるから良いけどさ...
# これもずれてるような、ずれてないような。

WebアプリからWCF使いたくても［Add Service Reference...］メニューが出てこんがなぁ。

刈歩菜良 — Fri, 15 Jun 2007 03:33:00 GMT

てなことは、前から気付いてたんやけどね。

で、「Visual Studio 2005 は正式に .NET Framework 3.0 に対応してるわけやないから、しゃあないね。」と、あきらめて、コマンドで

svcutil.exe http://どこぞのサーバー/WCFServe/Service.svc?wsdl

って、やっててんけどさぁ。

ひょんなことから、Web アプリでも［Add Service Reference...］メニューが出ることに気づいた。

なんと、Web アプリにApp_Codeフォルダがあると、［Webサイト］メニューに［Add Service Reference...］があるやん！
# 右クリックには相変わらず出ーへんよ。
わーい！やっぱWebアプリでもできるんやぁ。と、喜んだのもつかの間。実行してみると、

「オブジェクト参照がオブジェクトインスタンスに設定されていません。」

えーーーーーーーーー
なぢぇ、この期に及んで NullReferenceException やねんなぁ。

でも、望みを捨てきれず、ごにょごにょごにょごによ・・・
おかげさまで、また朝までコースかよっ。

はい、結局解決できまへんでした。
(T_T)

いやぁ、ほんと、いい加減こんな時間まで仕事するのはやめたいぞ。

ユーザ認証のハマりどころ

刈歩菜良 — Tue, 24 Oct 2006 16:43:00 GMT

久々の技術ネタです。( ;^^)ヘ..
てか、まともなんは初めて？？（￣□￣；）！！

Windows アプリケーション、Web アプリケーションにかかわらず、ユーザー認証を行いたい場合はプリンシパルを使います。いろんなパターンがありますが、ロール（グループ）の認証でよいのならば、一番単純なのがIsInRoleを使った認証。
たとえばこないな具合。

if (myPrincipal.IsInRole(属していなければいけないロール)) { // 属してるから認証おつけい！ } else { // 属してへんがな！エラー処理。 }

たとえば、Dev1 グループに属してへんとできへん処理ややらしたない処理がある場合はIsInRoleの引数に"Dev1"と書けば良いんやね。

と、思ったら大間違い！！

Windows認証でグループを指定する場合は、そのグループが属するドメイン名(ローカルグループの場合はPC名)を指定せないかんのですねぇ。

【正解】
if (myPrincipal.IsInRole("Karubo-PC\\Dev1"))

ほしたらば、ローカルマシンの Administrators グループに属してるかどうか確認したい場合は、

if (myPrincipal.IsInRole("Karubo-PC\\Administrators"))

って書けばよいわけやね。

と、思ったら超間違い！！

そう、ここがまさにハマりどころ！！

Administratorsをはじめ、UsersなどのOS標準のグループはビルトイングループと呼ばれてるんやけど、ビルトイングループで認証をする場合はPC名ぢゃなくってBUILTINと書かなければいかんのよねぇ。

【正解】
if (myPrincipal.IsInRole("BUILTIN\\Administrators"))

ちなみにちなみに、.NET2.0からはローカルグループやビルトイングループの認証の場合は、ロール名（グループ名）だけでよくなったみたい。

今回はIsInRoleでの認証を例に紹介しましたが、宣言セキュリティ（PrincipalPermission属性）や強制セキュリティ（PrincipalPermissionクラス）でロールを指定する場合もおんなじですよ。

去年の夏にわたくしはここで1～2週間ハマりましたわ。だって、MSDNライブラリのIsInRoleのとこ見てもそんなことひとっことも書いてくれてへんのやもん。もち、フィードバックしときましたが...

参考までにサンプルプログラムおば、

【サンプルコーナー】

【Windows アプリ編】
・Windowsフォームのプロジェクトを作成

・フォームにラベル2つとテキストボックス、ボタンをはっつける。名前はデフォルトのまんま。2つめのラベル(label2)は結果表示用なので、下のほうに大きくはっつけてください。

・ボタンをダブルクリックしてイベントハンドラ作成。

・コードファイルの先頭行に以下の2行を追加

using System.Security.Principal; using System.Threading;

・コンストラクタ（public Form1()って書いてるとこね。）に以下の1行を追加

Thread.CurrentPrincipal = new WindowsPrincipal(WindowsIdentity.GetCurrent());

・button1_Clickイベントハンドラに以下を追加

IPrincipal myPrincipal = Thread.CurrentPrincipal; label2.Text = textBox1.Text + "に属して"; if (myPrincipal.IsInRole(textBox1.Text)) { label2.Text += "います。"; } else { label2.Text += "いません。"; }

・で、完成！後は実行して、テキストボックスにロールを入れてボタンをクリックして下さいまし。2005の人はAdministratorsと入れただけで認証が通りますが、2003以前の方だとBUILTIN\Administratorsと入れないと認証が通りませんよ。

【Web アプリ編】
・Webフォームのプロジェクトを作成。作成場所はファイルシステムでもIIS上でもかまいませんが、IIS上に作った場合はIISの設定で統合Windows認証を有効にしてください。
（管理ツール→[インターネットインフォメーションサービス]を起動。Webアプリのフォルダで右クリック→プロパティ。[ディレクトリセキュリティ]タブの「匿名アクセスおよび認証コントロール」のところにある［編集］ボタンをクリック。一番下の［統合Windows認証］をチェック）

・フォームにテキストボックス、ボタン、ラベルをはっつける。名前はデフォルトのまんま。ラベル(Label1)は結果表示用なので、改行してはっつけてください。2005の方で面倒くさい方は以下のコードをコピーして<div>の下に貼り付けてもOK。

ロール名を入力してください：<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox> <asp:Button ID="Button1" runat="server" Text="ロールチェック" OnClick="Button1_Click" /><br /> <br /> <asp:Label ID="Label1" runat="server"></asp:Label>

・ボタンをダブルクリックしてイベントハンドラ作成して以下を追加

Label1.Text = TextBox1.Text + "に属して"; if (User.IsInRole(TextBox1.Text)) { Label1.Text += "います。"; } else { Label1.Text += "いません。"; }

・Web.configがなければ新規に追加して、<system.web>要素内に以下を追加。

<identity impersonate="true"/> <authorization> <deny users="?"/> </authorization>

なぜコードビハインドするとクラスは継承関係にならなければいけないのか勝手に考えてみました

刈歩菜良 — Thu, 21 Sep 2006 10:18:00 GMT

@PageディレクティブのInherits属性ってばの続きです。

昨日お風呂でぼ～っと考えてたらなんとなく思いついた！
もしかして、継承にしたかったのはコード側のコンストラクタとaspx側のコンストラクタ（自動生成）を分けたい＆起動順を固定したいからだったんかなぁ。

今まではOnInitの中で初期化っぽいことをしていて、InitializeComponent呼び出しなんかもここに入っていたので、独自の初期化処理をコンポーネントの初期化の前にやるのか、後にやるのかなんかを選択できてたけど、これからは選択できんてことやんね。と、いうか、本来は選択できるべきではない？？

そもそも自動生成されたコードが開発用のソースファイルに出てきて変更が可能な時点であやうかったんやけどね。えぇ、今まで講習中に数え切れないほどのトラブルがありましたさ。

#Regionで囲まれてるところ全削除されたり、逆に他のページからコピペしたときに#Region部分も丸ごとコピーしてきたり。そんなご無体なぁ～ (/。＼）
そんな初心者の方に内部構造教えても混乱させるだけやしね。

ASP.NET 2.0になって、講義は格段にやりやすくなりましたわ。オホホホホヾ（@^▽^@）ノ

【注】上記はかるぼの勝手な考察＆妄想なのでまったく裏が取れてません。参考の参考にもならない場合がありますのでご注意おば。
m(._.)m

@PageディレクティブのInherits属性ってば

刈歩菜良 — Wed, 20 Sep 2006 02:00:00 GMT

ふざけたご挨拶だけだとなんなので、この前受講生に指摘されて目からうろこだったネタおば...

受講生：「Inherits属性って継承ですよねぇ。何で継承なんですか。」
わたくし：「それはですね、デザイン担当のaspxファイルが... ぁ...（一瞬フリーズ）」

そう、ASP.NET2.0からはパーシャルクラス採用で、もう継承なんかしてないんやねぇ。
どうせならばInherits属性は互換性のための非推奨の属性にして、なんかもっと的確な名前の属性を作って欲しかったなぁ。PartialClass とか ClassName とか。

おかげで同様の質問が出ると歴史から話さなあかんようになってしまいました。
ヾ(>y<;)ノ

と、思ったら、囚人さんのご指摘の通り、実は.aspxファイルがふた手に分かれてパーシャルなのは変数宣言だけでした。
（囚人様感謝です_(_^_)_ ）

そんな細かな話まで説明しても初心者は混乱が増すだけなので、従来どおり「.aspx が別クラスになって」っていう説明にしますです。

しかし、何で全部パーシャルにしちゃわなかったんやろか？？
?(°_。)?(。_°)?