十数年ぶりに焼石岳
昨日、十数年ぶりに焼石岳に行ってきました。つぶ沼コースで日帰りです。
以前来たときにはまだ胆沢ダムはなく、石淵ダムが現役でした。今現在はすでに石淵ダムの面影の欠片もなく、ダム建設にともなって国道397号線(焼石ビーチライン)もすっかり姿を変えていました。
雲が多いものの日差しもあり一応の晴天。つぶ沼から石沼あたりにかけてのブナを主体とした森の中は、気温はそれほどでないものの風がなく湿度も高いため、歩くと汗がだらだら。銀明水のすぐ向かいの斜面にはいつものように若干残雪が残っておりその周辺はひんやりとした風が吹いていました。姥石平周辺から山頂にかけては流石に風があり、比較的快適に歩くことができました。
花は端境期らしく、あまり多くは咲いておらず。キンポウゲ、シャクナゲ、アヤメはまっさかりという感じでしたが、ヒメカイウはほとんどすべての株が白い花弁を落としてしまったあとでした。ちょっとびっくりしたのは山頂の岩陰にアジサイの小さな小さな株があり花を咲かせていたことでした。
ASP.NET Core 2.0でWebAPIにXSRF対策を仕込む
今日はASP.NET Core 2.0でWebAPIのコントローラーのアクションが起動するまえにXSRF対策の事前チェックを行う方法を調べていました。
HTMLのform要素をPOSTリクエストの送信元とする場合については情報も多くありました。しかし、jQueryのような低レベルのAPIであれAngularのようなフルスタックなフレームワークが提供する高レベルのAPIであれ、JavaScriptコードを送信元とする場合についてはあまり情報がありません。
Web上で紹介されている方法としては2つ。1つ目はASP.NET Coreフレームワークによりform要素内に書き出されたXRSFトークンをJavaScriptコードから取得してAjaxリクエストに使用するもの。2つ目は特定のパスにアクセスしたときだけCookieのエントリーとしてXSRFトークンをクライアントに発行し、クライアント側のJavaScriptコードからこれを取得してAjaxリクエストに使用するもの。
情報量としては前者の方が多かったです。しかし、この方法ではViewをレンダリングするアプリケーションとWebAPIを提供するアプリケーションは同一でないといけないのです。シンプルには違いないものの、どこか理屈というか哲学というかに引っかかるところがあります。ViewとWebAPIをなるべく疎結合にしたいと考えるなら、後者の方を選ぶことになると思います。
後者の方法はこちらで紹介されていました。このWebページの例ではAntiforgeryTokenMiddleware
というミドルウェア・クラスを定義して、「HTTPリクエストを解析して特定のパスに対するリクエストであったら、XSRFトークンを新規作成、HTTPレスポンスのSet-Cookieヘッダーを通じてクライアントに渡す」というロジックを記述しています。そしてこのミドルウェアをStartup.Configure(IApplicationBuilder, IHostingEnvironment)
でアプリケーションに組み込んでいます。
一方でConfigureServices(IServiceCollection services)
ではクライアントからのHTTP要求時にトークンがどこに格納されて送信されてくるかを指定しています。これをあえてしないとフレームワークはトークンがフォーム・データとしてHTTP要求本文の一部として送信されてくることを前提とした動きをしてしまうとのこと。
わかればどうということもない、ほんの少しのコードで実現できるのですが、意外と情報が少ないので苦戦しました。
JP1/AJS2でユニット定義情報に不正なarパラメータが登場
直近、JP1/AJS2に関連する開発プロジェクトを行っていて、メンバーが数時間悩まされた事象です。
事象
JP1/AJS2(v7)のユニット定義情報をJP1/AJS2 View画面で「退避」(エクスポート)すると、出力されたユニット定義情報のなかに、値が不正なユニット定義パラメーターarが混入するケースがある。この定義情報を「回復」(インポート)しようとすると入力エラーが発生する。エラーメッセージはどこの行のどのパラメータがNGであるかなどは一切言及してくれない。
混入するのは次のようなユニット名が不正な状態のarで、from/toを表すタプルのキーに対応する値が空文字列となってしまっている:
... ar=(f=,t=UNIT0000); ar=(f=UNIT0000,t=UNIT1000); ...
arはユニットの関連線(矢印)を定義するためのパラメーターであるが、Viewの画面で見る限りこの不正な値に対応する関連線は表示されない。たしかに表示しようがない内容ではある。
原因
不明。ただ、特定ユニットレベルで明確な再現性があることから、「退避」以前に、JP1/AJS2 Managerの内部データベースに登録されている定義情報からして不正な状態となっているものと考えられる。
対策
「退避」前のユニット定義情報をJP1/AJS2 View画面から編集(実質的にはジョブネットごと削除)してしまうか、「退避」後のユニット定義情報(テキストファイル)から当該のarパラメーターの行を除去してしまう。