0 と 1 の世界の見習い探検家

カテゴリ: プログラミング日誌

WordPress の API.NET のプログラムでつついていたところ、記事の投稿操作を行った際に下記のエラーが発生。
すぐに気付けたけど沼る方もいそうだなと思ったため、念のための備忘録です。
StreamWriter 使って Stream に JSON を書いてる方に当てはまるかも。

WordPress から返ってきたエラーの内容↓
rest_invalid_json: 無効な JSON ボディが渡されました。

結論
.NET の StreamWriter を使う際は、BOM に気をつけよう


無効な JSON というので、どんな壊れた内容で API をコールしてしまったのかとデバッガを覗いたところ、
見た目上はきれいな JSON が渡されているようでした。
見た目上は。

20240125-03_json


問題は、リクエスト時に送信する JSON を StreamWriter を使って Stream に書いていた時に起こっていました。
まずシリアライズ ツールを使って生成した JSON を String 型の文字列に格納し、その後送信用の Stream に StreamWriter を使って書いていました。

こんな感じ
var json = JsonSerializer.Serialize(obj, this._serializerOptions);
var ms = new MemoryStream();
using (var sw = new StreamWriter(ms, Encoding.UTF8, 512, true))
{
    await sw.WriteAsync(json);
}

良くなかったのがここで StreamWriter の Encoding 指定に Encoding.UTF8 を使っていたこと。
書き込み先の Stream の頭に BOM が付与されてしまい、それで受け取った側の WordPress が壊れた JSON として認識したようです。

雑なサンプルコードですが、UTF8 を使いたい場合は Encoding.UTF8 を使わずに、UTF8Encoding を new して、コンストラクタの第一引数に false を与えてあげましょう。BOM が付与されなくなります。

var json = JsonSerializer.Serialize(obj, this._serializerOptions);
var ms = new MemoryStream();
using (var sw = new StreamWriter(ms, new UTF8Encoding(false), 512, true))
{
    await sw.WriteAsync(json);
}


まぁそもそも、使っているシリアライザが System.Text.Json 名前空間のものなのですが、
デバッガで見た内容からして、ASCII で送信可能な状態にエンコーディングしてくれているので、UTF8 を使う必要がないと言えば無いのですが、ちょっとデバッグ目的で使いたて……ですね…… (もごもご)

20240125-01_netsdk1054errormsg

.NET Standard で NuGet 用のパッケージ (*.nupkg) を出力しようとした際、下記エラーが発生して出力できなかったときの備忘録。

.NET Standard で「パック」を行おうとしたところ、下記エラーメッセージが表示され出力に失敗しました。
NETSDK1054: .NET Core のみがサポートされています。

対象の .NET Standard プロジェクトのプロパティを開き、[パッケージ] > [全般] > 「.NET ツールとしてパック」の項目を探す。
間違えてチェックをオンにしてしまったようだが、下記は .NET Standard のプロジェクトでは非対応のようなので、チェックを外してください。

20240125-02_check

エラーの言っている .NET Core のみのサポートの話を参照している外部の NuGet パッケージのバージョンの問題だと誤解して、一生懸命バージョンを下げたりしていたが、なんのこともなかった……。

こんにちは、
立て続けに備忘録です。
WordPress 環境を社内のイントラ環境や個人 PC 内の検証環境でお使いの方向けの記事です。

※この記事で対象としている WordPress のバージョンは 6.4.2

WordPress には REST API の機能があり、コールすることで「記事の投稿」「ファイルのアップロード」など様々な操作を行うことが出来ます。
利用するためには、WordPress の管理画面で「アプリケーションパスワード」を発行する必要がありますが、HTTPS でない環境の場合、このアプリケーションパスワードの発行機能がブロックされており、使えません。
※アプリケーションパスワードの詳細についてはぐぐってください


20240123-201_WP_APWBLOCKED

アプリケーションパスワードを使用すると、実際のパスワードを入力しなくても XML-RPC や REST API などの非対話型システムを介した認証が可能になります。アプリケーションパスワードは簡単に取り消すことができます。サイトへの従来のログインには使用できません。

アプリケーションパスワードには HTTPS が必要ですが、このサイトでは有効ではありません。

これが開発用サイトであれば、適宜、環境タイプを設定して、アプリケーションパスワードを有効化できます。

まぁ当然といえば当然です。
暗号化されてない環境でアプリケーションパスワードを利用するということは、セキュリティ上の重大なリスクがあります。

ただ、社内のイントラ環境やローカルに立てた検証環境などで利用している WordPress で REST API やアプリケーションパスワード機能を使いたい場合もあるかと思います。
その方法のご紹介です。

インターネットに公開されている環境の WordPress ではこの手順は実施しないでください。セキュリティ上のリスクになります。


wp-config.php を編集する


20240123-202_WP_wpconfig

wp-config.php とは WordPress のインストール ディレクトリ内にある php ファイルです。
このファイルに後述の行を追加することで非 HTTPS 環境でもアプリケーションパスワードの発行を受けることができるようになります。

まずは wp-config.php のバックアップを取ってください (破損すると環境自体が壊れるので)

wp-config.php をテキストエディタで開きます。
Windows の場合、改行コードを壊さぬようテキストエディタは VSCode あたりを利用すると安全かもしれません。

そして、一番末尾までスクロールし、
require_once ABSPATH . 'wp-settings.php';
の 1 つ手前の辺りに次の内容を追加してください

define( 'WP_ENVIRONMENT_TYPE', 'local' );
末尾のセミコロンも忘れないでください。
下記のような感じで OK です。

20240123-203_WP_lineadded

上書き保存を行い、WordPress の管理画面のアプリケーションパスワード発行の画面のページをリロードすると、「アプリケーションパスワードには HTTPS が必要ですが、このサイトでは有効ではありません。~~」のメッセージが消え、下記のようにアプリケーションパスワードが発行可能になっていることを確認できると思います。

20240123-204_WP_enabled

お疲れ様です。
WordPress の REST API をお楽しみください。


【おまけ】WP_ENVIRONMENT_TYPE の設定が反映されない!?

下記のコードを追加してもアプリケーションパスワードが有効にならないことがあります。
define( 'WP_ENVIRONMENT_TYPE', 'local' );

私が遭遇したケースでは、上記のコードの挿入位置がよくありませんでした。
最初 wp-config.php の末尾に記載をしていたのですが、その際は反映がなされませんでした。
wp-settings.php を require_once する前に define しないと正しく反映されないようです。
ご注意ください。

こんにちは。
超久々の備忘録記事です。

Windows に Docker Desktop をインストールする際、インストール先とかを変える方法について遺しておきます。
2024 年 01 月段階での情報に基づきます。

結論: "Docker Desktop Installer.exe" のコマンドライン パラメーターを使う


Docker Desktop のインストーラはデフォルトでインストール先が指定されています。
あとついでに wsl のデータとかコンテナ関連のデータの配置先も。
全部 C:\ ドライブなんですよね。
パフォーマンス的には C:\ のほうが望ましいことがほとんどなのでしょうが、
開発検証目的の Docker Desktop 環境で C: ドライブの領域を使うのもなぁということで変更してみました。

後からでも変更する方法があるらしいですが、面倒なのでインストール時点で変えておきたいですよね。


インストーラーのパラメーター例 (WSL を利用する場合)
"Docker Desktop Installer.exe" install --installation-dir="D:\Program Files\Docker\Docker" --windows-containers-default-data-root="D:\Users\XXXX\AppData\Local\Docker\containers" --wsl-default-data-root="D:\Users\XXXX\AppData\Local\Docker\wsl"

上記の例では、Docker Desktop のインストール先と、WSL のイメージのデフォルト配置先、並びにコンテナのデフォルト格納先を変更しています。


【手順】 (Windows 10 の場合)
1. "Docker Desktop Installer.exe" を入手 (適当にダウンロード フォルダーとかにとりあえず落とす)

2. ダウンロード先のフォルダをエクスプローラーで開き、エクスプローラーのメニュー [ファイル] (左上) から
 [Windows PowerShell を管理者として開く] を選択

dockerdesktopwin240123-001_runas

3. cmd.exe を起動する
 ※管理者権限でコマンドラインが実行できればなんでも良いんですけどね

dockerdesktopwin240123-002_cmd


 上記のようにプロンプトの行頭に PS が出ていない状況なら OK

4. コマンドラインの実行
 お好みに合わせてインストール先は変えてくださいな

dockerdesktopwin240123-003_install


これで C:\ ドライブをあまり圧迫せずに済みそうです。



詳細情報
"Docker Desktop Installer.exe" に --help パラメーターを指定するとパラメーターの一覧を吐いてくれます。
いろいろインストール時に指定を掛けたい方は見てみるといいかも。

dockerdesktopwin240123-004_help



C:\ ドライブの領域を使いたくない人向けのソリューション、もっと良いものがある気がしますが、
一旦インストール先を変更する、という解決策のご紹介でした。
では。

どうもこんにちは、青砥です。
最近発見して便利だと思ったナレッジを共有します。

アセンブリのバージョンなどでビルド時の日時を使用する方法について書き遺しておきます。


awpioetvj4tj-02
図 1 ビルド結果

Visual Studio のプロジェクトのプロパティで、アセンブリや NuGet Package (*.nupkg) のバージョンを指定するかと思いますが、ここで「ビルド時の日時」を使用した動的なバージョン番号の生成を可能にする方法を見つけました。

まずは結論から。
$([System.DateTime]::Now.ToString('0.yy.M.dHH'))

qad34vtuwm04t
図 2 プロジェクト プロパティでの指定


DateTime オブジェクトを ToString しているイメージです。
yy.M.dHH なので下記のようになります。

図 3 例の書式指定の場合のバージョン番号生成結果


上記は .NET Standard 2.0 ライブラリのプロジェクトのプロパティですが、おそらく Visual Studio 2022 上であれば他の .NET Framework 向けプロジェクトなどでも利用可能かと思います。


仕組み
Visual Studio ではプロジェクト プロパティで利用可能な変数のような仕組みが存在します。

(参考)
MSBuild の予約済みおよび既知のプロパティ - MSBuild | Microsoft Learn
https://learn.microsoft.com/ja-jp/visualstudio/msbuild/msbuild-reserved-and-well-known-properties?view=vs-2022

例えば、プロジェクト プロパティでは出力アセンブリ名がデフォルトではプロジェクトと同名になるよう下記のような指定になっております。

図 4 出力するアセンブリ名の指定


上記の例ではプロジェクトに関する各種値を提供する機能からプロジェクト名を値として利用しています。このような変数機能の他に「プロパティ関数」と呼ばれる動的な値の呼び出しも一部提供されているようです。

(参考)
プロパティ関数 - MSBuild | Microsoft Learn
https://learn.microsoft.com/ja-jp/visualstudio/msbuild/property-functions?view=vs-2022

上記のページで紹介されている例を見てみるとなんとなく分かる通り、どうも PowerShell をワンライナーで実行しているようなイメージのようです。
そのため、結論に記載した通り、System.Date の Now プロパティで現在 (実行はビルド時なのでビルド時現在) の日時情報を DateTime オブジェクトで取得し、ToString メソッドで好きな形式に書式調整してあげれば、日時から動的にバージョン番号を生成することができるようになります。

DateTime の文字列化時の書式設定については下記ページをご参照ください。
(参考)
DateTime.ToString メソッド (System) | Microsoft Learn
https://learn.microsoft.com/ja-jp/dotnet/api/system.datetime.tostring?view=net-7.0

もっとわかりやすい MS 以外が公開しているドキュメントも参考になるかとは思いますがw


開発中途版などで中間成果物を短いスパンでリリースするなどの利用目的にハマると思います。

ご参考までに。

このページのトップヘ