WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

パラメータ化の副次的な効用

by WebSurfer 2016年6月4日 15:12

パラメータ化クエリを使用するというセキュリティ対策として普通にやるべきことをやっていれば、照合順序の違いによる文字化けに悩むことはなさそうという話を書きます。

元は MSDN Forum の「nvarcharに日本語を入力すると?????????になる」という表題のスレッドでの話です。

上の MSDN Forum のスレッドの問題は、簡単に書くと、SQL Azure の照合順序のデフォルトは SQL_Latin1_General_CP1_CI_AS となっていて、それに例えば以下のように 'あいうえお' というように N プレフィックスをつけないリテラルを INSERT すると文字化けするという話です。

INSERT INTO [Table] ([Name]) VALUES ('あいうえお')

(何故文字化けするかは MSDN Blog の記事「Unicode型列(NCHAR/NVARCHAR) に格納されるデータが “?” になる」に説明されていますので、そちらを見てください。手抜きでスミマセン)

クエリをパラメータ化して ADO.NET + SqlClient 経由で INSERT, UPDATE をかければ、照合順序が Japanese_CI_AS(デフォルト)でも SQL_Latin1_General_CP1_CI_AS(SQL Azure のデフォルトらしい)でも文字化けはしません。

パラメータ化あり / なしでどう違うかの例を以下に書きます。

まず、サンプルとして SQL Server 2008 Express に照合順序が SQL_Latin1_General_CP1_CI_AS のデータベースを作りました。以下の画像の通りです。

照合順序

それに以下のコードで INSERT してみます。上のクエリがパラメータ化なし、下のクエリがパラメータ化ありです。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Data.SqlClient;

namespace ConsoleApplication
{
  class Program
  {
    static void Main(string[] args)
    {
      string connString = @"接続文字列";

      using(SqlConnection conn = new SqlConnection(connString))
      {
        conn.Open();
        string query = 
          "INSERT INTO [Table] ([Name]) VALUES ('あいうえお')";
        using(SqlCommand cmd = new SqlCommand(query, conn))
        {
          cmd.ExecuteNonQuery();
        }

        query ="INSERT INTO [Table] ([Name]) VALUES (@Name)";
        using(SqlCommand cmd = new SqlCommand(query, conn))
        {
          cmd.Parameters.Add(
            new SqlParameter("@Name", SqlDbType.NVarChar, 50));
          cmd.Parameters["@Name"].Value = "かきくけこ";
          cmd.ExecuteNonQuery();
        }
      } 
    }
  }
}

結果は以下の通りです。赤枠で囲ったものがパラメータ化なし、青枠で囲ったものがパラメータ化ありです。

INSERT 結果

何故パラメータ化クエリを使うと文字化けの問題がなくなるのかと言うと、TechNet の記事「第 4 回 アドホック クエリのパラメータ化」の下の方に書いてあるように "SqlParameter クラスを利用すると、内部的には sp_executesql に変換されて実行されるようになり"、 その際以下のように N プレフィックスが付与されるからです。

exec sp_executesql 
    N'INSERT INTO [Table] ([Name]) VALUES (@Name)',
    N'@Name nvarchar(5)',
    @Name=N'かきくけこ'

というわけで、クエリをパラメータ化して ADO.NET + SqlClient を使えば(普通のやり方をしていれば)、照合順序の違いによって文字化けに悩むことはなさそうです。

Tags: ,

ADO.NET

ASP.NET と Roslyn コンパイラの問題

by WebSurfer 2016年5月10日 17:03

Roslyn というのは Visual Studio 2015 に採用された次世代コンパイラだそうです。

ASP.NET Web アプリの場合 Web サーバーで動的にコンパイルが行われるので Roslyn の採用によってそれがうまく行かないケース(例: Trust Level が Medium のホスティングサービスを利用している)があるということを書きます。

元は MSDN Forum の「ASP.NET MVCのサイトがサーバーで実行できない問題」という表題のスレッドでの話です。

Visual Studio のデフォルト設定では、先の記事「コンパイル済みアセンブリの保存場所」で書きましたように、Web サイトプロジェクトでは全てのファイルを、Web アプリケーションプロジェクトでも一部のファイルをサーバーで動的にアセンブリにコンパイルします。

上に紹介した MSDN Forum の記事は Roslyn を使って Web サーバーで動的にコンパイルするところで問題が出たという話です。要約すると以下の通りです。

  1. VS2015 で ASP.NET MVC 5 の Web アプリケーションプロジェクトを新規作成。
  2. Roslyn コンパイラ関係の NuGet が 2 つ自動的にインストールされる。
    Microsoft.CodeDom.Providers.DotNetCompilerPlatform
    Microsoft.Net.Compilers
  3. その際、Web アプリの bin フォルダに roslyn というサブフォルダが生成され、その中に csc.exe という Roslyn コンパイラが配置される。
  4. さらに Web アプリの web.config に <system.codedom> 要素が生成され、サーバー側での動的コンパイルに上記 3 の Roslyn コンパイラを使うよう設定される。(注:ASP.NET MVC の場合は View を動的にコンパイルします)
  5. 記事を書いた人の運用サーバーでは上記 3 のコンパイラの実行権限がなく View のコンパイルに失敗する。
  6. NuGet をアンインストールすれば上記 4 の設定がなくなって上記 3 のコンパイラを使わないので問題が起きない。(C:\Windows\Microsoft.NET\Framework\v4.0.30319 フォルダの csc.exe を使うと思われます・・・が未確認です)

対症療法的な解決策は上に書いた NuGet 2 つをアンインストールして Roslyn コンパイラを使わないということですが、Roslyn を使う場合は以下のいずれかの対応を取ることになります。

  1. Visual Studio 側で View を含めて全てのファイルをコンパイルしてアセンブリを作成しそれをデプロイする。サーバー側での動的コンパイルは不要にする。または、
  2. IIS で当該アプリをホストとしているワーカープロセスに bin/roslyn フォルダの csc.exe の実行権限を与える。

上記 1 ですが、Visual Studio のデフォルトではサーバー側でコンパイルする設定になっていますのでその変更が必要です。具体的には、MSDN ライブラリの記事 Advanced Precompile Settings Dialog Box の画像にあるように [Allow precompiled site to be updatable] にデフォルトでチェックが入っていますので、そのチェックを外します。

ただし、そうするとサーバーにデプロイした後で、View のみ(ASP.NET Web Forms アプリの場合は.aspx, .ascx のみ)差し替えるということができなくなってしまいます。(View をちょっとだけ変更しても、開発環境で全ファイルを再コンパイルして再発行することになります)

それが気に入らない場合は上記 2 の方法を取るということになりますが、そもそもが Web サーバーで .exe ファイルの実行が制限されていることからこの問題にぶつかることが多いようですので、難しいかもしれません。

Tags: ,

ASP.NET

Web API で AuthorizationFilter 実装

by WebSurfer 2016年4月10日 14:39

MSDN Forum の「ASP.net MVC5 WEB APIのキャンセル(特定のデータの返却)する方法はありますか?」という表題のスレッドでの話です。

[クライアント]⇒[閲覧用ページ]⇒[Web API]⇒[DB サーバー]

という構成で、(1) [Web API]が要求を受けたらそこで時間外か否かを判断し、(2) 時間外であれば[Web API]のアクションメソッドは実行せず、(3) [閲覧用ページ]に時間外メッセージと遷移先の URL を応答として返し、(4) [閲覧用ページ]は応答の内容をチェックして時間外であれば遷移先に指定された URL に JavScript で遷移する・・・という方法を考えてみます。

もちろん時間外でなければ、上記で、(2)[Web API]でアクションメソッドを実行し、(3) 通常の応答を[閲覧用ページ]に返し、(4)[閲覧用ページ]は応答を処理して表示するということになります。

それを実現するためには、[Web API]において以下のような AuthorizationFilterAttribute を継承したフィルターを作って、OnAuthorization メソッドを override し、そこでアクションメソッドが実行される前に時間外か否かをチェックし、時間外であればその旨メッセージを返すようにします。(以下のコードは既存のコードを流用したため日付の範囲で制限してます)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Net.Http;
using System.Web.Http.Filters;
using System.Web.Http.Controllers;

namespace WebApi1.Filters
{
  [AttributeUsage(
       AttributeTargets.Method | AttributeTargets.Class,
       Inherited = true, AllowMultiple = false)]
  public class TimeLimitAttribute : AuthorizationFilterAttribute
  {
    public TimeLimitAttribute(string dateBegin, string dateEnd)
    {
      this.Begin = dateBegin;
      this.End = dateEnd;
    }
        
    private DateTime _begin = DateTime.MinValue;
    private DateTime _end = DateTime.MaxValue;

    public string Begin
    {
      set
      {
        DateTime dateSet = DateTime.Parse(value);                
        if (dateSet >= this._end)
        {
          throw new ArgumentException("開始日設定エラー");
        }
        this._begin = dateSet;
      }            
    }

    public string End
    {
      set
      {
        DateTime dateSet = DateTime.Parse(value);
        if (dateSet <= this._begin)
        {
          throw new ArgumentException("終了日設定エラー");
        }
          this._end = dateSet;
      }
    }

    public override void OnAuthorization(
                      HttpActionContext actionContext)
    {
      if (actionContext == null)
      {
        throw new ArgumentNullException("context が null");
      }

      DateTime current = DateTime.Now;
      if (current < this._begin || current > this._end)
      {

        HttpResponseMessage response = 
            new HttpResponseMessage();
        response.Content = 
            new StringContent("時間外,<リダイレクト先 URL>");
        actionContext.Response = response;
      }

      base.OnAuthorization(actionContext);
    }        
  }
}

ASP.NET MVC 用と ASP.NET Web API 用とでは Filter は違うそうなので注意してください。詳しくは記事「Web API における操作ごとの制御 (Validation, 認証/権限, Exception 処理 など)」を見てください。

上のフィルター属性を ApiController のクラスに付与することで制限がかけられます。たとえば、以下のようにフィルター属性を付与すれば、2013/12/1 ~ 2013/12/31 以外の日時にアクセスした場合、"時間外,<リダイレクト先 URL>" という文字列が[Web API]から応答として返ってきます。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;
using WebApi1.Models;

namespace WebApi1.Controllers
{
    [WebApi1.Filters.TimeLimit("2013/12/1", "2013/12/31")]
    public class HeroesController : ApiController
    {
        private List<Hero> heroes = new List<Hero> {
              new Hero {Id = 1, Name = "スーパーマン"},
              new Hero {Id = 2, Name = "バットマン"},
              new Hero {Id = 3, Name = "ウェブマトリクスマン"},
              new Hero {Id = 4, Name = "チャッカマン"},
              new Hero {Id = 5, Name = "スライムマン"}
          };
                
        public IEnumerable<Hero> Get()
        {
            return heroes;
        }

        public Hero Get(int id)
        {
            return heroes[id - 1];
        }

        //・・・中略・・・
    }
} 

それを[閲覧用ページ]で jQuery.Ajax + JavaScript を使って、例えば上のアクションメソッドの public IEnumerable<Hero> Get() を呼んだ場合は以下のようの処置すれば、時間外であれば[Web API]からの応答に含まれる <リダイレクト先 URL> にリダイレクトされます。

function apiHeroesGet() {
    $.ajax({
        type: "GET",
        url: "api/heroes",
        contentType: "application/json; charset=utf-8",
        success: function (data, textStatus, jqXHR) {
            if (typeof(data) == "string" && 
                data.indexOf("時間外") == 0) {
                // 時間外の場合はリダイレクト
                var results = data.split(",");
                window.location.href = results[1];
            }
            else {
                // 時間内の場合の処置(省略)
            }
        },
        error: function (jqXHR, textStatus, errorThrown) {
            // エラーの場合の処置(省略)
        }
    });
}

Tags: ,

Web API

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年4月  >>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar