WebSurfer's Home

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

ユーザー対話モード

by WebSurfer 2022年9月18日 13:58

IIS でホストされる ASP.NET Web アプリはユーザー対話モードでは動かないという話を書きます。

Environment.UserInteractive

ASP.NET Web アプリを、開発環境で Visual Studio から実行して IIS Express 上で動かすと期待通り動くが、運用環境で IIS にデプロイすると動かないという話を耳にします。

その原因のほどんどは、(1) ワーカープロセスのアクセス権の違い、(2) プロセスがユーザー対話モードで動いているか否かです。(加えて、Session 0 分離による制約もあります。詳しくは、Microsoft の文書 Impact of Session 0 Isolation on Services and Drivers in Windows を見てください)

開発環境の時は、PC にログインしたアカウントで Visual Studio を起動しているので、(1) は PC にログインしたユーザーアカウントの権限、(2) はユーザー対話モードになっています。

運用環境で IIS にデプロイした時は、(1) はデフォルトでは Network Service または AppPoolIdentity という権限が低いアカウント、(2) は非ユーザー対話モードです。

ユーザー対話モードにならないということは、ユーザーが対話するためのグラフィカルユーザーインターフェイスが存在しないということで、モーダルダイアログやメッセージボックスは表示できません。

ワーカープロセスのアカウントは WindowsIdentity.GetCurrent メソッドで、ユーザー対話モードで実行されているか否かは Environment.UserInteractive プロパティで調べることができます。上の画像の赤枠部分が Windows 10 の IIS 10 でホストされる ASP.NET Web Forms アプリで調べた結果です。

上記 (1) の権限の問題は、Network Service または AppPoolIdentity に必要な権限を与えるとか、権限を持つアカウントを偽装するとかで解決します。

または、以下の画像のように IIS Manager を操作して、プロセスモデルの ID に必要な権限を持つユーザーアカウントを設定することでも解決できます。

ワーカープロセスのアカウント変更

しかし、(2) のユーザー対話モードについてはそれでは何ともなりません。ユーザー対話モードにする手段は少なくとも自分が調べた限りでは無かったです。

実は、上の画像のようにプロセスモデルの ID に管理者権限を持つユーザーアカウントを設定すれば Environment.UserInteractive が True(=ユーザー対話モード)になると思い違いしていました。

昔の Teratail のスレッド「WebBrowserの動作に影響するPC環境の相違点」に回答する際調べたことなのですが、すっかり忘れていたので備忘録として残しておくことにした次第です。

Tags: , ,

ASP.NET

要求の中断による処理のキャンセル (MVC5)

by WebSurfer 2021年7月12日 10:30

.NET Framework 版の ASP.NET Web アプリで、クライアントによる要求の中断を検出してサーバー側の処理をキャンセルする話を書きます。(ASP.NET Core の場合は先の記事「要求の中断による処理のキャンセル (CORE)」を見てください)

要求の中断

クライアントによる要求の中断とは、上の画像の赤丸印の中のブラウザの ✕ ボタンをクリックするとか Esc キーを押す、Ajax を使っての要求の場合は XMLHttpRequest.abort() メソッドを実行することを意味します。

ASP.NET 4.5 以降には HttpResponse.ClientDisconnectedToken プロパティが追加されています。このプロパティで取得できる CancellationToken によって、クライアントが要求の中断操作を行った場合に操作を取り消す通知を配信できます。(ASP.NET Core の HttpContext.RequestAborted プロパティと同様)

ただし、ASP.NET 4.5 以降という条件以外にも、上に紹介した Microsoft のドキュメントに書いてあるように IIS 7.5 以降の統合モードでのみサポートされているということですので注意してください

Visual Studio 2019 を使って、以下のコードを [デバッグ(D)] ⇒ [デバッグの開始(S)] で IIS 10 Express で実行して検証してみました。検証に使用したブラウザは Edge v91.0.864.67, Chrome v91.0.4472.124, Firefox v89.0.2, IE11, Opera v77.0.4054.203 で、いずれもクライアントによる要求の中断によってサーバー側での処理の中断が確認できました。

using System;
using System.Web.Mvc;
using System.Threading.Tasks;
using System.Diagnostics;

namespace Mvc5App2.Controllers
{
    public class HomeController : Controller
    {

        // ・・・中略・・・

        public async Task<ActionResult> Cancel()
        {
            var token = Response.ClientDisconnectedToken;

            Debug.WriteLine($"start: {DateTime.Now:ss.fff}");
            await Task.Delay(5000, token);
            Debug.WriteLine($"end: {DateTime.Now:ss.fff}");
            return View();
        }
    }
}

ASP.NET Core MVC と違ってアクションメソッドの引数に CancellationToken を追加しても ClientDisconnectedToken プロパティで取得される CancellationToken はバインドされないので注意してください。なので、上のコードのようにする必要があります。(引数に追加すると CancellationToken がバインドされますが、それは ClientDisconnectedToken プロパティで取得できるものとは別物のようで要求の中断による通知は出ません)

上のコードの Task.Delay(5000, token) では渡した token を Deley メソッドの中で継続的に観察しているようで、このメソッドが実行が開始された後でもそれから 5 秒以内ならブラウザで要求を中断すると TaskCanceledException がスローされて処理が終わります。

ただし、Entity Framework を使ってデータベースにアクセスして処置を行うときに使う ToListAsync とか SaveChangesAsync などや、HttpClient の SendAsync とか PostAsync なども同様かどうかは調べてなくて分かりません。今後の検討課題ということで・・・

Tags: , , ,

ASP.NET

要求の中断による処理のキャンセル (CORE)

by WebSurfer 2021年7月11日 13:07

IIS を使ってのインプロセス ホスティング モデル(この記事の下の方の図参照)でホストされる ASP.NET Core Web アプリは、クライアントによる要求の中断を検出してサーバー側の処理をキャンセルすることができます。(.NET Framework 版の ASP.NET の場合は別の記事「要求の中断による処理のキャンセル (MVC5)」を見てください)

要求の中断

クライアントによる要求の中断とは、上の画像の赤丸印の中のブラウザの ✕ ボタンをクリックするとか Esc キーを押す、Ajax を使っての要求の場合は XMLHttpRequest.abort() メソッドを実行することを意味します。

処理のキャンセルには HttpContext.RequestAborted プロパティで取得できる CancellationToken を利用します。クライアントが上に書いた要求の中断操作を行うと、取得した CancellationToken は操作を取り消す通知を配信します。

キャンセル処理は基本的に先の記事「非同期タスクのキャンセル」に書いたことと同様で、以下のようになると思います。

  1. HttpContext.RequestAborted プロパティで CancellationToken を取得しキャンセルをリッスンするタスクに渡す。(CancellationToken の取得先の CancellationTokenSource の初期化等は ASP.NET Core フレームワークがやってくれるようです)  
  2. タスクにはキャンセルをリッスンして適切に処置を行うコードを実装しておく。
  3. クライアントによる要求の中断が検出されると、フレームワークは CancellationTokenSource.Cancel メソッドを呼び出し、CancellationToken を通じてリッスンしているタスクにキャンセルを通知する。
  4. キャンセル通知を受けたタスクは、あらかじめ実装されているコードに従ってキャンセル処置を行う。  

CancellationToken を渡す方法ですが、ネットで見つけた記事 Handling aborted requests in ASP.NET Core に書いてある通り、渡し先のタスクが MVC や Web API のアクションメソッドであれば引数に CancellationToken を追加しておけば、それに HttpContext.RequestAborted から取得した CancellationToken をモデルバインドしてくれます。

検証は Visual Studio 2019 を使って、以下のコードを [デバッグ(D)] ⇒ [デバッグの開始(S)] で IIS 10 Express のインプロセスホスティングで実行して行いました。検証に使用したブラウザは Edge v91.0.864.67, Chrome v91.0.4472.124, Firefox v89.0.2, IE11, Opera v77.0.4054.203 で、いずれもこの記事を書いた時点での最新版です。

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using MvcCore5App4.Models;
using System.Diagnostics;
using Microsoft.AspNetCore.Authorization;
using System.Threading;
using System.Threading.Tasks;
using System;
using Microsoft.AspNetCore.Identity;
using MvcCore5App4.Data;

namespace MvcCore5App4.Controllers
{
    public class HomeController : Controller
    {
        private readonly ILogger<HomeController> _logger;

        public HomeController(ILogger<HomeController> logger)
        {
            _logger = logger;
        }

        // ・・・中略・・・

        public async Task<IActionResult> Cancel(CancellationToken token)
        {
            _logger.LogInformation($"start: {DateTime.Now:ss.fff}");
            await Task.Delay(5000, token);
            _logger.LogInformation($"end: {DateTime.Now:ss.fff}");
            return View();
        }
    }
}

上のコードの Task.Delay(5000, token) では渡した token を Deley メソッドの中で継続的に観察しているようで、このメソッドが実行が開始された後でもそれから 5 秒以内ならブラウザで要求を中断すると TaskCanceledException がスローされて処理が終わります。

Entity Framework を使ってデータベースにアクセスして処置を行うときに使う ToListAsync とか SaveChangesAsync などや、HttpClient の SendAsync とか PostAsync なども同様かというのが問題と思いますが、詳しくは調べてなくて分かりません。

ToListAsync(token) メソッドで少し調べてみた限りでは、ToListAsync(token) の次の行で CancellationTokenSource.Cancel() としても完了してしまいました。Task.Delay(5000, token) と違って即終わってしまうので間に合わないのか、走り出したらキャンセルは効かないということなのかは分かりません。

ホスティングモデルによる違いですが、Visual Studio 2019 で IIS 10 Express を使ってのアウトプロセス ホスティング モデルでは要求の中断による処理のキャンセルはできませんでした。

Microsoft のドキュメント「インプロセスおよびアウトプロセス ホスティングの相違点」にインプロセス ホスティングでは "クライアントの切断が検出されます。 クライアントが切断されると、HttpContext.RequestAborted キャンセル トークンが取り消されます" と書いてあります。裏を返すとアウトプロセスホスティングではダメと言っているようです。

構成の違いは以下の図(Microsoft のドキュメントから借用)の通りですが、IIS では切断は検出されるものの Kestrel との間は HTTP 通信なので Kestrel に切断を伝えるすべがないということではないかと思います。ちなみに IIS をリバースプロキシとして使わず Kestrel をエッジサーバーとした場合はインプロセスホスティングと同様に切断は検出されキャンセルも効きます。

インプロセス ホスティング

インプロセス ホスティング モデル

アウトプロセス ホスティング

アウトプロセス ホスティング モデル

IIS を使える環境で Kestrel をエッジに使うことはなさそうですし、Linux 系の OS の場合は Nginx とか Apache をリバースプロキシに使って、Kestrel で ASP.NET Core アプリをホストする、即ち IIS を使ってのアウトプロセスホスティングと同じ構成になるので、結局は IIS を使っての インプロセスホスティングモデルでないとキャンセルはできないということではないかと思います。

Tags: , , , ,

CORE

About this blog

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

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar