WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

WCF と jQuery AJAX

by WebSurfer 15. October 2015 21:01

Web サービスは "Legacy Technology" なので Windows Communication Foundation (WCF) を使うようにと言われています。なので、今さらながらですが、先の記事 jQuery AJAX と Web サービスで作ったサンプルと同様なものを WCF で実装してみました。

AJAX 対応 WCF サービス

作成に当たって参考にしたのは以下の 2 つの記事です。しかし、読んだだけではほとんど意味が分かりません。(汗)

自分の手を動かして作ってみれば少しは理解が深まるであろうということで、自分の環境(Vista SP2 32-bit の IIS7、ASP.NET 4, Visual Studio 2010 Professional、ASP.NET Web Forms アプリ)で実際にやってみました。やってみていろいろ分かったことがありましたので備忘録として書いておきます。

まず、開発マシンの IIS7 上で動く既存の ASP.NET Web Forms アプリに、上の画像のように Visual Studio の[新しい項目の追加(W)...]メニューからテンプレートを使って[AJAX 対応 WCF サービス]を CarService.svc という名前で追加します。([WCF サービス]の方は従来の SOAP を使う WCF サービス)

CarService.svc を追加すると以下のコードが自動生成されます。今回の記事では Web アプリケーションプロジェクトを使っています。Web サイトプロジェクトの場合は、コードビハンド CarService.svc.cs が CarService.cs という名前になって App_Code フォルダに置かれる、アセンブリ名 / 名前空間名が付与されないという違いがありますので注意してください。

CarService.svc(xxx は名前空間名)

<%@ ServiceHost
  Language="C#"
  Debug="true"
  Service="xxx.CarService"
  CodeBehind="CarService.svc.cs"
%>

CarService.svc.cs(xxx は名前空間名)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Web;
using System.Text;

namespace xxx
{
  [ServiceContract(Namespace = "")]
  [AspNetCompatibilityRequirements(RequirementsMode = 
                AspNetCompatibilityRequirementsMode.Allowed)]
  public class CarService
  {
    // HTTP GET を使用するために [WebGet] 属性を追加します 
    // (既定の ResponseFormat は WebMessageFormat.Json)。
    // XML を返す操作を作成するには、
    // [WebGet(ResponseFormat=WebMessageFormat.Xml)] を追加し、
    // 操作本文に次の行を含めます。
    // WebOperationContext.Current.OutgoingResponse.ContentType = 
    //     "text/xml";
    [OperationContract]
    public void DoWork()
    {
      // 操作の実装をここに追加してください
      return;
    }

    // 追加の操作をここに追加して、[OperationContract] とマーク
    // してください
  }
}

web.config への追加(xxx は名前空間名)

<system.serviceModel>
  <behaviors>
    <endpointBehaviors>
      <behavior name="xxx.CarServiceAspNetAjaxBehavior">
        <enableWebScript />
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
    multipleSiteBindingsEnabled="true" />
  <services>
    <service name="xxx.CarService">
      <endpoint address=""
        behaviorConfiguration="xxx.CarServiceAspNetAjaxBehavior"
        binding="webHttpBinding"
        contract="xxx.CarService" />
    </service>
  </services>
</system.serviceModel>

上記は、web.config に <enableWebScript /> とあることから分かるように、ASP.NET AJAX の ScriptManager を使用する Web ページからサービスを使用するための WCF AJAX サービスのコードです。

これらのコードを、上の 2 つの記事を参考に、JavaScript / jQuery を使用する Web ページからアクセスできるように書き換えてみました。

上に紹介した ASP.NET を使用せずに WCF AJAX サービスを作成する方法 に書いてあるように、以下の 3 つの手順に分けて説明します。

(1) ブラウザーからアクセスできる AJAX エンドポイントの作成
(2) AJAX 互換サービス コントラクトの作成
(3) WCF AJAX サービスへのアクセス


(1) ブラウザーからアクセスできる AJAX エンドポイントの作成

AJAX エンドポイントを作成するためには、

  1. .svc ファイルの @ServiceHost の Factory 属性に WebServiceHostFactory を設定する、または
  2. web.config の <system.serviceModel> 要素で WebHttpBinding と WebHttpBehavior を使用してエンドポイントを構成する

のいずれかの方法を取るのだそうです。具体例は上の記事(前者)のサンプルコードを参照してください。

1 の方が簡単そうに思えますが、実は 2 の方は web.config に自動生成されて追加されたコード(上のコードを見てください)の中の <enableWebScript /> を <webHttp /> に書き換えるだけで済みますので、手間的には大差はないです。

今回は 2 の方法(.svc ファイルには手を加えないで、web.config に自動生成されたコードの中の <enableWebScript /> を <webHttp /> に書き換え)を取りました。

エンドポイントアドレス名を指定してサービスを呼び出したい場合は、自動生成された address="" を修正してください。例えば、address="ajaxEndpoint" とすると、carservice.svc/ajaxEndpoint/GetAllCars でアクセスできます。(ちなみに、そのように address を設定すると、carservice.svc/GetAllCars では HTTP 404 Not Found になります)

1 の方法を取る場合、web.config に自動生成されたコードは削除した方がよさそうです。<enableWebScript /> を <webHttp /> に書き換えれば WebScriptEnablingBehavior では BodyStyle の Wrapped がサポートされてない等の問題は回避できますが、既存のサービスなどと競合してエラーになることがありましたので。


(2) AJAX 互換サービス コントラクトの作成

先の記事 ASP.NET AJAX と Web サービスの Web サービス(.asmx ファイル)のコードを CarService.svc.cs に移植します。

GetAllCars は GET 要求で呼び出せるようにしました。(JSON サービスを GET で要求するのは潜在的なセキュリティ上のリスクがあるそうです。詳しくはこのセクションの下の方で紹介した記事を見てください)

GetCarsByDoors は先の例と同様に POST 要求で呼び出すようにしました。サンプルコードは以下のようになります。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Web;
using System.Text;

namespace WebApplication1
{
    // web.config で aspNetCompatibilityEnabled="true" と設定され
    // ているので [AspNetCompatibilityRequirements(...)] が必要
    [ServiceContract(Namespace = "")]
    [AspNetCompatibilityRequirements(RequirementsMode = 
        AspNetCompatibilityRequirementsMode.Allowed)]
    public class CarService
    {
        List<Car> cars = new List<Car> {
            new Car {Make="Audi",Model="A4",Year=1995,
                Doors=5,Colour="Red",Price=2995f},
            new Car {Make="Ford",Model="Focus",Year=2002,
                Doors=5,Colour="Black",Price=3250f},
            new Car {Make="BMW",Model="5 Series",Year=2006,
                Doors=4,Colour="Grey",Price=24950f},
            new Car {Make="Renault",Model="Laguna",Year=2000,
                Doors=5,Colour="Red",Price=3995f},
            new Car {Make="Toyota",Model="Previa",Year=1998,
                Doors=5,Colour="Green",Price=2695f},
            new Car {Make="Mini",Model="Cooper",Year=2005,
                Doors=2,Colour="Grey",Price=9850f},
            new Car {Make="Mazda",Model="MX 5",Year=2003,
                Doors=2,Colour="Silver",Price=6995f},
            new Car {Make="Ford",Model="Fiesta",Year=2004,
                Doors=3,Colour="Red",Price=3759f},
            new Car {Make="Honda",Model="Accord",Year=1997,
                Doors=4,Colour="Silver",Price=1995f}
        };

        [OperationContract]
        [WebGet(ResponseFormat = WebMessageFormat.Json, 
            BodyStyle = WebMessageBodyStyle.Wrapped)]
        public List<Car> GetAllCars()
        {
            return cars;
        }

        [OperationContract]
        [WebInvoke(ResponseFormat = WebMessageFormat.Json, 
            BodyStyle = WebMessageBodyStyle.Wrapped)]
        public List<Car> GetCarsByDoors(int doors)
        {
            var query = from c in cars
                        where c.Doors == doors
                        select c;

            return query.ToList();
        }
    }

    [DataContract]
    public class Car
    {
        [DataMember]
        public string Make { get; set; }

        [DataMember]
        public string Model { get; set; }

        [DataMember]
        public int Year { get; set; }

        [DataMember]
        public int Doors { get; set; }

        [DataMember]
        public string Colour { get; set; }

        [DataMember]
        public float Price { get; set; }
    }
}

ポイントは WebGetAttribute 属性と WebInvokeAttribute 属性の設定で、具体的には以下の通りです。

  • ResponseFormat = WebMessageFormat.Json を設定して、応答に XML ではなく JSON を明示的に指定します。
  • 上に紹介した記事(後者)には "WebGetAttribute または WebInvokeAttribute 属性に Wrapped の本文スタイルが必要です" とありますが、その通りにすると応答もラップされて {"GetAllCarsResult":[{"Colour":"Red", ... ,"Year":1997}]} というような形になります。
  • BodyStyle = WebMessageBodyStyle.Wrapped を削除すると "GetAllCarsResult" というラップはなくなりますが、今度は POST 要求で HTTP 400 Bad Request となってしまいます。なので、少なくとも POST 要求する方は BodyStyle = WebMessageBodyStyle.WrappedRequest とする必要があります。

今回は記事に従って BodyStyle = WebMessageBodyStyle.Wrapped とし、ラップを外す処置をクライアントスクリプトにコーディングしました。具体的には、下の「(3) WCF AJAX サービスへのアクセス」のセクションを見てください。

ラップすると、Web サービスの JSON 応答を "d" でラップするのと同様に、セキュリティ上のリスクの軽減に効果があるはずです。

Web サービスの JSON 応答は .NET 3.5 から "d" でラップされるようになりましたが、それは JSON サービスの脆弱性に起因する XSS 対策だそうです。そのメカニズムは以下の記事に詳しく書いてあります。

WCF では "<メソッド名>Result" でラップされますが、Web サービスで "d" でラップするのと同様に JSON 配列を返さないという効果があります。(JSON 配列は JavaScript として有効というところが問題だそうです)

あと、上に紹介した記事に書いてありますが、GET 要求を使うことにもリスクがあるそうです。

いろいろ条件が重ならないとリスクにはならないですが、「君子危うきに近寄らず」ということで、(1) ラップする、(2) POST 要求を使う、という 2 つのことは実施した方がよさそうです。(ちなみに、ASP.NET AJAX を利用する場合はデフォルトでそうなります)


(3) WCF AJAX サービスへのアクセス

これは先の記事 jQuery AJAX と Web サービス とほぼ同様な jQuery.ajax のコードを利用して可能です。

上記 (2) の手順で、GetAllCars は GET 要求で、GetCarsByDoors は POST 要求で取得するようにしたので、それぞれ以下のようなコードで要求をかけ、JSON 文字列の応答を得てそれを処置することができます。

function getAllCars() {
    $.ajax({
        type: "GET",
        url: "carservice.svc/GetAllCars",
                
        success: function (cars) {
            if (cars.hasOwnProperty('GetAllCarsResult')) {
                cars = cars.GetAllCarsResult;

                // ・・・cars の処置(省略)・・・
            }
        },
        error: function (jqXHR, textStatus, errorThrown) {
            // ・・・省略・・・
        }
    });
}
        
function getCarsByDoors() {
    $.ajax({
        type: "POST",
        url: "carservice.svc/GetCarsByDoors",
        data: '{"doors":' + $("#ddlDoors").val() + '}',
        contentType: "application/json; charset=utf-8",

        success: function (cars) {
            if (cars.hasOwnProperty('GetCarsByDoorsResult')) {
                cars = cars.GetCarsByDoorsResult;

                // ・・・cars の処置(省略)・・・
            }
        },
        error: function (jqXHR, textStatus, errorThrown) {
            // ・・・省略・・・
        }
    });                
}

POST の方には contentType: "application/json; charset=utf-8" の設定は必須です。それがないと HTTP 400 Bad Request となって失敗します。

success オプションに設定したコールバックの引数 cars にはパース済みの JavaScript オブジェクトが渡されます。上の「(2) AJAX 互換サービス コントラクトの作成」のセクションで述べたように "<メソッド名>Result" でラップされていますので、ラップを外す処置が必要です。具体的には上のコードを見てください。(命名規則が不明なので、ラップを外す処置をハードコーディングするのはちょっと不安なのですが)

Tags: , ,

AJAX

jQuery.ajax の data の型

by WebSurfer 5. October 2015 14:38

jQuery.ajax を利用してデータをサーバーに送信するには、以下のような形で data オプションに送信するデータを設定しますが、そのデータ(下のコードで言うと jsonString)の型は何にすべきかという話を書きます。

function apiHeroesPost() {
    $.ajax({
        type: "POST",
        url: "api/heroes",
        data: jsonString,
        contentType: "application/json; charset=utf-8",
        success: function (data) {
            // ・・・省略・・・
        },
        error: function (jqXHR, textStatus, errorThrown) {
            // ・・・省略・・・
        }
    });
}

