検索
リンク
タグ
ASP.NET
.NET
ASP.NET MVC
F#
Azure
Visual Studio
ASP.NET Core
ライトニングトーク
Plone
Selenium
AJAX
C#
jQuery
ADO.NET Entity Framework
JavaScript
SQL Server
EFCore
LINQ
WebMatrix
Fizz-Buzz
カテゴリ
最新の記事
最新のコメント
記事ランキング
最新のトラックバック
以前の記事
2024年 02月 2024年 01月 2023年 12月 2023年 11月 2023年 10月 2023年 09月 2023年 08月 2023年 07月 2023年 06月 2023年 05月 2023年 04月 2023年 03月 2023年 02月 2023年 01月 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月 |
2012年 03月 04日
ASP.NET MVC4 WebAPI とはこの投稿を書いている時点ではまだβ版である ASP.NET MVC4。この ASP.NET MVC4 の新機能のひとつとして、"WebAPI" という機能がある。 これは、ASP.NET MVC の仕組みを基盤とし、"GET api/values" というような RESTFull な HTTP 要求に対して、JSON や XML 形式でのリソース公開・更新を可能とする Web アプリを、容易に開発可能とするものだ。 より具体的には、ASP.NET MVC4 によって提供される ApiController という新顔のコントローラクラスがキモ。 1. この ApiController クラスから派生したコントローラクラスを実装し、 2. さらに HTTP の動詞 ("GET", "POST", "PUT", "DELETE"...) と同名のメソッドを実装することで、 上手いこと先述の "GET /api/values" といった HTTP 要求がこれらメソッドの呼び出しにマッピングされる仕掛けである。 メソッドの戻り値も ActionResult ではなく、シンプルにただの string だったり、IEnumerable この戻り値は ASP.NET MVC4 WebAPI の仕掛けによって、JSON または XML に整形されてクライアント側へ返信される次第。 詳しくは、もちろん、公式サイトを参照されたし。 数分程度の短いビデオで、1トピックずつ入門することができてわかりやすい。 解説の音声は英語だが、コードを書いている画面を見ていれば充分理解できる。 Web API: The Official Microsoft ASP.NET Site www.asp.net/web-api ASP.NET MVC4 WebAPI の用途さてこの新機能、"WebAPI" の用途だが、上記公式サイトのビデオなどを参照する限りでは、"Single Page Web Application" のように、クライアント側で jQuery や knockout.js といったライブラリを活用しサーバー側と XHR で通信してリッチな UI と体験を実現する、そのサーバー側実装とすることが主眼に置かれているようにも見える。しかしながら、当然、この WebAPI 機能は、(同サイト上の) HTML ページ内の JavaScript から呼び出す用途に限らず、ほかのアプリケーションにリソースへのアクセスや機能を公開することにも使える。 ただし、GET アクセスのみならず、POST や PUT などのような、追加/更新/削除までも、誰彼無く匿名のクライアントに広く許す API 公開は、実運用上は考えにくい。 (GET だって、公開するリソースの内容によるが、多くの場合は匿名アクセスは禁じたいだろう) ASP.NET MVC4 WebAPI を認証&承認で保護するということで、認証済みのクライアントからのアクセスのみ、WebAPI の使用を許可することを考えてみる。方法1. Authorization 属性ASP.NET MVC では、コントローラクラスに Authorization 属性を付けることで、匿名アクセスを拒否することができる。ApiController に対しても、もちろん、これは通用する。 Authorization 属性のパラメータを指定すれば、特定のユーザーやロールに対してのみアクセスを許可する、といった指定も可能だ。 方法2. URL 承認ASP.NET Framework の基幹部分として、UrlAuthorizationModule というものもある。要求 URL に応じたアクセス許可を行うモジュールだ。 こちらも、Web Forms に限らず、MVC アプリに対しても普通に機能する。 例えば web.config に下記のように記述可能だ。 匿名ユーザーは "?" で表現される。 よって上記記述は、Web サイトのルート以下は、匿名ユーザーによるアクセスは拒否(deny)する、というわけだ。 URL 承認は、location セクションを記述したり、サブフォルダに配置された web.config で重ねて記述したりすることで、きめ細かく設定することが可能だ。 匿名ユーザーによるアクセスを拒否するとどうなるかさて、上記いずれかの手段により、WebAPI への匿名ユーザーによるアクセスを拒否したとしよう。すると、何が起きるか。 Visual Studio 11 Beta のプロジェクトテンプレートの、「Web API」テンプレートから作成したてのプロジェクトの場合、web.config の設定で、Forms 認証が有効になっている。 その結果、API への要求が、ログインページへのリダイレクト(HTTP 302 Found)となって返ってくるのだ。 ちなみに、「Web API」プロジェクトテンプレートにはログインページの実装は含まれていないため、最終的に HTTP 404 Not Found となっておしまいである。 もちろん、ログインページを実装し、適切にメンバシッププロバイダ等の認証まわりを配線・設定しておけば、これはこれで機能する。 人が Web ブラウザを介して API へアクセスを試みたのなら、このリダイレクトされたログインページで、予め構成しておいた然るべきユーザーによるアクセス名・パスワードを入力することで認証を済ませることができる。 しかし、先に書いたとおり、今回のテーマはほかのアプリケーションからの機械的なアクセスである。 ログインページたる HTML 文字列がアプリに返されたところで、その HTML をスクレイピングするのもおかしな話で、困ってしまうだろう。 HTTP 基本認証ということで今回は、まず、HTTP 基本認証 (ベーシック(Basic)認証) で認証させてみることにした。まずは NuGet Package Manager を使って HTTP Authentication Module をプロジェクトにインストールする。 なお、今日時点の HTTP Authentication Module の NuGet パッケージによるインストールには不足があって、インストール直後にそのままアクセスすると、web.config の構成エラーになってしまう。 web.config のどこかに、 <authentication mode="None"></authentication>という行があるはずなのでこれを削除。 さらに、同じく web.config のまた別の箇所に、 <authentication mode="Forms">という行があるはずなので、この mode 属性値を、Forms から None に書き換えておくこと。 ちなみに、この設定変更によって、ASP.NET 既定の認証モジュールは機能が無効化され、HTTP Authentication Module による認証機構のみが動作する次第。 以上で、まぁ、至極当然のことではあるのだが、普通に HTTP 基本認証にてユーザーを認証するようになった。 HTTP 基本認証であれば、たぶん、大抵の HTTP クライアントから、Credential 指定することでアクセス可能になるはずだ。 ただ、基本認証はそのままではユーザー名・パスワードが平文でネット上を流れることになる。 SSL 経由でのアクセスが前提となるだろう。 なお、HTTP Authentication Module は、HTTP ダイジェスト(Digest)認証にも対応はしている。 ダイジェスト認証であれば、非 SSL な通常の HTTP プロトコル上であってもユーザー名・パスワードが平文で流れることもなく、リプレイ攻撃にも耐えられる。 ただしダイジェスト認証を使うには、ASP.NET のメンバシップなどは使えず、HTTP Authentication Module 独自の構成セクションに独特のルールで MD5 ハッシュ値を記述しなくてはならない。 またどのみち、認証&承認によって保護したいリソースであれば、そもそも SSL でセキュアに保つことが前提になるだろう。 そんなわけで、実際のところ、ダイジェスト認証による認証は実用的ではないだろう。 認証方式を仕分ける(未達成)以上で、いちおう、ASP.NET MVC4 WebAPI サイトを、HTTP 認証による認証にて、アクセス制御ができるようになった。HTTP 認証なので、様々なプラットフォームから、認証可能なはずだ。 ただし、この方法では、サイトがまるごと HTTP 認証による認証となってしまう。 人が Web ブラウザを使ってページを開くときは Forms 認証、外部アプリケーションからの API への直アクセスに対しては HTTP 基本認証、といったように、アクセスの仕方に応じて認証方法を違えるのは、このアプローチでは限界がある。 実はすでに本件に関しては、@takepara さんがブログに記事を投稿されている。 ApiControllerで認証する際にログインページにリダイレクトしたくない http://takepara.blogspot.com/2012/03/apicontroller.html @takepara さんの作戦では、やはり何かしらの ASP.NET HTTP Module を実装するということになるのだが、その HTTP Module の実装において、要求処理完了時の通知を捕まえ、 1. 認証されていない、かつ、 2. 要求が API のアクセスである、かつ、 3. ログインページへのリダイレクトである 場合に、HTTP 401 Unauthorization を返すよう、FormsAuthenticationModule の処理結果を上書きするようになっている。 この作戦であれば、 a) 人が Web ブラウザを使ってページを開くときには Forms 認証が機能、 b) そうではない何かしらのアプリケーションが API への直アクセスをしたときには HTTP 401 Unauthorized が返る というように、ちゃんと仕分けされるようになる。 なお、@takepara さんのブログ記事では、API に直アクセスするアプリケーションがどのように認証をするのか、というところまでは具体論はだされていない。 とはいえ、HTTP 401 を返すところで HTTP 応答ヘッダにいくつか加えれば、ブラウザに対する基本認証の要求を発動することができるし、とにかく重要なポイントは十二分に示唆されている。 Forms 認証にまかせるかどうかの判定方法についても、現在の要求のハンドラの型を見るやり方の他、Twitter 上ではMVC コントローラに対するフィルタにて、要求コンテキストに対して何かしらのフラグを立てる方法についても言及されている。 https://twitter.com/#!/takepara/status/175748244490563586 この投稿を読まれた方は、@takepara さんのブログ記事は是非ご一読を。 ということで、この投稿では、認証方式を場合や状況に応じて仕分けるところまでは完成に至っていない。 とはいえ、ゴールにたどり着くまでの重要なヒントはいくつか示唆できたのではないかと思う。 ご意見・ご質問は、この投稿にコメント頂くか、@jsakamoto までどうぞ。
by developer-adjust
| 2012-03-04 22:44
| .NET
|
Comments(0)
|
ファン申請 |
||