WebSurfer's Home

Filter by APML

Fiddler が利用するサーバー証明書の更新

by WebSurfer 23. July 2024 15:51

Fiddler は、ブラウザなどの HTTP 通信を行うアプリケーションと Internet / Intranet の間の要求・応答をキャプチャして表示してくれる、Web アプリ開発には欠かせないツールです。(注: この記事は Windows OS 専用の Fiddler Classic の話です)

Fiddler Classic

HTTPS 通信もキャプチャ・復号して内容を表示してくれますが、そのために Fiddler は、Fiddler とクライアントの間に独自のサーバー証明書を利用します。

下の画像で赤枠で囲った DO_NOT_TRUST_FiddlerRoot がそれで、Fiddler のオプション設定によって「信頼されたルート証明機関」にインストールされます。

DO_NOT_TRUST_FiddlerRoot.jpg

証明書 NOT_TRUST_FiddlerRoot には有効期限があります。自動的には更新してくれないので、忘れた頃に突然証明書が無効だというエラーが出て焦ることになると思います。

下の画像がそれで、Fiddler を起動して、Visual Studio で起動した Web アプリを Chrome から呼び出して表示しようとしたら NOT_TRUST_FiddlerRoot の有効期限切れでエラーになったというものです。

ERR_CERT_DATE_INVALID

上の画像の NET::ERR_CERT_DATE_INVALID をクリックすると Subject:localhost 以下の詳細情報が表示されますので、その中の Issuer でどの証明書に問題があるのかが分かります。

(ちなみに、Fiddler と Web サーバーの間は別の証明書を使っており、それが開発用の証明書の場合は有効期限が切れることがままあって、その場合は Issuer が上の画像の DO_NOT_TRUST_FiddlerRoot とは異なるので分かります)

NOT_TRUST_FiddlerRoot の有効期限を延長するにはどうするかと言うと、Fiddler のツールバーの [Tools] ⇒ [Options] をクリックして Options ダイアログを開き、[HTTPS] タブの [Actions] ボタンをクリックしてプルダウンを表示し、[Reset All Certificates] をクリックしてやります。

Reset All Certificates

その先は表示される案内に従って進めていけば、「信頼されたルート証明機関」にインストールされた古い NOT_TRUST_FiddlerRoot 証明書が削除され、有効期限が延長された新しい証明書がインストールされます。

その際、[Decrypt HTTPS traffic] のチェックが外れることがあるようで、確認して外れていてらチェックを入れてください。

以上でエラーは解消できて、HTTPS 通信のトラフィックをキャプチャして表示できるようになるはずです。

Tags: , , ,

DevelopmentTools

ASP.NET Core Web API に Role ベースの承認を追加

by WebSurfer 20. July 2024 13:34

トークンベース (JWT) の認証を実装した ASP.NET Core Web API に Role による承認を追加する話を書きます。(認証と承認は違いますのでご注意ください)

クッキーベースの ASP.NET Identity 認証システムを実装した ASP.NET Web アプリでは、認証に加えて承認によるアクセスコントロールが可能です。承認には Role が使われます。例えばサイト管理者がマネージャー・ゲスト・管理者・メンバーなどといった Role を定義し、ユーザー別に Role をアサインすることにより細かいアクセスコントロールが可能になっています。

例えばアクションメソッドに [Authorize(Roles = "Admin")] という属性を付与したとすると、ユーザーが有効な ID とパスワードでログインして認証は通っていたとしても、Admin という Role を持っていないと承認されず、ユーザーはそのアクションメソッドにはアクセスできなくなります。

それは JWT ベースの認証機能を実装した Web API でも同様です。先の記事「Blazor WASM から ASP.NET Core Web API を呼び出し」で紹介した WeatherForecastController コントローラの Get() メソッドで、以下のように [Authorize] 属性を [Authorize(Roles = "Admin")] に変更してから Blazor アプリからアクセスすると、

// [Authorize]
[Authorize(Roles = "Admin")]
[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()
{
    return Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
        TemperatureC = Random.Shared.Next(-20, 55),
        Summary = Summaries[Random.Shared.Next(Summaries.Length)]
    })
    .ToArray();
}

以下の画像のように HTTP 403 Forbidden 応答 (サーバーは要求を理解しましたが、要求の実行を拒否しています・・・と言う意味) が帰ってきてデータの取得に失敗します。ちなみに、認証が通らない場合は HTTP 401 Unauthorized 応答が返ってきます。

HTTP 403 応答

上の画像の #11 では、Blazor アプリからは有効な ID とパスワードが送信されるので認証は通ってトークンが返ってきています。そして、#13 でそのトークンを要求ヘッダに含めて上のアクションメソッド Get に要求をかけています。その結果、サーバー側では認証には成功するものの Admin ロールを持っていないので承認が通らず HTTP 403 応答が返ってきています。

Role による承認が通るようにするには、上の画像の #11 で返されるトークンに Admin ロールを持っているという情報を含める必要があります。それにはトークンを生成する際、Claims 情報として Admin ロールを追加してやります。

具体的には、先の記事「Blazor WASM から ASP.NET Core Web API を呼び出し」で紹介したトークンを発行する API の BuildToken メソッドで、以下のように Admin ロール情報を Claims に追加します。

private string BuildToken()
{
    var key = new SymmetricSecurityKey(
        Encoding.UTF8.GetBytes(_config["Jwt:Key"]!));

    var creds = new SigningCredentials(
        key, SecurityAlgorithms.HmacSha256);

    var token = new JwtSecurityToken(
        issuer: _config["Jwt:Issuer"],
        audience: _config["Jwt:Issuer"],

        // Admin ロール情報を Claims に追加
        claims: [ new Claim(ClaimTypes.Role, "Admin") ],

        notBefore: null,
        expires: DateTime.Now.AddMinutes(30),
        signingCredentials: creds);

    return new JwtSecurityTokenHandler().WriteToken(token);
}

これにより発行されるトークンには Admin ロールを持っているという情報が含まれます。以下の画像は発行されたトークンを JWT というサイトでデコードしたものです。赤枠部分を見てください。

Admin ロール情報を含む JWT

そのトークンを要求ヘッダに含めて要求をかければ承認が通って、下の画像の #6 の通りデータが返され、

200 応答

Blazor アプリには期待通り結果が表示されます。

Blazor アプリの結果の表示

Tags: , , , ,

Web API

React アプリから ASP.NET Core Web API を呼び出し

by WebSurfer 2. July 2024 15:36

React アプリから、トークン (JWT) ベースの認証が必要な ASP.NET Core Web API にクロスドメインでアクセスしてデータを取得するサンプルを作ってみました。

結果の表示

先の記事「Blazor WASM から ASP.NET Core Web API を呼び出し」の Blazor WASM アプリを React アプリに代えただけです。

Web API アプリの作り方は先の記事に詳しく書きましたのでそちらを見てください。

React アプリは、Visual Studio 2022 v17.10.3 のテンプレートを使って「新しいプロジェクトの作成」ダイアログで「React and ASP.NET Core」のテンプレートを選び、ターゲットフレームワーク .NET 8.0 で作成したものです。

その中の .client プロジェクトの src\App.jsx ファイルの populateWeatherData メソッドに以下のように手を加えて、先の記事の Web API を呼び出すようにしています。その結果が上の画像です。

import { useEffect, useState } from 'react';
import './App.css';

function App() {
    const [forecasts, setForecasts] = useState();

    useEffect(() => {
        populateWeatherData();
    }, []);

    const contents = forecasts === undefined
        ? <p><em>Loading... Please refresh once the ASP.NET backend has started.</em></p>
        : <table className="table table-striped" aria-labelledby="tabelLabel">
            <thead>
                <tr>
                    <th>Date</th>
                    <th>Temp. (C)</th>
                    <th>Temp. (F)</th>
                    <th>Summary</th>
                </tr>
            </thead>
            <tbody>
                {forecasts.map(forecast =>
                    <tr key={forecast.date}>
                        <td>{forecast.date}</td>
                        <td>{forecast.temperatureC}</td>
                        <td>{forecast.temperatureF}</td>
                        <td>{forecast.summary}</td>
                    </tr>
                )}
            </tbody>
        </table>;

    return (
        <div>
            <h1 id="tabelLabel">Weather forecast</h1>
            <p>This component demonstrates fetching data from the server.</p>
            {contents}
        </div>
    );
    
    async function populateWeatherData() {
        // 自動生成されたコード
        //const response = await fetch('weatherforecast');
        //const data = await response.json();
        //setForecasts(data);

        // ・・・を、以下のように書き換える

        const tokenUrl = "https://localhost:44366/api/token";
        const forecastUrl = "https://localhost:44366/WeatherForecast";

        // 送信する ID とパスワード
        const credentials = {
            Username: "oz@mail.example.com",
            Password: "myPassword"
        };

        const params = {
            method: "POST",
            body: JSON.stringify(credentials),
            headers: { 'Content-Type': 'application/json' }
        };

        // ID とパスワードを POST 送信してトークンを取得
        const responseToken = await fetch(tokenUrl, params);
        if (responseToken.ok) {
            const data = await responseToken.json();
            let token = data.token;

            // 取得したトークンを Authorization ヘッダに含めて
            // 天気予報データを GET 要求し、応答を表示
            const responseForecast = await fetch(forecastUrl,
                { headers: { 'Authorization': `Bearer ${token}` } });
            if (responseForecast.ok) {
                const data = await responseForecast.json();
                setForecasts(data);
            }
        }
    }
}

export default App;

不可解なのが、上のコードでは Web API が 2 回呼ばれることです。ネットの記事を見ると、上のコード例のように useState の第 2 引数に空の配列 [] を設定した場合は初回レンダリングの際の 1 回だけしか第 1 引数に設定した populateWeatherData() は実行されないそうですが、Fiddler で要求・応答をキャプチャしてみると 2 回呼び出しが行われていました。

ネットの記事をいろいろ探したところ、React の useEffect のドキュメント(これが公式?)の「外部システムへの接続」のセクションに以下の記述を見つけました。

"バグを見つけ出すために、開発中には React はセットアップとクリーンアップを、セットアップの前に 1 回余分に実行します。これは、エフェクトのロジックが正しく実装されていることを確認するストレステストです。"

この記事以外に 2 回呼ばれる理由と結びつくことが書かれた記事は見つけられませんでした。本番環境で検証するとかすれば分かるのかもしれませんが、今はその気力がありません。(汗) 調べる気力が出てきて、何か分かったら追記します。

ちなみに、React には「クラスコンポーネント」と「関数コンポーネント」というものがあるそうで、上のサンプルコードは「関数コンポーネント」を使っています。それゆえ React フックと呼ばれる useEffect を使わざるを得ないようです。

一方、古い Visual Studio のテンプレートで作った React アプリは「クラスコンポーネント」を使っており、componentDidMount で Web API の呼び出しを行っています。その場合は 2 回 Web API が呼ばれることは無いです。

Tags: , , ,

React

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  February 2025  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

View posts in large calendar