答を先に書くと、

  1. GET 要求(クエリ文字列としてデータを送信)の場合は JavaScript オブジェクト
  2. POST 要求(コンテンツとしてデータを送信)の場合、(a) 受け取る側が application/x-www-form-urlencoded 形式を期待している場合は JavaScript オブジェクト、(b) ASP.NET Web API のように JSON 文字列を期待している場合は JSON 文字列

を data オプションに設定します。上のコードは POST 要求で「(b) ASP.NET Web API のように JSON 文字列を期待している」場合です。以下、POST 要求については (b) を前提に書きます。

jQuery の API Dcoumentation の説明によると、設定できる型は PlainObject or String or Array となっていますが、どれでもいいという訳ではありません。

その説明にある "It is converted to a query string, if not already a string. It's appended to the url for GET-requests." というところがポイントです。

具体的には、例えば、processData は設定しない(デフォルトの true)という条件で、

var j = { Id: 5, Name: "日本語" };  // j はオブジェクト
var jsonString = JSON.stringify(j); // jsonString は文字列

とした場合、GET 要求なら data:j とし、POST 要求なら data:jsonString とします。

data:j とすると j は application/x-www-form-urlencoded 形式に変換されて Id=5&Name=%E6%97%A5%E6%9C%AC%E8%AA%9E となり、GET 要求の際 URL にクエリ文字列として追加されます。(%E6%97%A5 ... %AA%9E は "日本語" の UTF-8 パーセントエンコーディング)

しかし、data:jsonString とすると、文字列は無変換なので、GET 要求の際そのままクエリ文字列として URL に追加されます。下の画像は Fiddler2 による GET 要求のキャプチャです。反転表示した部分を見てください。クエリ文字列が {"Id":5,"Name":"日本語"} となってるのが分かるでしょうか? (ブラウザに依存すると思いますが、IE9 では "日本語" は Shift_JIS になり、下の画像では 22 93 FA 96 7B 8C EA 22 というバイト列になっています)

不正なクエリ文字列

POST 要求の場合も、data の変換の仕方は同じ(オブジェクトはクエリ文字列形式に変換、文字列は無変換)になります。しかし、POST 要求はコンテンツとしてデータを送信しますので、GET 要求と違って data:j(j はオブジェクト)ではダメです。

data:jsonString として文字列を設定すればそのまま UTF-8 コードのコンテンツとして送信されますので、jsonString が有効な JSON 文字列なら期待通りの結果が得られるはずです。(注:contentType: "application/json; charset=utf-8" が前提です)

たぶん普通は、GET と POST の使い分けは以下のようにする(参考:jQuery - AJAX get() and post() Methods)と思います。

  • GET - Requests data from a specified resource
  • POST - Submits data to be processed to a specified resource

なので、データを送信する際は POST 要求、jQuery.ajax の data には JSON 文字列を設定ということしか頭になかったです。それでちょっとハマってしまったので、備忘録として残しておくことにしました。

Tags: ,

AJAX

MVC は maxJsonLength を無視

by WebSurfer 7. August 2013 13:32

Ajax を使用する際、クライアントとサーバー間でやり取りするデータには JSON (JavaScript Object Notation) 形式の UTF-8 文字列を使うのがデファクトスタンダードになっています。

ASP.NET Web Forms アプリケーションで Ajax を使って Web サービスと通信を行う場合も、先の記事 ASP.NET AJAX と Web サービスjQuery AJAX と Web サービス でも書きましたように、データのやり取りには JSON 形式の文字列を使っています。

クライアントからサーバーへ送信できる JSON 文字列の長さは、セキュリティ対策のため、デフォルトで 102,400 文字に制限されています。この値は、web.config の jsonSerialization 要素 (ASP.NET 設定スキーマ) の設定によって変更できます。以下のような感じです。

<system.web.extensions>
    <scripting>
        <webServices>
            <jsonSerialization maxJsonLength="3000000"/>
        </webServices>
    </scripting>
</system.web.extensions>

上の maxJsonLength 要素の設定により、JSON 文字列のデシリアライズに使用されている(と思われる)JavaScriptSerializer クラスの MaxJsonLength プロパティの設定が書き換えられるようで、デフォルト値の 2,097,152 文字を超えて JSON 文字列を送信することも可能です。(どこまで可能かは未検証ですが、2,097,152 文字を超えて可能なのは ASP.NET 4 Web Forms および MVC3 で確認しました)

ところが、呼び出す相手が Web サービスのメソッドでなく、MVC のアクションメソッドの場合、web.config の maxJsonLength 要素の設定は無視され、文字数制限は JavaScriptSerializerクラスの MaxJsonLength プロパティのデフォルト値 2,097,152 文字となります。

このあたりは、いろいろググって調べている時に、stackoverflow の記事 Can I set an unlimited length for maxJsonLength in web.config? を見つけて分かりました。そのページの Answers の 2 つ目に書いてあります。

いろいろ調べましたが、クライアントからサーバーに送信される JSON 文字列の長さ制限を変更する方法は見つかりませんでした。JavaScriptSerializer クラスの MaxJsonLength プロパティのデフォルト値 2,097,152 文字で固定となってしまいます。

ただし、逆方向のサーバーからクライアントに送信される JSON 文字列の長さ制限(MaxJsonLength プロパティのデフォルト値 2,097,152 文字)を緩和するための workaround はあります。詳しくは、上に紹介した stackoverflow のページに書いてありますので見てください。

クライアントからサーバーに送信する JSON データの文字数の制限を変更する方法はないか調べているときにわかったこと(何故変更できないか)を以下に書いておきます。

MVC のアクションメソッドを呼び出す場合、2,097,152 文字を超えてクライアントからサーバーにJSON データを送信すると「ArgumentException: JSON JavaScriptSerializer を使用したシリアル化または逆シリアル化中にエラーが発生しました。文字列の長さが maxJsonLength プロパティで設定されている値を超えています。」というエラーとなります。

スタックトレースを見ると JavaScriptSerializer クラスの DeserializeObject メソッドで JSON 文字列を受け取って、それデシリアライズするときに例外(ArgumentException・・・その条件の一つが「input の長さが MaxJsonLength の値を超えています。」)が発生したことが分かります。

さらに、スタックトレースから、そのメソッドは JsonValueProviderFactory クラスの GetDeserializedObject メソッドで使われているのが分かります。CodePlex のサイトで、その ソースコード を調べたら以下のようになっていました。

private static object GetDeserializedObject(
                    ControllerContext controllerContext)
{
  if (!controllerContext.HttpContext.Request.
          ContentType.StartsWith("application/json", 
                       StringComparison.OrdinalIgnoreCase))
  {
    // not JSON request
    return null;
  }

  StreamReader reader = new StreamReader(
        controllerContext.HttpContext.Request.InputStream);
  string bodyText = reader.ReadToEnd();
  if (String.IsNullOrEmpty(bodyText))
  {
    // no JSON data
    return null;
  }

  JavaScriptSerializer serializer = new JavaScriptSerializer();
  object jsonData = serializer.DeserializeObject(bodyText);
  return jsonData;
} 

上のコードの通り、GetDeserializedObject メソッドで使われている JavaScriptSerializer オブジェクトの MaxJsonLength プロパティの設定を変更する手段はないので、MVC のアクションメソッドを呼び出している限りは制限を 2,097,152 文字を超えて設定する手段はなさそうです。

どうしても 2,097,152 文字を超えて設定する必要があれば(実際、そんな必要があるのか分かりませんが)、アクションメソッドではなく、web サービス(.asmx)を作ってそのメソッドを呼び出すようにして、web.config の maxRequestLength 要素を 2,097,152 文字を超えた値に設定することで対応が可能です。

aspnet:MaxJsonDeserializerMembers について

上記の JSON 文字数の制限に加えて、2011 年 12 月 30 日に公開されたセキュリティ更新プログラム MS11-100 で HTTP 要求内の JSON メンバーの最大数がデフォルトで 1,000 に制限されるようになりました。

この 1,000 という数は、クライアントからサーバーに送信される JSON オブジェクト内の key:value アイテムの総数です。

デフォルト値 1,000 の変更は、web.config の ASP.NET appSettings 要素で aspnet:MaxJsonDeserializerMembers キーを設定することで可能です。

この制限を越えると JsonValueProviderFactory の EntryLimitedDictionary.Add メソッドで InvalidOperationException がスローされます。

ちなみにエラーメッセージは「InvalidOperationException: JSON リクエストが大きすぎるため、逆シリアル化できませんでした。」となります。

なお、web サービス(.asmx)のメソッドにも aspnet:MaxJsonDeserializerMembers による制限が有効かどうかは未確認です。

Tags: , ,

MVC

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  June 2021  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar