@jsakamoto

タグ：ASP.NET Core ( 12 ) タグの人気記事

ASP.NET Core で静的ファイルを認証で保護する

[ 2020-05 -27 21:59 ]
Twitter 認証を実装した ASP.NET Core 3.1 Web アプリで、Twitter 認証時にキャンセルをしたら、アプリがクラッシュした件

[ 2020-02 -17 19:04 ]
Entity Framework Core でデータベースを読み書きする ASP.NET Core アプリ開発中に、発行される SQL 文字列を確認する

[ 2019-08 -29 21:11 ]
ASP.NET Core での単体テスト内で、オプションおよびサービスプロバイダを作成する

[ 2019-07 -06 23:02 ]
ASP.NET Core Web アプリプロジェクトで、Node.js 使わずに Sass (SCSS) をコンパイルする

[ 2019-02 -26 22:01 ]
ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする

[ 2018-12 -28 22:37 ]
ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション

[ 2018-09 -28 23:29 ]
ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?

[ 2018-06 -29 19:02 ]
ASP.NET Core SignalR - サーバー側で配列を渡して InvokeAsync しても、JavaScript 側で第1要素しか受け取れない?

[ 2018-02 -27 12:39 ]
ASP.NET Core SignalR v.1.0 Preview2 Final で Web API のアクションメソッド内など任意の箇所からクライアントにプッシュ送信する方法

[ 2017-10 -30 22:29 ]
ASP.NET Core 2.0 の Razor Pages を markdown 構文で書く

[ 2017-09 -22 21:54 ]
ASP.NET Core 1.0 のアプリケーション構成 (オプション) を動的に読み取る

[ 2016-05 -31 22:47 ]

▽ このタグの記事をすべて表示

12次へ >>>

2020年 05月 27日

ASP.NET Core で静的ファイルを認証で保護する

"Microsoft Docs" サイトに記載のやり方は好きになれず...

C# 等による Web アプリ開発フレームワーク "ASP.NET Core" を用いた、サーバー側実装での話。

数週間ほど前から、新しい ASP.NET Core Web アプリ開発の案件が始まった。

この案件では、この Web アプリ上に配置される静的ファイルの一部を認証で保護、すなわち匿名アクセスは拒否する要件があった。

実のところ、ASP.NET Core 上に配置された静的ファイルを認証で保護する方法についてはわかっていなかった。

そこで、インターネット上で "protect static files, authorization, asp.net core" といったキーワードで検索するところから始めた。

相当数の検索結果がヒットしたが、その多くは "stackoverflow.com" に投稿された質問とその回答だ。

それらの回答は、以下のいずれかの解決策を提案しているケースが多かった。

(A) 自分で ASP.NET Core ミドルウェアのカスタム実装を作り、静的ファイルミドルウェアより前の HTTP 処理パイプラインにそのミドルウェアを差し込み、認証されていない要求をそのミドルウェアで拒否する。
(B) 保護したい静的ファイルを "wwwroot" フォルダの外部に配置し、代わりに、[Authorized] 属性付きの自作の ASP.NET Core MVC コントローラでその保護したい静的ファイルを応答で返すようにする。

特に上記解決策のうち (B) については、下記 URL の "Microsoft Docs" サイトでも公式に説明が掲載されている。

しかしながら、詳細はここでは割愛するが、今回案件特有の要件や背景事情をはじめ、いくつかの要因から、上記解決策 (A) (B) はちょっと採用したくなかった。

そこでもう暫し検索結果を読み進めた結果、幸いなことに、「これはよさそう!」と思われる解決案を stackoverflow.com 内で発見した。

その解決策とは、

「静的ファイルミドルウェアが提供している、"OnPrepareResponse" というコールバックポイントをフックする」

という方法だ。

ASP.NET Core 静的ファイルミドルウェアが提供しているフックポイント

静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき、すなわち Statrtup クラスの Configure メソッド内で UseStaticFiles() メソッドを呼び出すときだが、この際、StaticFileOptions 型のオプション指定をその引数に渡すことができる。

この　StaticFileOptions クラスに、静的ファイルを処理する直前に自前の処理を差し込みすることができる、あつらえたプロパティが用意されていたのだ。

そのプロパティの名前は OnPrepareResponse。

この OnPrepareResponse プロパティに自前の関数を設定すると、静的ファイルをブラウザに返す直前に、この設定した関数を呼び出してくれるのだ。

この自前の関数内で、要求が認証済みであるか否かに応じて、ブラウザへの応答を変更できる。

早速に、"stackoverflow.com" の下記回答にあるサンプルコードをコピーしてきて試してみた。

なお、もちろんのこと、認証ミドルウェアが静的ファイルミドルウェアよりも先に HTTP 処理パイプラインに登録されている必要がある。静的ファイルミドルウェアが要求を処理するより前に、認証済みであるか否かを判定済みにしておく必要があるからだ。

ということで自分のサンプルコードは下記のようになった。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  ...
  app.UseAuthentication();
  app.UseStaticFiles(new StaticFileOptions
  {
    OnPrepareResponse = ctx =>
    {
      // 現在の要求が認証済みでないなら...
      if (!ctx.Context.User.Identity.IsAuthenticated)
      {
        // "HTTP 401 Unauthorized" を返す.
        ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
      }
      ...

...なのに秘密のファイルが丸見え!

続けて先のサンプルコードをビルド、実行してみた、のだが...

ASP.NET Core で静的ファイルを認証で保護する_d0079457_21463503.png

期待に相反し、保護したはずの静的ファイルが、匿名アクセスでも見えてしまった!

たしかに自分が設定したコールバック関数は、認証されていない要求がきたら、 "401 Unauthorized" HTTP ステータスをブラウザに返せてはいるようだ。

しかしながら、静的ファイルミドルウェアがブラウザにコンテンツを返す処理に対し何の処置もしていなかったので、こんなことになったらしい。

応答全体を阻止する

HTTP ステータス 401 を返すことに加えて、静的ファイルミドルウェアによる応答本文をどうにかして破棄する必要がある。

これを実現するために、あともう2行、先のサンプルコードに追加した。

...
// "HTTP 401 Unauthorized" を返し...
ctx.Context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;

// さらに下記の2行を追加して、応答ボディを破棄!
ctx.Context.Response.ContentLength = 0;
ctx.Context.Response.Body = Stream.Null;
..

この追加の2行で、静的ファイルミドルウェアによる応答ボディをすべて破棄することができる。

というのも、応答オブジェクトの Body ストリームを System.Null に差し替えているためだ。

System.Null への書き込みはすべて単純に破棄され、また、読み取りは空を返すので、静的ファイルミドルウェアは応答ボディに対して何の影響も及ぼさなくなる。

こうすることで、めでたく、秘密のファイルを保護することに成功した。

ASP.NET Core で静的ファイルを認証で保護する_d0079457_21463908.png

なお、さらなる考慮事項として、ブラウザキャッシュの挙動にも気を付けた方が良さそうだ。

というのも、自分が試した範囲だと、いちど認証を済ませて保護された静的ファイルを開いたことがある場合、その後サインアウトして未認証の状態でも、ブラウザキャッシュから当該静的ファイルを見ることができた場合があったからだ。

自分は "Cache-Control" 応答ヘッダに "no-store" を指定し、キャッシュに保存することを一切禁止とブラウザに知らせることで、この挙動を回避した。

ctx.Context.Response.Headers.Add("Cache-Control", "no-store");

リダイレクトさせたい場合

未認証の状態で保護された静的ファイルの URL が要求されたときに、HTTP 401 応答を返すのではなく、"サインイン" ページなどにリダイレクトさせることも可能だ。

コードは次のようになるだろう。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
  ...
  app.UseAuthentication();
  app.UseStaticFiles(new StaticFileOptions
  {
    OnPrepareResponse = ctx =>
    {
      if (!ctx.Context.User.Identity.IsAuthenticated)
      {
        // 任意の URL にリダイレクト可能.
        ctx.Context.Response.Redirect("/")
      }
      ...

まとめ

静的ファイルミドルウェアを HTTP 処理パイプラインに登録するとき (UseStaticFiles() 呼び出し) のオプション引数の OnPrepareResponse プロパティを活用することで、静的ファイルを認証で保護することができる。
但し、UseAuthentication() 呼び出しを、UseStaticFiles(...) 呼び出しよりは前に済ませておくこと。
また、HTTP 401 応答を返して要求を拒否する場合は、加えて静的ファイルミドルウェアによる応答ボディ書き込みも阻止すること。
完璧に保護するためには、キャッシュ制御についても考慮が必要。
もちろん、HTTP 401 応用を返すのではなく、特定の URL にリダイレクトさせることもできる。

サンプルコード全体は下記 URL の GitHub リポジトリで公開している。

実際に動作するライブデモサイトも下記 URL で稼働中だ。

https://protect-staticfiles-with-auth-on-aspnetcore.azurewebsites.net/

以上!

▲ by developer-adjust | 2020-05-27 21:59 | .NET | Comments(0)

2020年 02月 17日

Twitter 認証を実装した ASP.NET Core 3.1 Web アプリで、Twitter 認証時にキャンセルをしたら、アプリがクラッシュした件

背景

ASP.NET Core 3.1 による、C# で実装した自作 Web アプリでの話。

昨今の Web アプリ用フレームワークの例に漏れず、ASP.NET Core においても、いわゆる "Twitter アカウントでサインイン" といった外部認証を実装することは容易である。

例えば Twitter での認証の仕組みを組み込みたい場合は、下記公式ドキュメントなどを参考に実装すればよい。

上記公式ドキュメントを参照することでわかるとおり、他にも、Google アカウントや Microsoft アカウント、Facebook アカウントなどなど、様々な外部アカウントを使った認証が容易に組み込み可能だ。

実装例

実際、自分が開発しているとある Web アプリ (ソースコードは下記) でも、Twitter による認証を実装している。

実装についてポイントだけかいつまむと、まずは自作の Web アプリのソースコード中、DI 機構へのサービス登録を行なっている、Startup クラスの ConfigureServices() メソッド内にて、標準的な Cookie ベースの認証用のサービスに加えて、Twitter 認証のためのサービスを "AddTwitter()" 拡張メソッドで登録してやる。

このタイミングで、Twitter 側で作業を済ませておいた、コンシューマー API キーとシークレットを、Twitter 認証構成オプションに設定するよう実装しておく。

// Startup.cs
...
public void ConfigureServices(IServiceCollection services)
{
  ...
  services.AddAuthentication(...)
    .AddCookie(...)
    // Twitter アカウントでのサインイン機構を組み込み
    .AddTwitter(options =>
    {
      options.ConsumerKey = ...;
      options.ConsumerSecret = ...;
    });
    ...

続けて、HTTP 要求を処理するパイプライン中に、認証の処理を挿入するため、同じく Startup クラス内の Configure() メソッド内にて、"UseAuthentication()" 拡張メソッドをしかるべき順序で呼び出し・ミドルウェアの挿入を行なっておく。

// Startup.cs
public void Configure(IApplicationBuilder app, ...)
{
  ...
  app.UseAuthentication();
  ...

最後に、Twitter アカウントでの認証を開始するための MVC アクションや API エンドポイントを実装し、これを呼び出してやれば良い。

// 何かコントローラなど
...
[HttpGet("/auth/signin")]
public IActionResult SignIn()
{
  // 認証スキーマとして Twitter による外部認証を指定している
  return Challenge(TwitterDefaults.AuthenticationScheme);
}

詳細はかなり端折っているが、概ね上記のような実装にて、この Web アプリの ~/auth/sigin へ遷移すると、Twitter の認証画面が開き、Twitter アカウントによる認証ができるようになる。

Twitter 認証を実装した ASP.NET Core 3.1 Web アプリで、Twitter 認証時にキャンセルをしたら、アプリがクラッシュした件_d0079457_18564335.png

実装の "手抜き" が発覚!

さて、そんな自作 Web アプリにおいて、ちょっと手抜きしていた点が発覚してしまった。

自作 Web アプリから認証を開始し、Twitter 側のページに遷移したあと、この Twitter の認証画面で「キャンセル」された場合を考慮していなかったのだ。

で、実際に Twitter の認証画面でのキャンセルを試してみたところ、あえなく、この自作 Web アプリは HTTP 500 Internal Server Error を吐いてしまった。

ローカル開発環境にて確認してみると、下記のような例外が発生していた。

System.Exception:
  An error was encountered while handling the remote login.
System.Exception:
  Access was denied by the resource owner or by the remote server.
 at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()

解決方法

では、外部認証先でのキャンセルの操作に対応するにはどうしたらよいのか?

某氏に教えてもらったところ、下記 Stackoverflow のスレッドに答えがあった。

すなわち、Twitter 認証のためのサービスを DI 機構に登録する際、そのオプション構成指定時に「Twitter による認証が失敗した」ときに呼び出されるコールバック関数を指定することができる。

具体的には、オプション引数の Events > OnRemoteFailure プロパティがそのコールバック関数となる。

というか、コールバック関数を指定してアプリケーション開発者が外部認証失敗時の処理を明示しないと、前述の例外発生となってしまうようだ。

さて、OnRemoteFailure で指定するコールバック関数、その引数には RemoteFailureContext オブジェクトが渡される。

このコンテキストオブジェクトには、Exception 型の Failure プロパティが公開されている。

これを参照することで、同じ「認証失敗」であっても、キャンセルなのかもっと他の要因で失敗したのか、処理の場合分けができそうだ (※自分は未確認)。

また、このコールバック関数の引数 = RemoteFailureContext オブジェクトには Response プロパティが提供されている。

この Repsonse オブジェクトを使うことで、外部認証失敗時における、お好みの HTTP 応答を返すことができる。

自分のアプリの場合は、何があろうと雑に、しれっとアプリのトップページに戻すこととした。

具体的には下記のとおり実装してみた。

...
.AddTwitter(options =>
{
  ...
  options.Events.OnRemoteFailure = context =>
  {
    var appUrl = $"{context.Request.Scheme}://{context.Request.Host}/";
    context.Response.Redirect(appUrl);
    context.HandleResponse();
    return Task.CompletedTask;
  };
})
...

まとめ

以上で Twitter の認証画面でキャンセルされた場合でも、HTTP 500 ページになることなく、それなりの動作 (今回の例では単にアプリケーションのトップページに戻るだけ) に収めることができた。

自分は Twitter アカウントによるサインインでしか確認していないが、おそらくは他の外部認証の場合でも、この Events.OnRemoteFailure による外部認証失敗時のハンドリングの仕組みは同じことだろう。

▲ by developer-adjust | 2020-02-17 19:04 | .NET | Comments(0)

2019年 08月 29日

Entity Framework Core でデータベースを読み書きする ASP.NET Core アプリ開発中に、発行される SQL 文字列を確認する

背景 - EFCore が出力する SQL 文を知りたい

データベースを読み書きする ASP.NET Core Web アプリ実装において、データベースアクセスライブラリの選択肢としてとりあえずオーソドックスな "Entity Framework Core" (以下 EFCore)。

EFCore およびその前身である "Entity Framework" の面白いところは、データベースクエリの結果をオブジェクトに "マップ" する O/R マッパーというだけでなく、C# コードとして記述されたラムダ式木に基づく SQL クエリビルダーでもあるという側面がある。

さてそんな EFCore であるが、だがしかし、期待していたのとは異なる SQL が発行される可能性も少なくない。

とくに EFCore の ver.2.x だと、GROUP JOIN ですら、簡素な SQL を発行して早々にデータベースから多量のレコードをオブジェクトとして読み込んでしまい、オンメモリで残りの処理を実行することもあるという。

なお、本ブログ執筆時点では未だリリースされていない、次バージョン EFCore 3.x では、このあたりの挙動が変更され、SQL に変換できないクエリは例外を発生させることになるらしい。

この辺りの話題は、下記などが参考になる。

そんなこともあり、とくにアプリ開発中は、EFCore が発行する SQL 文を確認したいところである。

なお、コンソールアプリなどで EFCore 使用時に、その発行する SQL を確認するには、その目的のロギング機構を組み立てて適用すればよい。

詳しくは下記などが参考になる。

実は開発時ログ出力には、既に含まれている

さてさて、ASP.NET Core アプリ開発中は、一般的なプロジェクトテンプレートから起こしたプロジェクトであれば特に、すでにロギング機構が組み込まれており、且つ、開発時向けのログレベル構成が適用済みである。

下記は開発時用構成ファイルである appSettigs.Development.json 中のログレベル構成だ。

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
}

この構成だと、Visual Studio で開発中であれば、Visual Studio の出力ウィンドウに色々ログが流れているのが確認できる。

(※デバッガなし実行でも表示される)

また、dotnet CLI を使ってる場合も "dotnet run" などで実行すると、コンソールにログが流れるのを見ることができる。

実は既に、EFCore が出力する SQL 文は、このログの中に表示されているのだ。

よーく見ると、EFCore が出力する SQL 文が、ログの中に表示されているのを見つけることができる (下図、赤丸のところ)。

Entity Framework Core でデータベースを読み書きする ASP.NET Core アプリ開発中に、発行される SQL 文字列を確認する_d0079457_20534430.png

大量のログ出力に埋もれてしまう...

しかしである。

上図でもわかるように、このままでは、ブラウザ等からの要求ごとの ASP.NET Core 関連ログが大量に発生し、EFCore の SQL 文ログがそれらログに埋もれてしまう。

(ないしは、あっという間にスクロールアウトしてしまう)

実際問題として、この構成のままでは、大量のログの中から EFCore が出力する SQL 文を探し出して確認するという作業はあまり現実的ではない。

これは個人的な意見であるが、実のところ、ASP.NET Core 関連の要求処理時の情報ログは、あまり必要を感じない。

どのようなリクエストがブラウザから発生しているかを見るときは、どちらかといえば、ブラウザの開発者ツールで確認するだけで用が足りることがほとんどだ。

EFCore 以外のログレベルを調整

ということで、appSettings.Development.json を改訂し、"Microsoft" カテゴリのログレベルを "Information (情報)" から "Warning (警告)" レベルに引き上げてしまうと良かろう。

そうすることで、ASP.NET Core 関連の大量の情報ログが表示されなくなる。

ただしそれだけだと、EFCore の SQL 文出力も同じく表示されなくなってしまう。

そこで、EFCore の SQL 出力だけはログ出力されるよう、"Microsoft.EntityFrameworkCore.Database.Command" カテゴリのログレベルを、再び "Information" としてオーバーライドするとよい。

最終的な appSettigs.Development.json は下記のような感じになる。

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Warning",
      "Microsoft.EntityFrameworkCore.Database.Command": "Information"
    }
  }
}

これで下図のような感じで、EFCore の出力する SQL 文だけが都度流れるようになる。

Entity Framework Core でデータベースを読み書きする ASP.NET Core アプリ開発中に、発行される SQL 文字列を確認する_d0079457_20535155.png

自分の開発スタイルとしてはこれくらいのログレベルでちょうどいい感じだ。

以上、すべてのケースでこのログレベル構成が最適とは言わないが、同じような境遇の人にこの情報が役に立てば幸いである。

補足

データベースアクセスのためには、EFCore 以外にも選択肢はいろいろあるので、発行される SQL を完全に制御したい場合などは、無理に EFCore を使う必要もない。

下記など参考にされたし。

▲ by developer-adjust | 2019-08-29 21:11 | .NET | Comments(0)

2019年 07月 06日

ASP.NET Core での単体テスト内で、オプションおよびサービスプロバイダを作成する

C# による ASP.NET Core プログラミングにおける、単体テストを実装していての話題。

ネットで検索すればすぐに見つけられるような内容かとも思うが、自分の為の備忘録を兼ねてここに記す。

さて、前述のとおりの単体テストを実装している際、IOption<T> をコンストラクタ引数に求めるオブジェクトをテスト対象とすることがある。

さらにたまーにではあるが、コンストラクタ引数に IServiceProvider を直に要求するオブジェクトを扱うこともある。

このようなケースで、どのように IOption<T> ならびに IServiceProvider をテストプログラム中でインスタンス化すればよいか、という話である。

IOption<T>

ASP.NET Core におけるオプション構成は、通常は Startup クラス中の ConfigureServices メソッド内で初期化するのが通常だ (下記は MyOptions 型のオプションを appSettings.json などの構成情報から読み取って取得する例)。

public class Startup
{
  private IConfiguration Configuration { get; }

  public Startup(IConfiguration configuration)
  {
    Configuration = configuration;
  }

  public void ConfigureServices(IServiceCollection services)
  {
    services.Configure<MyOptions>(this.Configuration.GetSection("My"));
    ...

こうしておくと、MVC/API コントローラなどで MyOptions 型のオプション情報が必要な場合は、そのコンストラクタ引数として IOptions<MyOptions> 型の引数を用意しておけば、依存性注入機構によって引き渡されるようになっている (下記例)。

public class MyController : Controller
{
  private IOptions<MyOptions> MyOptions { get; }

  public MyController(IOptions<MyOptions> myOptions)
  {
    this.MyOptions = myOptions;
    ...

さてこのような IOption<T> を自前のテストコード中で直に生成するには、Microsoft.Extensions.Options 名前空間の Options クラスの Create<T>(T options) 静的メソッドを用いる。

この Create<T>(T options) 静的メソッドの引数に、任意の型 T のオブジェクトを渡せば、その戻り値で IOption<T> が返る　(下記例)。

using Microsoft.Extensions.Options;
...
IOptions<MyOptions> myOptions = Options.Create(new MyOptions {...});

IServiceProvider

IServiceProvider を自前のテストコード中で生成するには、Microsoft.Extensions.DependencyInjection 名前空間の、ServiceCollection クラスを使う。

手順としては、まずは ServiceCollection クラスをインスタンス化する。

次にこの ServiceCollection オブジェクトに対し、AddSingleton<T1,T2>() などをはじめとしたおなじみのメソッドを呼び出して、そのテストで必要となるサービスを登録しておく。

(すなわち、IServiceProvider を要求しているテスト対象のコード中では、その IServiceProvider に対して GetService<T1>() とか呼び出して、サービスを入手しているであろうため)

以上の準備が整ったら、ServiceCollection オブジェクトの BuildServiceProvider() メソッドを呼び出す。

そうすると、BuildServiceProvider() メソッドの戻り値として、IServiceProvider が返る。

var services = new ServiceCollection();
services.AddSingleton<IMyService, MyServiceMock>());
...
var serviceProvider = services.BuildServiceProvider();

使い終わったら、Dispose() メソッドを呼び出してリソース破棄しておくことを忘れずに。

以上!

▲ by developer-adjust | 2019-07-06 23:02 | .NET | Comments(0)

2019年 02月 26日

ASP.NET Core Web アプリプロジェクトで、Node.js 使わずに Sass (SCSS) をコンパイルする

.NET Core SDK 環境のみで Sass (SCSS) をコンパイルする

C# による Web アプリ・サーバー側実装のフレームワーク ASP.NET Core を使った、Web アプリプログラム開発での話。

最近はフロント側を Angular で書くようになったため、Sass (SCSS) を CSS にコンパイルするのは、webpack によるモジュールバンドリング処理の一環として webpack の loader で行なう必要があり、実際そのようにしている。

しかし他方、Angular などのフロント側フレームワークに依らない、静的なちょっとした Web サイト作成や、C# でフロント側を実装する Blazor のようなフレームワークを使うケースでは、Sass (SCSS) ファイルを css ファイルにコンパイルする方法は、必ずしも webpack に頼る必要はない。

実のところ、.NET Core プロジェクトのビルドシステムにおいては、nuget.org で公開されているライブラリ (NuGet パッケージ) による支援もあって、Sass (SCSS) を css にコンパイルすることが可能だ。

.NET Core SDK さえ開発マシンにインストールされていれば、Node.js などがインストールされていなくても、Sass (SCSS) コンパイルが可能なのである。

ただ、現時点では .NET Core プログラムのビルドの一環として Sass (SCSS) コンパイルを実施することが可能、という状況なので、プロジェクトファイル (.csproj など) が必須である。

実際にやってみる

.NET Core プログラムのビルドの一環として Sass (SCSS) コンパイルを実施するには、まず、以下の NuGet パッケージを当該プロジェクトにパッケージ参照追加する。

dotnet CLI であれば、対象プロジェクトがあるフォルダをカレントディレクトリにして、下記を実行すればよい。

> dotnet add package BuildWebCompiler

Windows OS 上で Visual Studio を使っている場合は、GUI のパッケージマネージャから追加してもよいだろう。

ASP.NET Core Web アプリプロジェクトで、Node.js 使わずに Sass (SCSS) をコンパイルする_d0079457_21554818.png

次に、対象プロジェクトのルートフォルダに以下のような内容の設定ファイル "compilerconfig.json" を作成する。

[
  {
    "inputFile": "wwwroot/css/test.scss",
    "outputFile": "wwwroot/css/test.css"
  }
]

以上で設定完了だ。

上記 compilerconfig.json の inputFile で指定した Sass (上記例だと SCSS 形式だが) ファイル "wwwroot/css/test.scss" を作成し、ビルドを実行する。

そうすると、この Sass (SCSS) ファイルがコンパイルされて、outputFile で指定されたファイル名の CSS ファイルが出力されるのが確認できるはずだ。

さらにオマケとして、出力先 css ファイルは、そのミニファイ版も同時に生成される（ファイル名は .../test.min.css となっている）。

compilerconfig.json にどのような記述ができるかは、あまり詳しいリファレンスは見つけていないものの、先の NuGet パッケージの GitHub リポジトリにある README (下記 URL) が参考になる。

https://github.com/madskristensen/WebCompiler#compilerconfigjson

このように、.NET Core SDK 環境だけでも、プロジェクトのビルドの一環として、Sass (SCSS) ファイルを css にコンパイルすることが可能である。

ちなみにこの BuildWebCompiler NuGet パッケージ、実は Sass (SCSS) -> css コンパイルのみならず、LESS や CoffeeScript などなど、様々な変換が可能だ。

自分では実際には試したことがないが (※CoffeeScript 書くスキルがない...)、もし需要があるなら試してみるとよいかもしれない。

Sass (SCSS) -> CSS コンパイルだけ実行する

ビルド時に Sass (SCSS) -> CSS コンパイルができるようになったが、しかしながら開発中は、.scss を編集するだけでいちいちプロジェクト全体をビルドはしたくないところである。

dotnet CLI を使うなら、対象プロジェクトがあるフォルダ上で下記 dotnet コマンドを実行することで、Sass (SCSS) -> CSS コンパイルだけを実施することが可能だ。

> dotnet msbuild -t:WebCompile -nologo

ウォッチ

さらにできれば、.scss ファイルを保存したら自動で .css にコンパイルしてくれたら嬉しい。

そのためのやり方のひとつとして、「ファイルの変更を監視し、変更されたらタスク (この場合は .scss > .css のコンパイル) を実行する」という "ウォッチ" 方式がある。

このウォッチ方式による .scss > .css 自動コンパイルの実現は、dotnet CLI のウォッチ機能を利用することで可能となる。

ただし残念ながら自分が知る限り、ちょっとだけ事前の手順が必要。

まず対象プロジェクトファイルをテキストエディタで編集し、下記の要領で .scss ファイルを監視対象に含めるようプロジェクトを構成する必要がある。

<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <ItemGroup>
    ...
    <Watch Include="wwwroot\css\*.scss" /> <!-- この行を追加 -->
  </ItemGroup>
  ...

上記変更を施したら、対象プロジェクトがあるフォルダ上で下記 dotnet コマンドを実行することで、ファイル変更の監視を行なう dotnet CLI が常駐する。

> dotnet watch msbuild -t:WebCompile -nologo

この状態で .scss ファイルを上書き保存すると、.scss > .css コンパイルが実行されるようになる。

なお、dotnet CLI の watch 機能は、監視対象のファイルを状況に応じて使い分けることが難しいようで、例えばこの状態で、同プロジェクトに含まれる C# ソースコード (.cs ファイル) を上書き保存しても、.scss > .css コンパイルが走ってしまう。

dotnet CLI の watch 機能を、このプロジェクトでは .scss > .css コンパイルにしか使わない、という場合は、プロジェクトファイルに以下のとおり追記して、C# ソースコードファイルを監視対象から除外することが可能だ。

<Project Sdk="Microsoft.NET.Sdk.Web">
  ...
  <ItemGroup>
    ...
    <Compile Update="**/*.cs" Watch="false" /> <!-- この行を追加 -->
  </ItemGroup>
  ...

IDE/エディタの拡張機能もあるが...

以上ここまで、.NET Core SDK 環境で、プロジェクトのビルドの一環として Sass (SCSS) を CSS にコンパイルする方法について説明してきた。

なお、Sass (SCSS) を CSS にコンパイルする方法としては他にも、Visual Studio のような IDE や、Visual Studio Code などのエディタにおける「拡張機能」を利用することもできる。

実際、Windows OS 上で Visual Studio を使う場合は下記拡張を Visual Studio にインストールしておくと、Visual Studio 上での .scss ファイルの編集・保存時に .css へのコンパイルが実行されるようになる。

実のところ、これまで説明してきた、.NET Core アプリプロジェクトのビルド時に Sass (SCSS) コンパイルが実行されるやり方で使用したに BuildWebCompiler NuGet パッケージと上記 Visual Studio 拡張は同じコードベースで作られている。

そのため、先に説明した compilerconfig.json の設定を読んで同じように動作するので大変使い勝手が良い。

あと、同じ理由で、この Visual Studio 拡張も Sass (SCSS) のみならず LESS やら CoffeeScript やらもファイル保存時のコンパイルが可能だ。

また、Visual Studio Code であれば、下記の拡張が人気があるようだ。

このように、IDE やエディタの拡張機能を用いることで、.scss ファイル保存時に自動で .css にコンパイルすることができるようになり、このほうが開発者体験としてはより良いように感じる。

とはいえ、開発メンバー全員の IDE/エディタ環境を揃えるのが手間だったりうまくいかないことがあるかもしれない。

開発環境を再構築後に、うっかり拡張を入れ忘れてしまい、.scss を変更・保存したけれども、対応する .css が更新されずしまい、というバグだって引き起こしてしまうかも知れない。

そうしたケースに備える目的で、ソースコードをリポジトリから git clone するだけで、開発環境への各種拡張の追加インストールすることなく、最低限ビルドすればちゃんと .scss が .css にコンパイルされるようになるのは、これはこれで便利で大事なことだと思う。

補足

これまでの説明では、あくまでも .NET Core アプリ開発としての説明としてきたが、実は BuildWebCompiler NuGet パッケージは、.NET Framework のプロジェクトに追加しても同じように動作する。

これまでの説明における dotnet CLI を使った用法はできないが、Visual Studio 上で .NET Framework 用アプリ開発時でも、同じようにビルド時に Sass (SCSS) ファイルを CSS ファイルにコンパイルすることが可能となる。

▲ by developer-adjust | 2019-02-26 22:01 | .NET | Comments(0)

2018年 12月 28日

ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする

背景

Visual Studio や dotnet CLI + お好みのエディタなどを使っての、ASP.NET Core Web アプリを開発中の話。

開発中の ASP.NET Core Web アプリを、エミュレータではない実機のモバイル端末 (iOS や Android など) から接続して動作確認したいことはよくある。

その実現方法としては、例えば ngrok を使ってローカル開発中の ASP.NET Core Web アプリをインターネット上に晒し、そこにモバイル端末実機のブラウザから接続しにいくのもアリではある。

とはいえ、開発途上のものを、一時的とはいえインターネット上に晒すのは危険が伴う。

そもそも通信経路が長くなる上、ngrok の処理性能やモバイル回線の速度・帯域にも大きく左右されて、すばやい動作確認、トライ&エラーの繰り返しがやりにくい。

ということで、顧客に見てもらうなどの理由がない限りは、開発機と同一ローカルエリアネットワークに Wi-Fi 接続したモバイル端末実機から、同ネットワーク経由で接続するのが普通かと思う。

ただ、ASP.NET Core Web アプリの既定のプロジェクト構成では、開発中の ASP.NET Core Web アプリはローカルホスト (127.0.0.0/24, ::1) でしか待ち受けしていない。

なので、当該開発機の外部からは、そのままでは接続できない。

そこで、プロジェクト構成を変更する必要がある。

Visual Studio 上からの設定変更

Visual Studio で開発中の場合、お勧めの方法は以下のとおり。

まず実行形態を、IIS Express によるホスティングではなく、プロジェクト実行 (いわゆる、"dotnet run" 実行) を選択しておく。
Visual Studio 上で当該 ASP.NET Core Web アプリプロジェクトのプロパティ表示を開き、[デバッグ] カテゴリを開く。
この画面で、[ブラウザを起動] の設定で、「https://localhost:5001」というような絶対 URL を明記。
続けて [環境変数] のところに、[名前] が「ASPNETCORE_URLS」である項目を追加、[値] には「https://*:5001;http://*:5000」というように、ホスト名を「*」で指定した待ち受け URL を、複数ある場合はセミコロン (;) 区切りで設定する。
[アプリケーション URL] の欄は空欄にする。

ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする_d0079457_22243549.png

以上で Ctrl+F5 で実行などすれば、当該開発機の外部からも、この ASP.NET Core Web アプリが接続を受理、応答を返すようになる。

なお、上記で行なった設定内容は、Properties フォルダ内にある、「launchSettings.json」というファイル名の JSON ファイルにその設定内容が保存されている。

例えば次のとおり。

{
  "iisSettings": ...,
  "profiles": {
    "IIS Express": ...,
    "WebApplication1": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "https://localhost:5001",
      "environmentVariables": {
        "ASPNETCORE_URLS": "https://*:5001;http://*:5000",
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": ""
    }
  }
}

"dotnet run" で実行する場合

dotnet CLI を用いた "dotnet run" による実行でも、上記 launchSettings.json に基づいて ASP.NET Core Web アプリを立ち上げる。

なので、 dotnet CLI を使っての開発中の場合でも、上記のように launchSettings.json を作成・記述しておけばそれだけでよい。

また、先の説明では端折ってしまったが、設定のキモは、環境変数 ASPNETCORE_URLS の設定である。

標準のプロジェクトテンプレートで作成された ASP.NET Core Web アプリであれば、環境変数 ASPNETCORE_URLS を見て、そこに設定されている待ち受け URL を採用するようにできているのだ。

先で説明している launchSettings.json の内容も、要するに環境変数 ASPNETCORE_URLS を設定しているわけである。

なので、launchSettings.json がなくても、コマンドプロンプト (ターミナル) で下記のように環境変数 ASPNETCORE_URLS を設定してから dotnet run を実行することでも OK だ。

> rem 以下は Windows OS のコマンドプロンプトでの例
> cd \path\to\yourprojectdir
> set ASPNETCORE_URLS=https://*:5001;http://*:5000
> dotnet run

※ "dotnet run" を実行したコマンドプロンプト (ターミナル) 内で環境変数 ASPNETCORE_URLS を設定しつつ、 launchSettings.json でも環境変数 ASPNETCORE_URLS を設定していた場合は、 launchSettings.json の設定のほうが優先する。

補足: アプリケーション URL を設定すればよいのでは?

ホストアドレスに「0.0.0.0」を指定

実は、Visual Studio での設定時、環境変数 ASPNETCORE_URLS ではなく、[アプリケーション URL] に、「https://0.0.0.0:5001;http://0.0.0.0:5000」というように、ホストアドレスを「0.0.0.0」とした待ち受け URL を設定することでも、外部からの接続を受け付けるようになる。 ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする_d0079457_22243059.png

ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする_d0079457_22243059.png

但し上図の設定だと、IPv4 アドレスでのみ待ち受けすることになるので注意。

すなわち、開発機上のブラウザでアドレスバーに「https://localhost:5001」や「http://127.0.0.1:5001」と入力するぶんには当該 Web アプリにアクセスできるものの、IPv6 アドレスである「https://[::1]:5001」を入力すると、接続不能となるのである。

まぁ、「開発中の Web アプリをモバイル端末実機で確認」という用途であれば、IPv4 アドレスのみでの待ち受けで十分事足りる気もする。

なので、実際上は、上図のようなアプリケーション URL 設定による方式で十分かもしれない。

もっとも、IPv6 アドレスでも待ち受けさせることももちろん可能で、その場合はホストアドレスとして「[::]」を指定すればよい。

例えば「https://0.0.0.0:5001;http://0.0.0.0:5000;https://[::]:5001;http://[::]:5000」というようにアプリケーション URL を設定すれば、IPv4 でも IPv6 でも、外部からつながるようになる。

ただ、ちょっと設定が長すぎではある。

アプリケーション URL 設定で、ホストアドレスに「*」を指定しないのはなぜ?

アプリケーション URL 設定に、（環境変数 ASPNETCORE_URLS での設定と同じように）「https://+:5001」とか「https://*:5001」のように、ホストアドレスとして「+」や「*」を指定すれば、 IPv4 と IPv6 の設定を併記しなくて済むのでは? とも思われた。

試しにやってみたところ、 launchSettings.json を直接編集して "applicationUrl" に "https://*:5001" を設定し、dotnet run で実行するぶんにはうまくいった。

しかし launchSettings.json がこの状態で、当該プロジェクトを Visual Studio で開き、Ctrl+F5 実行すると、「Invalid URI: The hostname could not be parsed.」というエラーメッセージボックスを表示して起動してくれない。

また、Visual Studio 上からは、アプリケーション URL に + や * をホストアドレスとした URL を設定すると入力検証エラーになって設定できない。

加えて、先のとおり launchSettings.json を直接編集した状態でプロジェクトのプロパティ画面から [デバッグ] セクションを開いてしまうと、場合によっては入力検証エラーに阻まれ、プロパティ画面を閉じたり保存したりができなくなり、どうにもならない "詰んだ" 状況に陥ってしまう。

...これらのことから、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式がいちばん一貫性もあり、自分のお勧めの方法と結論づけている。

補足: [ブラウザを起動] の URL を明記するのはなぜ?

dotnet run で実行するぶんには、 launchSettings.json の "launchUrl" は無くても (あるいは空文字であっても) なんら問題ない。

本稿作成時点では、dotnet run では、ブラウザの起動までは行なわないからだ。

しかし Visual Studio 上で開発・実行してブラウザも開きたいというケースでは、[ブラウザを起動] の URL を明記しておかないと厄介なことになる。

まず、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式の場合、Ctrl+F5 実行すると、Web アプリのプロセスは起動するものの、Visual Studio がエラーメッセージボックスを出してブラウザ起動に至らない。

また、アプリケーション URL にホストアドレス 0.0.0.0 で設定する方式の場合、Ctrl+F5 実行すると、ブラウザは起動するものの、「https://0.0.0.0:5001」という URL を開いてしまってアクセスできない結果となる。

なので、少なくとも Visual Studio 上での実行でブラウザも同時に開きたいケースでは、ちゃんと [ブラウザを起動] の URL を明記しておくに越したことはない。

補足: IIS Express での実行時について書かれてないけど?

需要と余力があれば調べて試して本ブログに投稿する...かもしれない。

▲ by developer-adjust | 2018-12-28 22:37 | .NET | Comments(0)

2018年 09月 28日

ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション

ASP.NET Core アプリのアプリケーション構成

ASP.NET Core アプリは、標準のプロジェクトテンプレートで作成すると、プロジェクトのフォルダにある appSettings.json というファイルを読みこんで、アプリケーション構成として使用するようにできている。

この appSettings.json にアプリケーション固有の半固定パラメータなどの設定値を JSON 形式で記述しておき、アプリ中からその設定値を読み取って利用する、というものだ。

詳しくは下記を参照するとよいだろう。

例えば下記のような appSettings.json を用意したとして、

{
  "SiteSettings": {
    "Title": "Hello World",
    "TimeZone": {
      "Name": "Tokyo Standard Time",
      "Offset": 9
    },
    "Tags": [
      { "Text": "Foo", "Priority": 0.7 },
      { "Text": "Bar", "Priority": 0.3 }
    ]
  }
}

ASP.NET Core アプリの実装コード (今回は C#) で、下記のように、上記 appSettings.json の JSON 構造にマッピングされるクラスを用意して、

public class SiteSettings {
  public string Title { get; set; }

  public TimeZoneSettings TimeZone { get; set; }

  public class TimeZoneSettings {
    public string Name { get; set; }
    public int Offset { get; set; }
  }

  public TagSettings[] Tags { get; set; }

  public class TagSettings {
    public string Text { get; set; }
    public double Priority { get; set; }
  }
}

ASP.NET Core アプリの Startup クラスにて、下記のように、appSettings.json ファイル中の SiteSettings ノード以下を DI コンテナへサービス登録することで、

public class Startup
{
  public IConfiguration Configuration { get; }
  
  public Startup(IConfiguration configuration)
  {
    Configuration = configuration;
  }

  public void ConfigureServices(IServiceCollection services)
  {
    services.Configure<SiteSettings>(Configuration.GetSection("SiteSettings"));
    ...

`IOptions<SiteSettings>` 型のインスタンスを DI 機構によって入手できるようになる。

この `IOptions<SiteSettings>` オブジェクトの各プロパティを参照すると、appSettings.json の記載内容が SiteSettings オブジェクトにマッピングされて読み取られ、参照可能となっている寸法だ。

// 変数 settings は、DI 機構から入手した IOptions<SiteSettings> オブジェクトへの参照
settings.Value.Title; // <- "Hello World"
settings.Value.TimeZone.Name; // <- "Tokyo Standard Time"
settings.Value.TimeZone.Offset; // <- 9
settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[1].Text; // <- "Bar"

アプリケーション構成の "上書き"

この appSettings.json に記載されている設定値だが、いくつかの方法で "上書き" が可能だ。

ひとつは appSettings.Develop.json に記述する方法。

開発環境での実行時は、appSettings.json の設定値に対して、appSettings.Develop.json に記述した設定値で上書きされたように、アプリ側では設定値を読み取るようにできているのだ。

この仕組みにより、appSettings.json には既定値を、appSettings.Develop.json には各開発者固有の環境依存の設定値など（例えばデータベースの接続先設定値とか）を記載しておいたりして、アプリの動作を調整できる。

例えば先の例だと、appSettings.Develop.json に以下のように記述しておくと、

{
  "SiteSettings": {
    "TimeZone": {
      "Name": "Asia/Tokyo",
    }
  }
}

アプリ側の読み取り結果は下記のとおりとなる。

settings.Value.Title; // <- "Hello World"
settings.Value.TimeZone.Name; // <- "Asia/Tokyo" ... 上書きされた!
settings.Value.TimeZone.Offset; // <- 9
settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[1].Text; // <- "Bar"

なお、appSettings.Develop.json の "Develop" のファイル名部分は、実は環境変数 ASPNETCORE_ENVIRONMENT の値である。

なので、環境変数 ASPNETCORE_ENVIRONMENT に "FooBar" を設定すれば、appSettings.FooBar.json が上書き用に読み込まれる。

アプリケーション構成のセクション名は英字の大小が区別されない

話は逸れるが、面白い(?)ことに、appSettings.Develop.json で appSettings.json の設定値を上書きする際、セクション名 (ノード名、プロパティ名) の英字の大文字と小文字は一致しなくても構わない。

アプリケーション構成のセクション名は Case Insensitive として動作するのだ。

なので、appSettings.json に、英字の大小違いの同一セクションを設けると（例えば下記）、JSON としては間違いではないのだが、その ASP.NET Core アプリは起動時にクラッシュしてしまう。

{
  "SiteSettings": {
    "title": "hello world", // <- セクション名の先頭が小文字
    "Title": "Hello World", // <- セクション名の先頭が大文字

IIS 経由で実行した場合は

「HTTP Error 502.5 - Process Failure - The application process failed to start」

として現れるし、「dotnet run」で実行すると、

「Unhandled Exception: System.FormatException: A duplicate key 'SiteSettings:Title' was found.」

というように、重複キー発生である例外メッセージがコンソール出力から読み取れる。 ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション_d0079457_23131528.png

環境変数で "上書き"

アプリケーション構成を上書きするもうひとつの方法は、環境変数で "上書き" する方法である。

appSettings.json 中の各セクション (ノード、プロパティ) 名を、コロン (:) 区切りで連結した名前で環境変数を定義すると、その環境変数の値がアプリケーション構成として読み取れるのだ。

言い換えると、C# や JavaScript 上、ドット (.) で区切るところをコロン区切りに置き換えた名前、とも言える。

先の例でいくと、例えば環境変数 "SiteSettings:TimeZone:Offset" に "8" と設定してから実行すると、アプリでの読み取り結果は下記のとおりとなる。

settings.Value.Title; // <- "Hello World"
settings.Value.TimeZone.Name; // <- "Tokyo Standard Time"
settings.Value.TimeZone.Offset; // <- 8 ... 9 から 8 に上書きされた!
settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[1].Text; // <- "Bar"

Windows OS 上で Visual Studio を用いて開発・実行している場合は、Visual Studio の画面上、プロジェクトのプロパティ画面から環境変数を設定することもできる。 ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション_d0079457_23144057.png

ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション_d0079457_23144057.png

このやり方だと、環境変数の設定を変更して保存 (Ctrl +S) すると、Visual Studio が自動で ASP.NET Core アプリのプロセスを再起動してくれ、アプリケーション構成が再読み取りされて、設定内容が即反映されるのだ。

appSettings.json 及び appSettings.Develop.json を編集・保存した場合は、そのようなプロセス再起動をはじめ、自動でアプリケーション構成を再読み取りされることはないようである。

(どこかで、appSettings.Develop.json が変更されたら再読み取りするオプション指定を見かけたような気もするのだが。)

ちなみに、こうして Visual Studio 上から設定した環境変数設定は、プロジェクトのフォルダ以下、Properties フォルダ内の launchSettings.json 内に書き込まれる。

「dotnet run」で実行する際も、この launchSettings.json の内容は読み取られて使われる。

なので、launchSettings.json に環境変数を設定しておいて「dotnet run」で実行すると、その環境変数設定が反映されて実行される。

ご参考までに。

また、これも至極当然のことではあるが、こうして環境変数で上書きする際も、セクション名 (環境変数名) の英字の大小は区別されない。

Microsoft Azure の App Service 設定での "上書き"

実は、Microsoft Azure の App Service 上に Web アプリを配置したときに、Azure ポータルから「アプリケーション構成」で設定する値も、アプリ側には環境変数として現れる。

なので、この仕組みで、ASP.NET Core アプリのアプリケーション構成を Azure ポータルから上書き設定することができるのだ。

その際のセクション名の指定方法は、上記のとおりコロン区切りでセクション名を連結した名前を、Azure ポータル「アプリケーション構成」の欄の "APP SETTING NAME" のところに指定してやれば良い。 ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション_d0079457_23263924.png

ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション_d0079457_23263924.png

"上書き" というよりは "合成" と言ったほうがイメージあってる?

これら "上書き" の動作だが、優先順位としては次のとおり。

環境変数 > appSettings.Develop.json > appSettings.json

上記3者で同じセクション名で異なる値をそれぞれ設定していた場合、環境変数による設定が勝つ。

また、"上書き" とは言ったが、appSettings.json 内に記述のないセクション名のアプリケーション構成を、環境変数で設定してあれば、アプリ側ではちゃんと読み取れる。

例えば appSettings.json に SiteSettings.Title がなくても、

"SiteSettings": {
  "TimeZone": { // <- "Title" プロパティがない!
  ...

環境変数 "SiteSettings:Title" に "HELLO!" が設定されていれば、アプリ側ではちゃんと読み取れる。

settings.Value.Title; // <- "HELLO!" ... 環境変数での設定が見えている!

なお、上記のような例を見ると、appSettings.json に存在しないセクションなので、存在しないものに対して "上書き" という言い方には違和感を覚えるかもしれない。

上書きというよりかは、Key-Value の辞書のツリーを "合成" (マージ) していくようなイメージのほうが理解しやすいかもしれない。

よくよく考えたら、環境変数を読むのに使えたり。

ここまでを振り返ってよくよく突き詰めて考えてくと、実は ASP.NET Core のアプリケーション構成の仕組みで、環境変数がまるっと取得できてしまったりもするのだ。

ここまで紹介してきた例では、Startup にて、"Configuration.GetSection("SiteSettings")" と設定していたので、すべての環境変数は見えず、"SiteSettings:～" で始まる名前の環境変数だけ見えていた。

これを改め、単に "Configuration" オブジェクトそのものを渡してバインドすれば、すべての環境変数値がバインド可能だ。

また、ASP.NET Core アプリケーション構成の仕組みは、必ずしも静的型付けしなくては使えないわけではなく、Configuration オブジェクトを参照し、その GetValue などのメソッドを使って、文字列でセクション名 (= 環境変数名) を指定して取得することもできる (下記など参考に)。

本来の用途ではないが、ASP.NET Core のアプリケーション構成の仕組みを介して、プロセスの環境変数をすべて参照することも可能だ。

ところで、コレクションって何にバインドできる?

ところで、今回の例にある、"Tags" セクションは、JSONN 上、配列になっており、これのバインド先の SiteSettings クラスでも配列としている。

public class SiteSettings {
  ...
  public TagSettings[] Tags ... // <- TagSettings 型の "配列"
  ...

試したところ、実はここ、配列じゃなくても大丈夫だった。

"List<T>" でも "IEnumerable<T>" でも "ICollection<T>" でもバインドできた。

public class SiteSettings {
  ...
  public IEnumerable<TagSettings> Tags ... // <- これでも OK!
  ...

果たして "T[]"、"List<T>"、"IEnumerable<T>"、"ICollection<T>"、etc. のいずれでバインドするのが最適なのか、自分にははっきりとは判断つきかねる。

ただ、どちらかといえばいちばん書き換えできなさそうな "IEnumerable<T>" がいいのかなぁ、と漠然と考えている。

環境変数からコレクションの設定を上書きするには?

さて今回の例の "Tags" セクション内の配列構成を、環境変数で上書きするには、どのような変数名を指定すればよいのだろう?

最初は、"SiteSettings:Tags[0]:Text" というような、C# や JavaScript などでよくあるインデクサ表記を環境変数名とすることで上書きできるのかと考えた。

が、試したところこれは間違い。

正解は "SiteSettings:Tags:0:Text" だ。

これは "JavaScrit 的な考え方" に慣れてるとわかりやすいと思う。

すなわち、配列の要素を、例えば0番目の要素であれば「Tags オブジェクトの、"0" という名前のプロパティ」というように捉えるのだ。

今回の例の、上書き前のオリジナルの appSettings.json の構成内容だと、Tags プロパティの内容は下記のとおりとなっている。

settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[0].Priority; // <- 0.7
settings.Value.Tags[1].Text; // <- "Bar"
settings.Value.Tags[1].Priority; // <- 0.3

ここで環境変数 "SiteSettings:Tags:1:Text" に "Hoge" を設定すると、下記のとおり上書きされる。

settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[0].Priority; // <- 0.7
settings.Value.Tags[1].Text; // <- "Hoge" ... "Bar" から上書きされた!
settings.Value.Tags[1].Priority; // <- 0.3 ... ここはそのまま!

上書き前の配列要素数を超えたら...?

さて、では今回の例において、環境変数 "SiteSettings:Tags:999:Text" に "Hoge" を設定したらどうなるのか!?

アプリ側で読み取った結果はこうなった。

settings.Value.Tags[0].Text; // <- "Foo"
settings.Value.Tags[0].Priority; // <- 0.7
settings.Value.Tags[1].Text; // <- "Bar"
settings.Value.Tags[1].Priority; // <- 0.3

// Tags[2] が増えた!
settings.Value.Tags[2].Text; // <- "Hoge"
settings.Value.Tags[2].Priority; // <- 0.0

一瞬戸惑ってしまったが、改めて JavaScript 脳になって考えてみると、何のことはない、環境変数名の "999" は「配列の添え字」ではなく、プロパティ名なのだ。

どうやら、ASP.NET Core のアプリケーション構成の仕組みは、バインド先の型がコレクションである場合、バインド元の値の "プロパティ" を列挙して、その値を順繰り、バインド先のコレクションの要素に編成しているようである。

配列、じゃなくて、結局は Key-Value の辞書である

なので、数字だけじゃなくて、任意の識別子を当てはめられる。

例えば環境変数名を、"SiteSettings:Tags:999:Text" ではなく、"SiteSettings:Tags:FizzBuzz:Text" としても、結果は同じになるのだ。

また、環境変数からの上書きというのではなく、appSettings.json の記述そのものを辞書形式で記述することもできる。

"SiteSettings": {
  ...
  "Tags": [
    { "Text": "Foo", "Priority": 0.7 },
    { "Text": "Bar", "Priority": 0.3 }
  ]
  ...

は、アプリケーション構成的観点では以下のように記述してるのと同義と言える。

実際、アプリでの読み取り結果も変らなかった。

"SiteSettings": {
  ...
  "Tags": {
    "0": { "Text": "Foo", "Priority": 0.7 },
    "1": { "Text": "Bar", "Priority": 0.3 }
  }
  ...

さらには、プロパティ名 (Key) は数字である必要すらない。

下記でも TagSetting[] にバインドされ、読み取り結果は変わりない。

"SiteSettings": {
  ...
  "Tags": {
    "Alpha": { "Text": "Foo", "Priority": 0.7 },
    "Omega": { "Text": "Bar", "Priority": 0.3 }
  }
  ...

ちなみに、上記のような感じで Key-Value 辞書オブジェクトをコレクションにバインドした場合、その要素の追加順序は、プロパティ名 (Key) のオーダーとなるようだ。

削除はできなさそう

なお、このような仕掛けであるようなので、appSettings.json で設定した配列構成要素を、appSettings.Develop.json や環境変数から "削除" することはできなさそうだ。

例えば今回の例において、appSettings.Develop.json を以下のとおり記述し、Tags の設定内容を要素数 0 件に潰そうとしたとする。

"SiteSettings": {
  ...
  "Tags": [] // オリジナルの Tags 構成値を0件にしてやる!
  ...

しかしこれは意図したとおりには動作しない。

配列ではなく、"0" や "1" といった配列序数を名前としたプロパティを持つオブジェクトを "上書き" するのだ、と JavaScript 脳で考える必要がある。

JavaScript で言うならば、オリジナルの Tags オブジェクトに対し、空のオブジェクトで Object.assign するようなものだ。

var tags = {"0":{...}, "1":{...}};
var tagsDevlop = {}; // "Tags":[] は空オブジェクトと同義

// 空オブジェクトを assign しても、tags は何の変化もなし!
Object.assign(tags, tagsDevelop);

結果として、上記 appSettings.Develop.json は、何の効果ももたらさないこととなる。

そう、JavaScript の Object.assign を知っているならば、ASP.NET Core アプリケーション構成の "上書き" の仕組みは、Object.assign であると考えると間違いがないだろう。

まとめ

以上、ASP.NET Core のアプリケーション構成の上書き (というか、"合成") の振る舞いについて色々試した結果となる。

ざっくりおさらいすると下記のとおり。

英字の大文字・小文字は区別されない。
appSettings.Develope.json より環境変数のほうが勝つ。
環境変数ではセクション名をコロンで区切って設定。
Visual Studio での環境変数設定は Properties\launchSettings.json ファイルに保存される。
コレクションのバインド先は "T[]", "List<T>", "IEnumerable<T>", "ICollection<T>" のいずれでも OK。
環境変数でコレクションの要素を上書きするには、序数をプロパティ名として設定。
コレクションもその正体は、"0" や "1" といった序数をプロパティ名とした JavaScript オブジェクト (辞書) であるだけ。
なので、序数じゃない任意の識別子も指定できちゃう - その場合、プロパティ名 (Key) のオーダーでコレクションが編成される。
結局、JavaScript の Object.assign() で重ね書きしてる感じ。
なので、appsettings.json に設定済みの要素を、削除することはできないと思われる。

あと、最後になってしまったが補足しておくと、ここまでのアプリケーション構成の仕組みは ASP.NET Core アプリに限らず、Microsoft.Extensions.Options でアプリケーション構成を扱う .NET アプリ全てに適用される。

今回の投稿はかなりの大作となってしまった。

これでアプリケーション構成の "上書き" で迷うことはなくなった...と思いたい。

▲ by developer-adjust | 2018-09-28 23:29 | .NET | Comments(0)

2018年 06月 29日

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?

HTTPS プロトコルでのアクセスを強制する

ASP.NET Core 2.1 から登場した、Microsoft.AspNetCore.HttpsPolicy NuGet パッケージにて提供されている HttpsRedirection ミドルウェアを使うと、ASP.NET Core 2.1 Web サイト/アプリに、HTTP プロトコルでのアクセスがあったら HTTPS プロトコルのアクセスにリダイレクトさせる機能を実装できる。

例えば Visual Studio IDE 2017 で開発している場合は、Visual Studio IDE のプロジェクト新規作成のダイアログにて、この HTTPS リダイレクト機能込みでプロジェクトを作成する選択肢が用意されている。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18505533.png

こうして作成した ASP.NET Core 2.1 Web アプリの Startup.cs を覗いてみると、Configure メソッド内にて、「app.UseHttpsRedirection()」というように、HttpsRedirection ミドルウェアの組み込みを行っている行があるのがわかる。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18505199.png

この状況で、ローカル開発環境で実行してみると、たしかに http://localhost:... のアクセスは https://localhost:... へのアクセスにリダイレクトされている。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18504680.png

Azure Web Apps 上では、デプロイするだけでは NG

それではこの ASP.NET Core 2.1 Web アプリを Azure Web App に発行してみたらどうなるか。

残念ながら (?)、それだけでは HTTPS プロトコルへのリダイレクトは機能しない。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18504183.png

ドキュメントを確認してみると、HttpsRedirect ミドルウェアによる HTTPS プロトコルへのリダイレクトは、ある一定の条件が必要らしい。

ここでは、「環境変数 ASPNETCORE_HTTPS_PORT に、HTTPS プロトコルで接続するときのポート番号が指定されている場合」を、Azure Web Apps に適用して、HTTPS プロトコルへのリダイレクトが発動するように試してみた。

具体的には、Azure ポータル上から、当該 Web App のアプリケーション構成の設定ブレードを開き、下図のように HTTPS_PORT = 443 (※ポート番号 443 は HTTPS プロトコルの標準のポート番号) に設定する。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18503398.png

こうすると、Azure Web Apps 上に発行後でも、HTTPS プロトコルへのリダイレクトが機能するようになった。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?_d0079457_18530444.gif

以上！

▲ by developer-adjust | 2018-06-29 19:02 | .NET | Comments(0)

2018年 02月 27日

ASP.NET Core SignalR - サーバー側で配列を渡して InvokeAsync しても、JavaScript 側で第1要素しか受け取れない?

シナリオ

.NET 版 Web アプリサーバー側フレームワークである ASP.NET Core で実装したWebアプリにおける、サーバー側からもクライアント側への呼び出しを行なうことのできる "Real time Web" 実装、ASP.NET Core SignalR。

今回はその ASP.NET Core SignalR を使っていて遭遇したトラブルとその回避方法の話である。

下記記事のコード例を基に話を進めよう。

但し、上記記事のコード例では、単一文字列を送受信していたところを、文字列の配列に変えてみたのが、今回のテーマ。

サーバー側実装は、上記記事のコード例に対し、下記強調表示のとおり書き換える。

public class Chat : Hub
{
    public Task Send(string[] messages)
    {
        return Clients.All.InvokeAsync("Send", messages);
    }
}

すなわち、クライアント側からサーバー側へ送信された文字列の配列を、そのまま文字列の配列のまま、クライアント側に送り返す実装だ。

クライアント側も同様に下記要領で、SignalR 接続が開設したら、単一文字列 "Hello" を送信していたところを、["Hello", "World"] の文字列の配列を送信するようにする。

且つ、受信した内容を console.log で開発者コンソールに表示する際に、合せてその受信内容の型も表示するようにしてみる。

let connection = new signalR.HubConnection('/chat');

connection.on('send', data => {
    console.log(typeof (data))
    console.log(data);
});

connection.start()
    .then(() => connection.invoke('send', ['Hello', 'World']));

さて、このように手を加えたサンプルコードを実行、ブラウザで開くと、サーバー側からクライアント側に送信された内容が開発者コンソールに表示される。

その内容の期待値は、文字列の配列を送受信しているわけだから、当然下記のようなものとなる。

> object
> ["Hello", "World"]

ところが実際にやってみると、その実行結果は下記のとおりとなった。

> string
> "Hello"

サーバー側からは文字列の配列をクライアント側へ送信しているのに、それを受け取ったクライアント側では、なぜか第1要素のみが受信ハンドラの引数に渡されているのである。

これはおかしいと、ブラウザの開発者コンソールにて通信内容を確認してみた。

すると、なんと、下図（蛍光マーカー表示の箇所）のとおり、サーバー側からは単一文字列が2引数で送信されているように見える。当方の期待するところとしては、ここは ["Hello", "World"] ではなく、[ ["Hello", "World"] ] である。 ASP.NET Core SignalR - サーバー側で配列を渡して InvokeAsync しても、JavaScript 側で第1要素しか受け取れない?_d0079457_08543074.png

ASP.NET Core SignalR - サーバー側で配列を渡して InvokeAsync しても、JavaScript 側で第1要素しか受け取れない?_d0079457_08543074.png

原因

原因は、サーバー側実装にあった。

SignalR における、サーバー側からクライアント側への送信に用いる InvokeAsync メソッドなのだが、これが可変個引数を扱うために object[] を引数にとるようになっている (下記)。

namespace Microsoft.AspNetCore.SignalR
{
    public interface IClientProxy
    {
        Task InvokeAsync(string method, object[] args);
    }
}

このため、愚直に配列をクライアント側へ送信しようと思って InvokeAsync メソッドの第二引数に渡すと、
配列を引き渡したいつもりが可変個引数として扱われてしまっていた
という訳だ。

ちなみに、InvokeAsync メソッドには拡張メソッドによるオーバーロードバージョンも用意されている (下記)。

using System.Threading.Tasks;

namespace Microsoft.AspNetCore.SignalR
{
  public static class IClientProxyExtensions
  {
    public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1);
    public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1, object arg2);
    public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1, object arg2, object arg3);
    ...    // 以降、10引数まで続く
}

このオーバーロードバージョンによって、n 個引数での InvokeAsync 呼び出しの際、

InvokeAsync("method", new object[]{ "taro", 24 })

と書かずに

InvokeAsync("method", "taro", 24)

と略して書けるようになっている。

回避方法

回避方法はいくつかある。

「可変個引数のうち、第一引数に、文字列の配列を渡しますよ」ということを、略記せずにきっちり記述することで回避できる。

InvokeAsync("Send", new []{ // 可変個引数を表す配列
  messages // その第1要素(第1引数) に、文字列の配列を渡す
});

いちばん直球勝負で正直な実装方法だが、ちょっとくどい。

あるいはまた、「object[] args」のシグネチャにマッチするのを回避しつつ、クライアント側 JavaScript では配列として扱われる List<T> に変換してから渡す方法もある。

// LINQ の ToList 拡張メソッドで List<T> に変換してから渡すことで、
// InvokeAsync(string, object arg1) の拡張メソッドに適合するようにする。
InvokeAsync("Send", messages.ToList());

いったん List<T> を生成するのでメモリ効率的に気持ち悪いが。

はたまた、「object[] args」のシグネチャにマッチしなければよいので、InvokeAsync(string, object arg1, object arg2) などにマッチするよう、ダミーの引数を付加することもできよう。

InvokeAsync("Send", message, "dummy");

しかし、前者でさえ「なぜわざわざ List<T> にするの?」という点で可読性低いのに、このダミー引数版はさらに可読性ダダ下がりな感じで、個人的には採用したくない手法。

「object[] args」のシグネチャにマッチしないようにオーバーロードバージョンの使用を誘導するのであれば、as 演算子で型を指定することもできる。

// as 演算子で object 型にアップキャストすることで、
// InvokeAsync(string, object arg1) の拡張メソッドに適合するようにする。
InvokeAsync("Send", message as object);

クライアント側実装もあわせて変えてよければ、同じく「object[] args」のシグネチャにマッチしないよう、匿名型オブジェクトにくるむ方法もある。

InvokeAsync("Send", new {messages});

クライアント側はこうなる。

connection.on('send', data => {
    console.log(data.messages);
});

ざっと思いつく回避方法はこんなところだ。

ちなみに可変個引数は、例えば string.Format メソッドとかをはじめ、いろいろなところでよく使われる一般的な技法ではある。

ただ、例えば string.Format では配列を書式化したいとかいう需要がさほどないであろうから、そんな感じであまり問題にはならないのだろう。

まとめ

以上、こんな感じで回避はできる。

とはいえ、やっぱり「なんでそのまま引数に渡さずにコネコネしてるの？」というように可読性は低いし、将来の保守で壊してしまったり、あるいは新規実装でもたびたびこのワナに陥りそうでちょっと嫌ではある。

ということで、この件は GitHub 上の Issue でもちょうど検討中らしい。

ASP.NET Core SignalR は、まだ Alpha バージョンである。

この件に関しても今後、何かしら変更や改善など進展が見られるかもしれない。

注目しておこうと思う。

▲ by developer-adjust | 2018-02-27 12:39 | .NET | Comments(0)