アーカイブ
AWS SSO環境下でASP.NET CoreからAWSのリソースを参照する場合はAWSSDK.SSOとAWSSSO.SSOOIDCを参照する。
AWS SSO配下のアカウントのプロファイルを使って署名URLを発行しようとしたところ、下記のような例外が発生しました。
An unhandled exception occurred while processing the request.
FileNotFoundException: Could not load file or assembly ‘AWSSDK.SSO, Culture=neutral, PublicKeyToken=null’. 指定されたファイルが見つかりません。
System.Reflection.RuntimeAssembly.InternalLoad(ObjectHandleOnStack assemblyName, ObjectHandleOnStack requestingAssembly, StackCrawlMarkHandle stackMark, bool throwOnFileNotFound, ObjectHandleOnStack assemblyLoadContext, ObjectHandleOnStack retAssembly)
InvalidOperationException: Assembly AWSSDK.SSO could not be found or loaded. This assembly must be available at runtime to use Amazon.Runtime.Internal.SSOServiceClientHelpers, AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604.
Amazon.Runtime.Internal.SSOServiceClientHelpers.CreateClient(RegionEndpoint region, string serviceClassName, string serviceConfigName, string parentAssemblyName, IWebProxy proxySettings)
AWS Toolkitのバージョンが問題?
下記のIssueを見るとVisual StudioのAWS向け拡張機能であるAWSToolkit for VisualStudioの問題だから最新にすれば治るよとのこと。
https://github.com/aws/aws-toolkit-visual-studio/issues/268
変わらずエラーが出ますね。ローカルにインストールされたバージョンは1.35.2.0でした。1.34.0.0で解決しているはずなのでやはり違う問題のようです。
AWSSDK.SSOパッケージとAWSSDK.SSOOIDCパッケージのインストール
あ、エラーメッセージにAWSSDK.SSOパッケージが解決できないって書かれてますね。AWSSDK.SSOとAWSSDK.SSOOIDCの両方をプロジェクトに追加します。片方だけだと最初の例外と同様にFileNotFoundExceptionが発生するので注意してください。
ReSharper と Rider の .NET 6 / Visual Studio 2022 対応
おぉ、ReSharper と Rider が .NET 6 / Visual Studio 2022 に対応してる！待ってました！
リリースに関する JetBrains のブログ投稿はこちら
https://blog.jetbrains.com/dotnet/2021/12/08/resharper-2021-3/
https://blog.jetbrains.com/dotnet/2021/12/08/dottools-2021-3/
https://blog.jetbrains.com/dotnet/2021/12/08/rider-2021-3-released/
Rider はともかく Visual Studio 2022 が 64bit 化された影響があるので、ReSharper のリリースはもう少し後かなと思っていたのでこれはうれしいですね！
.NET のApple Silicon対応メモ
Apple Silicon に対する.NET の対応方針。とりあえず.NET5はRosetta 2でのエミュレーションまで実施して、ネイティブ対応は.NET 6ですね。
Qiitaへの初投稿
所属会社でもっと技術を公開していこうって動きがあって、だいぶ遅まきながらQiitaへ初投稿です。月１ぐらいで何かしら書いていこうと思います。こっちはこっちで気軽に続けます。
Swagger UI で OIDC の Implicit FlowなAPIを呼びだす。
Swagger UI で OIDC の Implicit Flow な認証を必要とする API を呼びだそうとすると、response_typeにid_tokenが無いぞ。とか、nonceが無いぞ。とか言ってうまく呼びだせない。
issueを見るとOIDC対応はOAS3からだよと書いてあって、終わっているんだかどうだかよくわからない状況になっています。
参考
– https://github.com/swagger-api/swagger-ui/issues/3906
– https://github.com/swagger-api/swagger-ui/issues/3517
OIDCサーバーの実装にもよると思うけれど、IdentityServer 4 を使っている環境では authorizationUrl をこんな風に指定してあげたらどうにか動くようになった。
securityDefinitions:
bearer:
type: oauth2
description: MyApi
flow: implicit
authorizationUrl: 'https://myidp/connect/authorize?nonce=xxxxxxxxx&response_type=id_token'
scopes:
openid: openid token
profile: profile
あっ、Swaggerをホストしているサーバーをlocalhost:3000とかで起動するなら、Identity Server側のRedirectUrisに http://localhost:3000/oauth2-redirect.html を入れる必要がありますね。
docker-composeで起動するならこんな感じですかね
version: "3"
services:
swagger:
image: swaggerapi/swagger-ui
volumes:
- ./swagger.yml:/usr/share/nginx/html/swagger.yaml
environment:
API_URL: swagger.yaml
OAUTH_CLIENT_ID: xxxxxxxx
OAUTH_CLIENT_SECRET: xxxxxxxx
OAUTH_SCOPES: openid profile
ports:
- "3000:8080"
PowerAutomateで、Office 365 グループ宛ての新着メールをトリガーする場合はOffice 365 Groups Mailコネクターを使おう
Office 365 の Outlook の受信をもとに作業を自動化する場合、PowerAutomateのトリガーはOffice 365 Outlookコネクターを利用します。ただし、Office 365 グループ宛ての新着メールをトリガーする場合、このトリガーの「新しいメールが届いたとき（V3）」や「新しいメールが共有メールボックスに届いたとき（V2）」を使ってもトリガーすることができません。
Office 365グループ宛ての新着メールをトリガーしたい場合は、Office 365 Groups Mailコネクターを利用して、「When a new email arrives to a groupトリガー」を設定する必要があります。
どのグループからのメールをフックするかを選択し、
Get a thread postアクションで投稿を取得します。
改めてGroup IDを選択し、Thread IDにトリガーのConversion thread IDとPost IDを設定するとこんな感じに2段階のループになります。
このコネクターで取得できる値はここで説明されています。とりあえず今回欲しいのはこのあたりですね。
| 属性 | 概要 |
| Email address of the user | 送信元メールアドレス |
| Name of the user | 送信元名 |
| Body content | 本文 |
本文はHTMLメールの場合、当たり前ですがHTMLが入ってきてしまうので、Content ConversionコネクタのHtml to textアクションでテキストに変換してあげます。
メールの件名が欲しい場合は、Get a conversation threadアクションを使って、Conversation topic をComposeしてあげれば取得できます。
参考
https://powerusers.microsoft.com/t5/Building-Flows/Flows-for-Office-365-Groups/m-p/144442
https://flow.microsoft.com/en-us/blog/use-our-new-office-365-groups-mail-connector/
ASP.NET Coreの開発中アプリのコンテナで、テスト証明書を作りHTTPSを有効にする。
Visual StudioでASP.NET Coreのコンテナ対応アプリケーションを作成する場合、プロジェクトテンプレートでHTTPS用の構成チェックボックスを有効にすることでDockerコンテナであっても簡単にHTTPSに対応したアプリケーションを作成できます。一度作成したASP.NET Coreのコンテナアプリケーションの場合は、自前でテスト証明書を作成し、環境変数を設定することでHTTPSに対応することができます。
Dockerfile で 443 ポートを EXPOSE する
HTTPSの構成を無しで作成した場合Dockerfileは80しかEXPOSEしていないと思うので443も追加してあげましょう。
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443Visual Studioでデバックする場合
Visual Studioでデバックする場合は、launchSettings.jsonにHTTPSで起動する旨を記載すると、Visual Studioがよろしくやってくれるのでだいぶお手軽です。おそらくこんな感じになっていると思うので、
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
"publishAllPorts": true
}
起動設定を見ながら必要な設定を追加します。とりあえずデバックするだけなら、こんな感じですかね。
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
"publishAllPorts": true,
"useSSL": true,
"environmentVariables": {
"ASPNETCORE_URLS": "https://+:443;http://+:80",
"ASPNETCORE_HTTPS_PORT": "44360"
},
"httpPort": 51803,
"sslPort": 44360
}
Visual Studioは実行時に自動的にテスト証明書を作成しパスワードをユーザーシークレットに保存します。プロジェクトにユーザーシークレットが含まれていない場合は、プロジェクトのコンテキストメニューからユーザーシークレットの管理を選択してVisual Studioがユーザーシークレットを使えるようにします。
この状態でデバック実行を開始すれば、https://localhost/が開きコンテナでのデバック時もHTTPSで開発を進めることができます。
Alpineベースのイメージを利用する場合、System.Drawing名前空間の利用は気を付けたほうが良いかも
.NET CoreでBitmapクラスを利用したりする場合、こんなエラーメッセージが表示されlibgdikplusをインストールしろと言われます。Webで検索するとこのあたりが引っかかりますが、なにも考えずに本番プロジェクトに適用するのは考えたほうが良い気がします。
Can’t use System.Drawing.Common in microsoft/dotnet:runtime
https://github.com/dotnet/dotnet-docker/issues/618#issuecomment-462129474
上のリンクなどでは、”http://dl-cdn.alpinelinux.org/alpine/edge/testing” リポジトリからダウンロードするようにすれば動くよーという情報が載っています。他にもいくつかのサイトで同様の指摘があったのですが、そもそもedgeリポジトリ自体が下記に記載がある通り開発中の位置づけです。ましてやtesting（テスト中）のものを本番環境で使うのは怖いです。
https://wiki.alpinelinux.org/wiki/Edge
なので、方針としては下記の4つあたりの検討かなぁと
– apkのstableリポジトリに移ってくるのを待つ
– 自前でlibgdiplusをビルドする
– System.Drawingを参照する場合、alpine以外のイメージを使う
ASP.NET Core で別プロジェクトにあるコントローラーをマップする場合は、MvcCoreMvcBuilderExtensions.AddApplicationPart拡張メソッドを使う
ドキュメントとしてはここに書いてある。
コントローラー、ビュー、Razor Pages などをアプリケーション パーツと共有する
MvcCoreMvcBuilderExtensions.AddApplicationPart
拡張メソッドを使うわけだけれど、2.xと3.xではConfigureServicesの書き方がちょっとだけ違うので注意
2.xの書き方
services.AddMvc() .AddApplicationPart(typeof(Controllers.IssueController).Assembly);
3.xの書き方
services.AddControllers() .AddApplicationPart(typeof(Controllers.IssueController).Assembly);
AddControllersの部分は、AddControllersWithViewsだったりするかもしれない。
PowerAutomateでBacklogAPIを使いやすくするためのBridgeAPIを作りました。
BacklogAPIって、Swagger定義が無いのと、同一項目を複数回クエリ内で利用するようなAPI(ex. Issue API)がいくつかあるんです。
Swagger上はこのエントリーで紹介したSwagger定義で、type:array、collectionFormat: multiで指定されるような項目なんだけれど、どうやっても複数項目の指定がうまくいかない。
paths:
/api/v2/issues:
get:
summary: FindIssues
description: FindIssues
operationId: FindIssues
parameters:
- {name: apiKey, in: query, type: string, required: true}
- {name: 'projectId[]', in: query, type: string, required: true}
- {name: 'assigneeId[]', in: query, type: string, required: true}
- name: statusId[]
in: query
type: array
collectionFormat: multi
items: {type: integer}
というわけで、複数項目をcollectionFormat: multiではなくJSONのArrayで指定できるようにしたBridgeAPIを作成しました。現時点でこのAPIでフォローしているのは自分で必要なものだけなので、必要があったら追加してくれるとうれしいです。
https://github.com/karuakun/backlog-api-bridge
一応、AzureのWebSiteとAWSのLabmdaで動かすためにプロジェクトを分けているので、配置する場合はどちらか好きなほうから配置してください。単純にデバックとかで動かしたい場合は、BacklogApiBridge.WebApp側でデバック実行すればよいです。
自分のためのAPIなので、すべてのBacklogSpaceへのリクエストをBridgeするようにはしていません。環境変数AllowBacklogSpaces__0とかに、自分のBacklogSpace名をしていして実行してください。
Azureにデプロイする場合は、Azure App Serviceの設定を編集するから、AllowBacklogSpaces__0環境変数を追加してください。
AWS Labmdaで実行する場合は、serverless.templateファイルの26行目あたりでallow-space-nameを書き換えてあげてください。あっ、aws-lambda-tools-defaults.jsonも修正してくださいね。
かるあのメモ on Wordpress 